Back to Details

argent-react-native-optimization

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Rules

规则

  • Do not apply shotgun optimizations. Measure first, define what "good enough" looks like (target metric + threshold), fix the top offender, re-measure honestly.
  • Quick scan — 
    react-profiler-renders
    for a live render count table. Identifies hot components instantly.
  • Deep measure — load 
    argent-react-native-profiler
    skill. 
    react-profiler-start
    → interact → 
    react-profiler-stop
    → 
    react-profiler-analyze
    .
  • Inspect — 
    react-profiler-component-source
    per finding. 
    react-profiler-fiber-tree
    to trace component ancestry and render cost.
  • Verify correctness - before fixing, recollect information from steps above and make a logical conclusion whether the approach is worth undertaking.
  • Fix — apply one fix. Validate with 
    debugger-evaluate
    before committing.
  • Re-measure — report whether the target metric improved, regressed, or stayed flat. Check for regressions in other areas. If no net benefit or unacceptable tradeoffs, revert.
  • Profile for discovery, not only verification. Use the profiler to find issues static analysis missed, not only to confirm fixes.
  • One fix per cycle for architectural changes. Mechanical batch fixes (inline styles, index keys) can be grouped — re-profile once after the batch. When the measurement involves device interaction, record it as a flow (
    argent-create-flow
    skill) before the first run so all subsequent cycles replay identical steps.
  • React Compiler: if 
    react-profiler-analyze
    reports 
    reactCompilerEnabled: true
    , do NOT propose 
    useCallback
    /
    useMemo
    /
    React.memo
    unless you confirmed compiler bail-out via 
    react-profiler-fiber-tree
    (absent 
    useMemoCache
    ).
  • Sub-agents: Phases 1–2 dispatch sub-agents — one per file for lint results, one per checklist item for semantic. Sub-agents CANNOT touch the device - all profiling and E2E verification must happen in the main agent.
  • 不要盲目进行优化。先测量，定义“足够好”的标准（目标指标+阈值），修复影响最大的问题，然后如实重新测量。
  • 快速扫描 — 使用
    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 Compiler：如果
    react-profiler-analyze
    报告
    reactCompilerEnabled: true
    ，除非通过
    react-profiler-fiber-tree
    确认编译器出现退出情况（缺少
    useMemoCache
    ），否则不要建议使用
    useCallback
    /
    useMemo
    /
    React.memo
    。
  • 子代理：第1-2阶段会调度子代理 — 每个lint结果对应一个子代理，每个语义检查清单项对应一个子代理。子代理不能操作设备 — 所有性能分析和端到端验证必须在主代理中进行。

Pipeline

流程

Lint and semantic sweeps catch deterministic issues cheaply. Profiling finds runtime bottlenecks that static analysis misses. Do both.
Copy this checklist into your TODO list:
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)
Lint扫描和语义扫描可低成本发现确定性问题。性能分析可找出静态分析遗漏的运行时瓶颈。两者都要执行。
将以下清单复制到你的待办事项列表中：
优化进度:
- [ ] 阶段1: Lint扫描（确定性 — 在应用未运行时排查机械性问题）
- [ ] 阶段2: 语义扫描（需判断 — 记忆化、列表、动画等）
- [ ] 阶段3: 基准性能分析（找到真实瓶颈，修复影响最大的问题）
- [ ] 阶段4: 验证无性能退化（崩溃、错误、红屏）

Phase 1: Lint sweep

阶段1: Lint扫描

Run ESLint once at the project root with a comprehensive RN performance ruleset. Dispatch sub-agents to fix results — one per file. See references/lint-rules.md for ruleset and procedure.
在项目根目录运行一次ESLint，使用全面的RN性能规则集。调度子代理修复结果 — 每个文件对应一个子代理。 查看references/lint-rules.md获取规则集和操作流程。

Phase 2: Semantic sweep

阶段2: 语义扫描

Review each area requiring judgment — memoization, list rendering, animations, async patterns, effect cleanup, state hygiene, context architecture. Dispatch one sub-agent per checklist item. See references/semantic-checklist.md for full checklist.
审查每个需要判断的领域 — 记忆化、列表渲染、动画、异步模式、副作用清理、状态管理、上下文架构。每个清单项调度一个子代理。 查看references/semantic-checklist.md获取完整清单。

Phase 3: Visual profiling

阶段3: 可视化性能分析

  1. Load 
    argent-react-native-profiler
    skill, start dual profiling
  2. Exercise key user flows (navigate screens the user specified, or all major flows)
  3. Analyze with 
    react-profiler-analyze
    + 
    native-profiler-analyze
    + 
    profiler-combined-report
  4. Cross-reference profiling results with Phase 1–2 findings
  5. Fix highest-impact issues. Re-profile after architectural changes; batch mechanical fixes. If a recorded flow breaks after a fix (e.g., UI layout changed), follow 
    argent-create-flow
    skill to repair the flow rather than silently discarding it.
  1. 加载
    argent-react-native-profiler
    技能，启动双重性能分析
  2. 执行关键用户流程（导航用户指定的页面，或所有主要流程）
  3. 使用
    react-profiler-analyze
    + 
    native-profiler-analyze
    + 
    profiler-combined-report
    进行分析
  4. 将性能分析结果与阶段1-2的发现交叉对比
  5. 修复影响最大的问题。架构变更后重新进行性能分析；批量处理机械性修复。如果修复后记录的流程出现故障（如UI布局变更），请遵循
    argent-create-flow
    技能修复流程，而非直接丢弃。

Phase 4: Verify no regressions

阶段4: 验证无性能退化

Navigate every screen and UI flow within scope, confirm each renders without errors. If no scope was specified, verify the entire app — cover all reachable screens via 
argent-device-interact
. Use 
debugger-log-registry
to check for runtime errors and take screenshots to check for red/yellow error screens. Check for regressions introduced by fixes (e.g., fewer re-renders but higher CPU, or new jank in a different screen). Main agent only.
导航范围内的每个页面和UI流程，确认每个页面都能正常渲染无错误。如果未指定范围，则验证整个应用 — 通过
argent-device-interact
覆盖所有可访问页面。使用
debugger-log-registry
检查运行时错误，并截图检查红/黄错误屏。检查修复是否引入性能退化（如重渲染减少但CPU占用升高，或其他页面出现新卡顿）。仅由主代理执行此操作。

App-wide optimization

全应用优化

  1. Phase 1: run lint centrally (one command), dispatch sub-agents to fix per-file in parallel
  2. Phase 2: one sub-agent per checklist item for semantic sweep
  3. Phase 3: main agent profiles top offending screens; fixes architectural issues top-down
  4. Phase 4: main agent navigates all screens to verify nothing crashes
After the entire run, run lint again to verify no new issues were introduced with your changes. This also helps ensure you haven't missed any issues which could've been fixed.
  1. 阶段1: 集中运行lint（一条命令），并行调度子代理修复每个文件的问题
  2. 阶段2: 每个语义扫描清单项对应一个子代理
  3. 阶段3: 主代理对影响最大的页面进行性能分析；自上而下修复架构问题
  4. 阶段4: 主代理导航所有页面以验证无崩溃情况
整个运行完成后，再次运行lint以验证你的变更未引入新问题。 这也有助于确保你没有遗漏任何可修复的问题。