React Native 应用的劣化有自己的套路：一个屏每次敲键都重渲、导航栈里挂着 30 个屏不释放、一个第三方原生模块在旧 bridge 上能用，可 0.82 把所有人强制推上新架构后就悄悄出问题。Profile 工具能找出这些，但前提是你知道往哪指。AI 审计给你的是”先看哪”清单，让你接下来在 React Native DevTools 里花的那一小时真的能赚回来。
TL;DR
把项目树、package.json 和访问量最高的 3 个屏喂给 LLM，跑四个针对性审计 prompt（渲染、导航、列表、原生模块），拿到一份带文件路径的排序热点清单。然后动手修之前，每一条都先在 profiler 里验证。截至 2026 年 6 月的基线：React Native 0.82（新架构强制，旧 bridge 已移除）、调试器是 React Native DevTools（Flipper 已下线）、大列表用 FlashList v2 或 LegendList。
这篇讲什么
聚焦审计流程，优先看 RN 应用真正会坏的地方：渲染性能、导航内存、新架构下的原生模块兼容、列表虚拟化、图片处理、iOS 与 Android 差异。产出是带文件路径的排序热点清单，不是泛泛的”让它更快”讲座。
本文涉及的工具 / 概念：
- React Native 新架构: Fabric（C++ 渲染器）加 TurboModules（基于 JSI、按需懒加载的原生模块）。0.76 起默认，0.82 起成为唯一选项（旧 bridge 已被移除）。这是 2026 年任何一次审计里最关键的变量。
- Hermes: RN 默认 JS 引擎。React Native DevTools 和 Performance 面板都是围绕 Hermes 做的，所以大部分 profile 都默认你在 Hermes 上而非 JSC。
- 重渲染: 组件再次求值却没产出不同结果。实践中它仍是 RN 头号性能抱怨，通常来自行内函数、不稳定的对象 prop、或范围过大的 Context。
这篇适合谁看
发线上 RN 应用的开发者（独立、外包、内部都行），尤其是当你本地复现不出”用户机上慢”的投诉、需要一种结构化方式缩小搜索范围时。版本升级之后也特别有用——大多数回归都藏在那里。
什么时候适合用
- 季度维护。
- 上 App Store / Play Store 前，特别是大重构后的首发。
- RN 升级之后。跨过新架构这条线（任何 0.76 以下 → 0.82）风险最高，因为依赖旧 bridge 的原生模块会坏。
- 用户投诉提到”慢”、“卡”、“只 Android 闪退”时。
开始前准备
- 跑
tree -L 3 -I node_modules src，把输出粘给 AI 当方向。 - 说清你的确切 RN 版本；用 Expo 的话说明 Expo SDK（SDK 54 是最后一个还能用旧架构的，SDK 55 起带 RN 0.83）、以及你是 bare 还是 managed。审计 prompt 会按这些调整。
- 找出用户访问最多的 2-3 个屏。先审这些，别先审很少用的流程。
具体步骤
- 给 AI 项目树、
package.json和高流量 3 屏的文件路径。说清 RN 版本，并确认你在新架构上（0.82+ 上几乎必然是）。 - 跑渲染性能审计：
检查 [高流量屏列表]。列出前 5 个最可能的重渲染热点。每个：
是哪个组件、什么触发了额外渲染（行内函数、不稳定的对象
prop、范围过大的 Context 消费者）、最小修复（useCallback、
useMemo、React.memo，或拆分 Context）。- 跑导航审计：
检查导航配置（React Navigation v7 或 Expo Router）。标出：
深嵌套栈挂载过多屏不释放、缺失能关掉昂贵特性的 screen
options（headerLargeTitle、手势）、以及任何启动时 mount
但本应懒加载的屏。- 跑列表 / 数据审计：
对每个 FlatList / SectionList / VirtualizedList，检查：
keyExtractor 是否稳定、固定高度行是否有 getItemLayout、
按条目数量看是否该迁到 FlashList v2 或 LegendList。标出
单元格里仍用 RN <Image> 而不是 expo-image 的图片组件。- 跑原生模块审计：
列出 package.json 里的第三方原生模块。每个标：新架构
（TurboModule/Fabric）兼容性、iOS 与 Android 行为差异、
当前 RN 版本下的已知问题。标出最后发布超过 12 个月、或
有未关闭新架构兼容 issue 的模块。- 对 AI 标的做 profile。别信假设。用 React Native DevTools（React profiler，0.83+ 上还有 Performance 面板）验证，iOS 原生线程用 Xcode Instruments，Android 原生线程用 Android Studio Profiler。
- 带测试修，然后在改过的代码上重跑审计。回归会藏在修复里。
列表库怎么选（2026 年 6 月）
列表审计通常以”这个该用 FlashList 还是 LegendList？“收尾。诚实的经验法则如下：
| 库 | 适合 | 原因 |
|---|---|---|
FlatList（内置） | 约 500 条以下的列表 | 够用、不加依赖；超过几百行就劣化，因为它会销毁并重建单元格 |
FlashList v2（Shopify） | 多数生产列表，500+ 条 | 用单元格复用而非纯虚拟化；v2 是针对新架构的重写，去掉了 estimatedItemSize，自动测量条目尺寸 |
LegendList | 滚动是核心体验的信息流 / 聊天 / 媒体 | 专为新架构打造；在中端 Android 上跑大且复杂的行也能稳住 60fps，而 FlashList 这种场景偶尔掉帧 |
注意 v2 的迁移细节：升级 FlashList 时，删掉 estimatedItemSize、estimatedListSize、estimatedFirstItemOffset——v2 会忽略它们。见 FlashList 文档。
第一次实操怎么跑
- 挑你用得最多的那一个屏，只跑渲染性能审计。
- 5 个热点逐个在 React Native DevTools 的 React profiler 里验证。预期大概 3-4 个成立、1-2 个错。从代码模式生成的假设，这很正常。
- 修一个被验证的热点，再 profile，记下实际的帧时间变化（或没变化）。
- 你现在就有了这个 app 的 ground truth：哪些预测可靠。用这个校准去审其余代码。
完成后检查
- AI 说了具体文件和组件吗？“性能可以更好”不可操作。
- 它说的热点在 profiler 里能复现吗？触发不出来就降级为”以后再查”。
- 它区分了 iOS 和 Android 的影响吗？很多 RN 问题是平台特有的；混在一起浪费 profile 时间。
- 原生模块的标记，你对照模块真实 repo 查了吗（最后发布日期、未关闭的新架构 issue）？AI 会很自信地幻觉兼容性结论，所以这步不能省。
容易踩的坑
- 不真 profile 就信 AI 热点。AI 是从代码模式假设，profiler 才是 ground truth。
- 一次审整个代码库。50 条发现一条都修不完。先 3 屏。
- 跳过导航审计。30+ 屏的应用经常在渲染 profiler 看不到的地方保留内存，得专门去看导航栈。
- 升级时跳过原生模块兼容检查。移除旧 bridge 的 0.76 → 0.82 这一跳，正是模块坏掉的地方。
- 还在问”Flipper”。它在 0.73-0.74 就被弃用、已不在模板里。告诉 AI 你用 React Native DevTools，它的建议才对得上现实。
- 把 React 渲染计数当唯一信号。也要在 DevTools 里看 JS 线程时间，在 Xcode Instruments / Android Studio Profiler 里看原生线程时间。
FAQ
- Expo 应用适用吗？: 适用。除了
package.json，把app.config.js/app.json也指给 AI，因为 Expo 抽象了 native config。如果你还在用旧架构的 Expo SDK 54，明说；SDK 55（RN 0.83）要求新架构。 - 新架构变强制后有什么变化？: 从 RN 0.82 起没有退路，每个原生模块都必须是 TurboModule/Fabric 兼容的构建。升级之后，本流程里最重要的就是原生模块审计这一步。
- AI 能修它找的问题吗？: 代码级修复可以（memoization、prop 稳定化、列表迁移）。原生模块问题通常要真人加上模块维护者。
- 跟付费 RN 咨询审计比？: 咨询更深、还带架构判断。AI 审计覆盖了相当一部分常规发现（重渲染、列表误用、僵尸模块），成本只占很小一块，而且快到能每季度跑一次。
- 哪个模型？: 用能跨整个 repo 读文件的编码模型。Claude Code 里的 Claude Opus 4.7 或 Sonnet 4.6、Codex 里的 GPT-5.5，都能很好处理跨文件 RN 读取。Cursor 的 agent 模式同理好用。