argent-react-native-optimization

规则

• 不要进行散弹式优化。先测量，定义什么是“足够好”（目标指标 + 阈值），修复最严重的问题，然后诚实地重新测量。
• 快速扫描 — 使用 react-profiler-renders 获取实时渲染计数表。立即识别热点组件。
• 深度测量 — 加载 argent-react-native-profiler 技能。react-profiler-start → 交互 → react-profiler-stop → react-profiler-analyze。
• 检查 — 根据发现使用 react-profiler-component-source。使用 react-profiler-fiber-tree 追踪组件祖先和渲染成本。
• 验证正确性 — 在修复之前，重新收集上述步骤的信息，并逻辑判断该方法是否值得实施。
• 修复 — 应用一个修复。在提交之前使用 debugger-evaluate 验证。
• 重新测量 — 报告目标指标是否改善、退化或保持不变。检查其他区域是否有退化。如果没有净收益或不可接受的权衡，则回退。
• 性能分析不仅用于验证，也用于发现。 使用性能分析器发现静态分析遗漏的问题，而不仅仅是确认修复。
• 架构变更每周期只修复一个。 机械性批量修复（内联样式、索引键）可以分组 — 批量后重新分析一次。当测量涉及设备交互时，在第一次运行前将其记录为流程（argent-create-flow 技能），以便所有后续周期重放相同的步骤。
• React 编译器：如果 react-profiler-analyze 报告 reactCompilerEnabled: true，除非通过 react-profiler-fiber-tree 确认编译器退出（缺少 useMemoCache），否则不要提议使用 useCallback/useMemo/React.memo。
• 子代理：阶段 1-2 分派子代理 — 每个 lint 结果一个文件，每个语义检查项一个。子代理不能接触设备 — 所有性能分析和端到端验证必须在主代理中完成。

流程

Lint 和语义扫描可以廉价地捕获确定性问题。性能分析发现静态分析遗漏的运行时瓶颈。两者都要做。

将此检查表复制到您的 TODO 列表中：

优化进度：
- [ ] 阶段 1：Lint 扫描（确定性 — 无需运行应用即可捕获机械性问题）
- [ ] 阶段 2：语义扫描（判断 — 记忆化、列表、动画等）
- [ ] 阶段 3：基线性能分析（找到真正的瓶颈，修复最严重的问题）
- [ ] 阶段 4：验证无回归（崩溃、错误、红屏）

阶段 1：Lint 扫描

在项目根目录运行一次 ESLint，使用全面的 RN 性能规则集。分派子代理修复结果 — 每个文件一个。
参见 references/lint-rules.md 了解规则集和步骤。

阶段 2：语义扫描

审查每个需要判断的区域 — 记忆化、列表渲染、动画、异步模式、效果清理、状态管理、上下文架构。每个检查项分派一个子代理。
参见 references/semantic-checklist.md 获取完整检查表。

阶段 3：可视化性能分析

1. 加载 argent-react-native-profiler 技能，启动双重性能分析
2. 执行关键用户流程（导航用户指定的屏幕，或所有主要流程）
3. 使用 react-profiler-analyze + native-profiler-analyze + profiler-combined-report 分析
4. 将性能分析结果与阶段 1-2 的发现交叉引用
5. 修复影响最大的问题。架构变更后重新分析；机械性修复批量处理。如果修复后录制的流程中断（例如 UI 布局更改），请按照 argent-create-flow 技能修复流程，而不是静默丢弃。

阶段 4：验证无回归

导航范围内的每个屏幕和 UI 流程，确认每个都能无错误渲染。如果未指定范围，则验证整个应用 — 通过 argent-device-interact 覆盖所有可达屏幕。使用 debugger-log-registry 检查运行时错误，并截图检查红色/黄色错误屏幕。检查修复引入的回归（例如，更少的重新渲染但更高的 CPU，或不同屏幕上的新卡顿）。仅主代理。

应用级优化

1. 阶段 1：集中运行 lint（一条命令），分派子代理并行修复每个文件
2. 阶段 2：语义扫描每个检查项一个子代理
3. 阶段 3：主代理分析最严重的屏幕；自上而下修复架构问题
4. 阶段 4：主代理导航所有屏幕以验证无崩溃

在整个运行之后，再次运行 lint 以验证您的更改没有引入新问题。
这也有助于确保您没有遗漏任何本可以修复的问题。