React Native 应用的漂移有自己的形状：一个屏每秒重渲 12 次、导航栈在内存里堆 40 个屏、一个 native module 在 0.71 上能用但在新架构上悄悄坏。Profile 工具能找出这些，但前提是你知道往哪里指。AI 审计给你的是”先看哪”清单，让下个小时的 profile 真的能赚回来。
这篇讲什么
聚焦审计流程，优先看 RN 应用真正会坏的地方：渲染性能、导航状态、原生模块兼容、列表虚拟化、图片处理、平台差异（iOS vs Android）。产出是带文件路径的排序热点清单，不是泛泛的”让它更快”讲座。
本文涉及的工具 / 概念：
- React Native: 用 React 写跨平台原生移动 App 的框架。新架构（Fabric / TurboModules）会改变部分审计假设。
- Hermes: RN 默认 JS 引擎。很多性能假设依赖你是 Hermes 还是 JSC。
- 重渲染: 组件没有状态收益地再求值。实践中 RN 头号性能问题。
这篇适合谁看
发线上 RN 应用的开发者——独立、外包、内部都行。当你本地复现不出”用户机上慢”投诉、需要一种结构化的缩小搜索时，特别有用。
什么时候适合用
季度维护。上 App Store / Play Store 前，特别是大重构后的首发。RN 升版本后（0.73 / 0.74 / 0.75 每个都改了性能特性）。用户投诉提到”慢”、“卡”、“只 Android 闪退”时。
开始前准备
- 项目结构能给出。跑
tree -L 3 -I node_modules src粘给 AI 当方向。 - 知道你的 RN 版本、是否在新架构、用 Expo 还是 bare。审计 prompt 会按这些调整。
- 找出用户访问最多的 2-3 个屏。审计优先这些而不是少用流。
具体步骤
- 给 AI 项目树、
package.json、高流量屏的文件路径。说清 RN 版本和架构模式。 - 跑渲染性能审计：
检查 [高流量屏列表]。列出前 5 个可能的重渲染热点。每个：
是哪个组件、什么触发额外渲染（行内函数、不稳定 ref、
context 传播）、最小修复。- 跑导航审计：
检查导航配置（React Navigation / Expo Router）。标出：
深嵌套栈保留过多屏、关闭昂贵特性的 screen options 缺失
（headerLargeTitle、swipe back）、app 启动时 mount 但
本应懒加载的屏。- 跑列表 / 数据审计：
对每个 FlatList / SectionList / VirtualizedList，检查：
keyExtractor 存在且稳定、固定高度时 getItemLayout 有、
Android 上 removeClippedSubviews、单元格里的图组件用
FastImage 或 expo-image 而不是 RN Image。- 跑原生模块审计：
列出 package.json 里的第三方原生模块。每个标：新架构
兼容状态、iOS / Android 行为差异、当前 RN 版本下的已知
问题。标出无人维护的模块（最后发布 > 18 个月）。- 对 AI 标的做 profile。不要信假设——用 Flipper、React DevTools、Hermes profiler 验证。然后带测试修。
- 改过的代码上重跑审计。性能回归藏在修复里。
第一次实操怎么跑
- 挑一个屏——用得最多那个——只跑渲染性能审计。
- 5 个热点逐个在 React DevTools profiler 验证。审计 3-4 个对、1-2 个错，正常。
- 修一个被验证的热点。再 profile。记下实际帧时间改进（或没改进）。
- 你就有了这个 app 的 ground truth：哪些预测可靠、哪些不可靠。用这个校准应用到其余审计上。
完成后检查
- AI 说了具体文件 / 行号吗？“性能可以更好”不可操作。
- 它说的热点 profile 里能复现吗？复现不出来就降级为”以后再查”。
- 它有没有区分 iOS / Android 影响？很多 RN 问题是平台特有；混在一起浪费 profile 时间。
- 原生模块的标记你对照模块真实 repo 验证了吗（发布日期、新架构 issue）？AI 会幻觉兼容性。
怎么复用这套流程
- 四个审计 prompt（渲染、导航、列表、原生模块）存成 Claude Project 或保存 prompt。
- 每次大 RN 升级后先重跑原生模块审计——升级痛多藏这。
- 把审计发现 + 修复结果记进性能日志。3 次审计后你会知道哪些类别在你 app 上真正动针。
建议的操作流程
项目结构 → 高流量 3 屏 → 渲染审 → 导航审 → 列表审 → 原生模块审 → profiler 验证 → 带测试修 → 重审。时间：审计本身约 3 小时，profile + 修按需若干天 / 周。
容易踩的坑
- 不真 profile 就信 AI 热点——AI 是从代码模式假设，profiler 才是 ground truth。
- 一次审整个代码库——50 条发现一条都修不完。先 3 屏。
- 跳过导航审计——30+ 屏的 RN 应用经常在 profile 不到的地方保留内存，得专门去看。
- 升级时不查原生模块兼容——0.73 → 0.74 升级就是在这悄悄坏。
- 不区分 Hermes / JSC——性能假设依赖引擎。告诉 AI。
- 把 React DevTools 渲染计数当唯一信号——也用 Hermes profiler 看 JS 线程时间，Xcode Instruments / Android Studio Profiler 看原生线程时间。
FAQ
- Expo 应用适用吗？: 适用，但 Expo 抽象了部分 native config；把
app.config.js/app.json也指给 AI，加上 package.json。 - 新架构（Fabric / TurboModules）呢？: 告诉 AI 你迁了没。新架构改了原生模块审计方式（TurboModule 状态很重要）。
- AI 能修它找的问题吗？: 代码级修复可以（memoization、prop 改）。原生模块问题通常要真人 + 模块维护者。
- 跟付费 RN 咨询审计比？: 咨询更深、还有架构判断。AI 审计覆盖典型发现的 60-70%，成本只占 1%。
- 哪个模型？: Claude 或 GPT-5.5 有文件访问。Cursor agent 模式对 RN 很合适，能跨多文件读。