口述：RN性能优化方法论深度解析

一句话概括

RN 性能优化的核心方法论是「先定位线程，再下手优化」——性能瓶颈可能藏在 JS 线程、UI 线程、Shadow 线程或 Bridge 通信管线的任何一个环节，而优化的三驾马车是：压缩通信、丝滑列表、秒开首屏。

核心知识点

1. 通信优化——别让 Bridge 成为高速公路上的收费站

旧架构每次 JS ↔ 原生交互都是一次序列化 + 排队 + 反序列化的往返。优化原则就三条：

原则一：减少通信频率

// ❌ 滑块拖拽时每帧都通信（16ms一次，Bridge 直接排队爆炸）
<Slider onValueChange={v => NativeModules.Filter.apply(v)} />

// ✅ 节流到 50ms，减少 70% 的消息量
import { throttle } from 'lodash';

const throttledFilter = useMemo(
  () => throttle(v => NativeModules.Filter.apply(v), 50),
  []
);
<Slider onValueChange={throttledFilter} />

原则二：能跑原生线程就别跑 JS 线程

动画、手势、传感器监听这类高频操作必须用 useNativeDriver: true，它们完全在原生侧执行，不经过 Bridge：

Animated.timing(opacity, {
  toValue: 0,
  duration: 300,
  useNativeDriver: true,  // ← 这行值一万次 Bridge 通信
}).start();

原则三：大数据不要塞进 Bridge

传一张 2MB 图片的 Base64 字符串意味着 JS 侧编码 → Bridge 序列化 → 原生侧解码，三程浪费。传文件路径，让原生自己去读。

2. 列表渲染优化——FlatList 参数调对就能快 50%

列表优化的 80% 收益来自这 5 个配置项：

<FlatList
  data={data}
  renderItem={renderItem}
  keyExtractor={item => item.id}          // ① 别用 index 当 key
  getItemLayout={getItemLayout}            // ② 定高列表的灵魂
  removeClippedSubviews={true}             // ③ Android 必开
  windowSize={5}                           // ④ 默认21太大，5刚好
  maxToRenderPerBatch={10}                 // ⑤ 别一口气渲染太多
  initialNumToRender={10}
/>

为什么 getItemLayout 是灵魂？ 没有它，FlatList 需要等每个 item 渲染后才能测量高度。有它，FlatList 直接跳着算 offset，滑动时不需要等待布局——这就是「丝滑」和「一顿一顿」的区别。

组件层面配 React.memo + useCallback 的组合拳：

const FeedItem = React.memo(({ item, onLike }) => {
  const handleLike = useCallback(() => onLike(item.id), [item.id, onLike]);
  return (
    <TouchableOpacity onPress={handleLike}>
      <Text>{item.content}</Text>
    </TouchableOpacity>
  );
});
// React.memo: props 不变就不重渲染
// useCallback: 保证 onLike 的引用不变，memo 才能生效

3. 让动画不卡——useNativeDriver 的前世今生

Animated API 有两种驱动模式：

模式	计算在哪里	每帧通信	适用
JS 驱动（默认）	JS 线程	每帧 Bridge 传值	需要 JS 逻辑参与（如颜色插值）
原生驱动	原生 UI 线程	零通信	transform、opacity 等纯视觉动画

// ✅ 这些属性支持原生驱动
Animated.timing(fadeAnim, {
  toValue: 1,
  useNativeDriver: true,  // opacity、transform 都支持
}).start();

// ❌ 这个不行——颜色/宽高的动画改不了原生驱动
// Animated.timing(widthAnim, { ..., useNativeDriver: true, });
// 报错：width is not supported by native animated module

为什么不是全部属性都支持原生驱动？ 因为 useNativeDriver 把动画直接交给原生侧的 CADisplayLink（iOS）或 Choreographer（Android）驱动，只有原生侧「知道」怎么直接应用在 View 上的属性（transform、opacity）才支持。width、height、backgroundColor 这些需要触发布局重算的属性，必须 JS 线程参与。

