1. 性能优化工程导论

React Native 让团队用 JavaScript 与 React 快速构建跨平台应用，但“能跑起来”与“跑得流畅”之间往往隔着一条很宽的鸿沟。很多项目在功能开发阶段一切正常，上线后却频繁收到“列表滑动卡顿”“页面切换掉帧”“启动白屏时间长”的反馈。要系统解决这些问题，第一步不是急着改代码，而是建立一套关于性能的工程认知：性能问题从哪里来、我们到底要优化什么、用什么方法保证优化不反弹。

一、性能问题从哪里来：三层来源模型

React Native 的性能问题并非单一原因，而是分布在三个层次上，理解这三层是后续所有优化的基础。

第一层是 JavaScript 线程层。React 的渲染、状态更新、事件处理、业务逻辑都运行在 JS 线程上。当一次 setState 触发大量组件重渲染，或在一个事件回调里同步执行了复杂计算（如大数组排序、深拷贝、正则匹配），JS 线程就会被长时间占用。此时即便原生侧一切正常，用户看到的也是界面无响应，因为驱动界面更新的指令无法及时发出。

第二层是原生/UI 线程层。原生模块调用、布局计算（Yoga 引擎）、视图的创建与销毁、图片解码都发生在原生侧。典型问题是长列表一次性渲染过多节点，导致 Yoga 布局计算量激增；或图片未按显示尺寸解码，一张 4000×3000 的图被塞进 100×100 的 Image 中，内存与解码开销被放大数十倍。

第三层是跨线程通信层。JS 与原生之间通过 Bridge（新架构下为 JSI）传递消息。频繁、大量、高频的消息往返会形成通信瓶颈。例如在 onScroll 中每帧都调用原生方法，或在动画中反复读写需要跨线程同步的属性，都会让通信成为瓶颈而非计算本身。

二、优化目标：从“感觉快”到“可度量”

性能优化最忌讳凭感觉。工程化的第一步是把目标量化。在 React Native 中，我们通常关注以下可度量指标：

• 帧率（FPS）：目标稳定在 60 FPS（每帧 16.67ms）或 120 FPS（每帧 8.33ms）。低于 55 FPS 用户即可感知卡顿。
• JS 线程帧耗时：单帧 JS 执行时间应控制在 8ms 以内，为原生渲染留出余量。
• 启动时间（TTI）：从点击图标到首屏可交互的时间，冷启动通常要求控制在 2 秒以内。
• 内存占用：关注峰值内存与内存增长趋势，避免因泄漏导致 OOM。
• 包体积：影响下载转化率与启动加载时间，Android 通常要求 APK 控制在 30MB 以内。

这些指标不是孤立的。例如，为了降低启动时间而延迟加载模块，可能导致首屏渲染时 JS 线程负担加重，反而影响 FPS。因此优化目标需要根据业务场景排优先级：电商类应用首屏启动与列表滑动是核心，工具类应用可能更关注内存与包体积。

三、工程化思维：让优化可持续

性能优化不是一次性的“救火”，而应嵌入研发流程。工程化思维包含四个关键动作：

1. 建立基线：在优化前，用固定设备、固定场景采集一组性能数据作为基线。没有基线，就无法判断优化是否有效。
2. 持续监控：将 FPS、启动时间等指标接入监控平台，在开发、测试、灰度、线上各阶段持续采集，而不是等到用户投诉才排查。
3. 设定预算：为关键路径设定性能预算，例如“首页列表滑动 FPS ≥ 55”“冷启动 TTI ≤ 1.8s”，超出预算即视为回归。
4. 回归防护：在 CI 流程中加入性能检测，当新代码导致指标劣化超过阈值时自动告警或阻断合并。

四、课程项目介绍：一个可复现的性能优化实战

本课程将围绕一个名为 “RN Shop” 的电商示例项目展开。该项目包含以下典型场景，覆盖了 React Native 性能问题的主要来源：

项目会提供完整的可运行代码与性能采集脚本。在后续章节中，我们将依次对上述模块进行性能剖析、优化实施与效果验证。每个优化环节都会给出优化前后的对比数据（示例数据，基于固定测试设备与场景），帮助你建立“问题—手段—验证”的完整闭环。

性能优化工程的核心，不是记住多少技巧，而是建立一套可复用的分析框架：看到卡顿，能判断它来自 JS 线程、原生线程还是通信层；看到指标，能判断优化是否真正生效；看到代码，能预判它可能引入的性能风险。接下来的 29 章，我们将沿着这条主线，从原理到工具，从单点优化到工程体系，逐步构建完整的 React Native 性能优化能力。