argent-react-native-optimization

规则

• 不要盲目进行各种优化。先测量，明确“足够好”的标准（目标指标 + 阈值），修复影响最大的问题，再如实重新测量。
• 快速扫描：使用 react-profiler-renders 查看实时渲染计数表，快速找出热点组件。
• 深入测量：加载 argent-react-native-profiler skill。依次运行 react-profiler-start → 交互 → react-profiler-stop → react-profiler-analyze。
• 检查：针对每项发现运行 react-profiler-component-source。使用 react-profiler-fiber-tree 追踪组件的祖先关系和渲染开销。
• 验证正确性——修复前，重新收集上述步骤中的信息，并在逻辑上判断是否值得采用该方案。
• 修复：应用一项修复。提交前使用 debugger-evaluate 验证。
• 重新测量：报告目标指标是有所改善、变差还是保持不变。检查其他方面是否出现回归。如果没有净收益或权衡不可接受，则还原。
• 用性能分析来发现问题，而不只是验证。 使用性能分析器找出静态分析遗漏的问题，而不只是确认修复有效。
• 架构变更每个周期只做一项修复。 机械式批量修复（内联样式、索引键）可以合并处理；完成后重新进行一次性能分析。如果测量需要与设备交互，请在首次运行前将其记录为端到端测试（argent-create-e2e skill），以便后续所有周期都能重放相同步骤。
• React Compiler：如果 react-profiler-analyze 报告 reactCompilerEnabled: true，除非已通过 react-profiler-fiber-tree 确认编译器发生回退（缺少 useMemoCache），否则不要建议使用 useCallback/useMemo/React.memo。
• 子 Agent：阶段 1–2 会分派子 Agent：Lint 结果按每个文件分派一个，语义检查按每个清单项分派一个。子 Agent 不能操作设备——所有性能分析和端到端验证都必须由主 Agent 完成。

流程

Lint 和语义检查可以低成本地发现确定性问题。性能分析可以找到静态分析遗漏的运行时瓶颈。两者都要做。

将此清单复制到你的 TODO 列表中：

Optimization Progress:
- [ ] Phase 1: Lint sweep (deterministic: catch mechanical issues without a running app)
- [ ] Phase 2: Semantic sweep (judgment: memoization, lists, animations, etc.)
- [ ] Phase 3: Baseline profile (find real bottlenecks, fix top offenders)
- [ ] Phase 4: Verify no regressions (crashes, errors, red screens)

阶段 1：Lint 扫描

在项目根目录运行一次 ESLint，并使用全面的 RN 性能规则集。分派子 Agent 修复检查结果：每个文件分派一个。 规则集和操作步骤请参阅 references/lint-rules.md。

阶段 2：语义检查

审查每个需要判断的方面：记忆化、列表渲染、动画、异步模式、Effect 清理、状态管理规范和上下文架构。每个清单项分派一个子 Agent。 完整清单请参阅 references/semantic-checklist.md。

阶段 3：视觉性能分析

1. 加载 argent-react-native-profiler skill，开始双重性能分析
2. 测试关键用户流程（导航用户指定的屏幕，或所有主要流程）
3. 使用 react-profiler-analyze + native-profiler-analyze + profiler-combined-report 进行分析
4. 将性能分析结果与阶段 1–2 的发现交叉比对
5. 修复影响最大的问题。架构变更后重新进行性能分析；机械式修复可以批量处理。如果记录的端到端测试在修复后失效（例如 UI 布局发生变化），请按照 argent-create-e2e skill 修复端到端测试，不要悄悄丢弃它。

阶段 4：确认无回归

导航至范围内的每个屏幕和 UI 流程，确认渲染时没有错误。如果未指定范围，则验证整个应用：通过 argent-device-interact 覆盖所有可访问的屏幕。使用 debugger-log-registry 检查运行时错误（如果它返回 status: "not_connected"，则表示没有日志文件；请先按照其 guidance 重新连接），并截图检查是否出现红色/黄色错误屏幕。检查修复是否引入回归（例如，重渲染次数减少但 CPU 占用升高，或其他屏幕出现卡顿）。仅由主 Agent 执行。

全应用优化

1. 阶段 1：集中运行 lint（使用一条命令），并行派遣子 Agent 按文件修复问题
2. 阶段 2：每个检查清单项安排一个子 Agent 进行语义检查
3. 阶段 3：主 Agent 对问题最严重的页面进行性能分析，并自上而下修复架构问题
4. 阶段 4：主 Agent 浏览所有页面，确认没有崩溃

全部流程结束后，再次运行 lint，确认更改没有引入新问题。 这也有助于确保你没有遗漏任何可以修复的问题。