📚 课程目录第2章搭建性能可观测的RN工程

2. 搭建性能可观测的RN工程

性能优化最怕“盲调”。如果工程里没有稳定的观测手段，我们只能凭感觉猜瓶颈：是 JS 线程被长任务堵住，还是 UI 线程掉帧，抑或是网络请求拖慢了首屏。本章的目标，是把一个普通的 React Native 工程改造成“自带仪表盘”的可观测工程——从初始化项目开始，接入 Flipper、React DevTools、Hermes 调试能力，并配置好性能面板，让后续每一处优化都有数据可依。

一、初始化一个可观测友好的工程

先创建工程。这里以 React Native CLI 为例（若使用 Expo，可参考其对应的 dev client 方案）：

npx @react-native-community/cli init PerfLab --version 0.74.0
cd PerfLab
npx react-native run-android   # 或 run-ios

初始化完成后，先确认三件事，它们决定了后续观测能力是否可用：

Hermes 是否开启：在 android/app/build.gradle 中确认 hermesEnabled = true；iOS 在 Podfile 中确认 :hermes_enabled => true。Hermes 是 RN 默认 JS 引擎，它自带采样式 Profiler，是性能面板的数据来源。
开发模式与 Release 模式区分：Dev 模式下 JS 走 Metro、开启大量校验，性能数据不能代表线上；性能结论必须同时看 Dev 与 Release 两个口径。
调试端口：Metro 默认 8081，Flipper 通过它连接设备；若端口被占用，需在 metro.config.js 或启动参数中调整。

二、集成 Flipper：桌面端的“总控台”

Flipper 是 Meta 开源的移动端调试平台，它把日志、布局检查、网络、数据库、React DevTools 等插件集中在一个桌面应用里。RN 0.62 之后已内置 Flipper 支持，通常只需安装桌面端并确认原生依赖存在。

Android 侧，在 android/app/build.gradle 的 dependencies 中确认：

debugImplementation("com.facebook.flipper:flipper:0.239.0")
debugImplementation("com.facebook.flipper:flipper-network-plugin:0.239.0")
debugImplementation("com.facebook.flipper:flipper-fresco-plugin:0.239.0")

iOS 侧，Podfile 中通常已有 use_flipper! 相关配置，执行 pod install 即可。启动 App 后，Flipper 会自动识别设备，左侧设备列表出现应用名即表示连接成功。

Flipper 里最值得关注的三个面板：

Logs：查看 JS 与原生日志，配合 console.log 定位异常。
Layout Inspector：可视化视图层级，快速发现过深嵌套、冗余包裹。
Network：抓取请求耗时、响应体大小，判断首屏是否被接口拖慢。

三、React DevTools：看清组件渲染

React DevTools 用于检查组件树、props、state 以及渲染次数。RN 中它有两种接入方式：一是通过 Flipper 的 React DevTools 插件，二是独立运行 npx react-devtools 后由 App 连接。

接入后，重点使用 Profiler 标签页：点击录制，操作一段交互，停止后即可看到每个组件的渲染耗时与渲染原因。若某个列表项组件在滚动时反复渲染，说明缺少 React.memo 或依赖数组不稳定，这正是后续优化的切入点。

React DevTools 的 Profiler 反映的是 React 协调（reconciliation）阶段的耗时，而 Hermes Profiler 反映的是 JS 执行耗时。两者结合，才能区分“渲染逻辑重”还是“JS 计算重”。

四、Hermes 调试与性能面板配置

Hermes 提供了采样式 CPU Profiler。开启方式是在 App 内通过开发者菜单或代码触发：

// 在开发入口处按需开启采样
if (__DEV__) {
  const { PerformanceObserver } = global;
  // Hermes 采样通常通过 DevSettings 或 Flipper 的 Hermes 插件触发
}

更常用的路径是：在 Flipper 中打开 Hermes Debugger 或 React Native Performance 插件，点击 “Start Profiling”，操作页面后 “Stop”，即可得到火焰图。火焰图中横向宽度代表耗时占比，纵向代表调用栈深度。若某个函数在栈顶占据很宽，它就是热点。

同时，RN 内置的 Systrace 与 Performance Monitor 也值得开启。Performance Monitor 可在开发者菜单中打开，实时显示：

UI FPS：原生 UI 线程帧率，低于 55 需警惕。
JS FPS：JS 线程帧率，掉到 30 以下通常意味着长任务。
RAM：内存占用，持续上涨可能泄漏。

下面这张图把本章的观测链路串起来：从工程初始化，到三类工具各自负责的观测维度，再到最终定位问题的判断依据。

五、把观测变成日常习惯

工具装好只是起点。建议在工程里固定一套“性能自检”流程：每次提交涉及列表、动画、首屏的改动前，先在 Release 包上跑一遍 Performance Monitor，记录 UI FPS 与 JS FPS 基线；再用 Hermes Profiler 录一段火焰图，确认没有新增热点。基线数据可以简单记录成表格：

场景	UI FPS	JS FPS	首屏耗时	备注
冷启动到首页可交互	—	—	示例：1.8s	Release 包，中端机
长列表快速滚动	58	52	—	示例基线
打开详情页	60	57	—	示例基线

表中数值为示例基线，实际应以自己设备与包体测得为准。有了这张表，后续任何优化都能回答“快了没有、快了多少”。

注意：Flipper、React DevTools、Hermes Profiler 都会带来额外开销，观测时性能数据会略低于真实运行。做最终结论时，应关闭非必要插件，仅保留 Performance Monitor 复测一次。

至此，工程已经具备“看得见”的能力：Flipper 管全局，React DevTools 管组件，Hermes 管 JS 执行，Performance Monitor 管实时帧率。下一步的优化工作，都将围绕这些观测数据展开。