4. 排查清单：从现象反推原因

现象	最可能的根因	优先排查
滚动时 JS FPS 低	JS 线程在做耗时计算	console.time 排查 renderItem
JS FPS 正常但 UI FPS 低	Shadow Tree 太深 / View 创建太多	减少嵌套层级、开 removeClippedSubviews
滑动到顶部白屏	windowSize 太小，顶部 View 被回收	增大到 7-9
图片闪烁白块	网络图片未缓存	上 FastImage
页面跳转卡顿	Bundle 体积大、首屏组件太重	拆包 + Hermes + InteractionManager
动画掉帧	没开原生驱动	检查所有 Animated 调用

5. JS 线程、UI 线程、Shadow 线程的分工

很多面试者说不清这三条线程的职责，一句话讲清楚：

JS 线程：跑你的 React 代码（render、state更新）
        ↓ 生成虚拟DOM → 走 Diff
Shadow 线程：跑 Yoga 布局计算（flexbox → 坐标）
        ↓ 生成 Shadow Tree
UI 线程：跑原生 View 的创建和绘制（Android/iOS 主线程）

如果列表卡顿，先在 FPS Monitor 看是哪条线程的帧率掉了一一然后针对性下手。

其实你每天都在用

• 微信朋友圈下滑时旧内容闪现白色占位： removeClippedSubviews 回收了滚出屏幕的 View，滚动回去时需要重建——windowSize 没调好
• 淘宝搜索结果列表的灰色方块逐渐变图片： 图片懒加载 + 渐进式渲染
• iOS 比 Android 的 RN 动画顺滑很多： iOS 的 CADisplayLink 驱动比 Android 的 Choreographer 帧率更稳，且 iOS 的 UI 线程优先级更高
• 低端机上打字时 RN 页面「冻住」： 键盘弹起的系统动画占用了 UI 线程，而你的 RN 页面恰好在 UI 线程创建 View——用 InteractionManager.runAfterInteractions 延迟非紧急操作
• 截屏/录屏时 RN 动画掉帧明显： 系统录屏在 UI 线程插了一脚，每帧都要捕获画面，和你的动画抢资源

常见误解（FAQ）

❌ 误区1：「优化列表就是加 keyExtractor 和 React.memo」

这两个只是及格线。真正的质变来自 getItemLayout（定高列表的性能从 O(n) 变 O(1)）和 removeClippedSubviews（Android 上显著降低内存）。很多团队止步于 memo 就以为优化完了，结果扁平列表仍然卡。

❌ 误区2：「Bridge 通信很慢，所以尽量少用原生模块」

Bridge 慢在高频通信而非单次通信。一次 NativeModules.xxx.doSomething() 的耗时在 1-3ms，完全可以接受。但如果在 onScroll 里每帧调用一次（16ms 间隔），排队效应会让延迟累积到肉感可察。解决方案不是不用，而是节流 + 批量。

❌ 误区3：「开了 Hermes，性能就不需要再管了」

Hermes 解决启动速度，不解决运行时的 JS 逻辑卡顿。一个 while(true) 死循环在 Hermes 上一样卡死 JS 线程。运行时性能优化（减少重渲染、避免耗时计算在主线程）仍然需要。

❌ 误区4：「性能优化是一次性的工作」

依赖升级（RN 大版本）、功能迭代（新增模块）、数据量增长（列表从 100 变 1000 条）都会让之前的优化失效。必须建性能基线和自动化回归——FlatList 的 onScroll 里打 FPS，CI 里对比构建前后的差异。

一句话总结

RN 性能优化没有银弹——先定位瓶颈线程，再对症下药：通信靠节流和原生驱动、列表靠定高和 memo、首屏靠 Hermes 和预加载，三条路一起走才能把「能用」变成「好用」。