📚 课程目录第3章 JS线程与UI线程协作机制

3. JS线程与UI线程协作机制

React Native 的性能问题，绝大多数最终都会落到同一个根因上：JS 线程与 UI 线程之间的协作效率。理解这两条线程如何分工、如何通过 Bridge 交换数据、以及数据在什么条件下会排队等待，是后续所有优化手段的基础。本节先讲清协作机制，再给出可落地的阻塞识别与任务拆分方法。

一、两条线程的分工与 Bridge 的角色

在 React Native 的运行时中，UI 线程（主线程）负责原生视图的创建、布局、绘制以及触摸事件的原始分发；JS 线程负责执行 React 组件渲染、业务逻辑、状态计算和事件回调。两者运行在独立的执行环境中，不能直接共享内存对象，所有跨线程调用都必须经过 Bridge 序列化传递。

Bridge 本质上是一条异步消息通道，它有三个关键特征：

序列化传输：JS 侧的对象会被序列化为 JSON 兼容结构，原生侧再反序列化。这意味着函数、类实例、循环引用无法直接传递，大对象会产生明显的序列化开销。
批量投递：Bridge 不会为每一次调用单独发一条消息，而是在一个事件循环批次内把多个调用打包成一批，统一发送。这就是“异步批处理”的来源。
单向队列：JS→原生与原生→JS 各自维护队列，队列中的消息按顺序处理，前一条消息处理不完，后面的消息只能等待。

因此，Bridge 的吞吐能力是有限的。当单位时间内产生的跨线程消息超过 Bridge 的处理速度，队列就会积压，表现为界面卡顿、触摸响应延迟、动画掉帧。

二、异步批处理：为什么“批量”既是优化也是陷阱

批处理的设计初衷是减少跨线程往返次数。假设一个列表渲染需要创建 50 个原生视图，如果每次创建都单独发一条消息，Bridge 要处理 50 次序列化和 50 次线程切换；批处理会把它们合并成一批，显著降低开销。

但批处理也带来两个副作用。第一，延迟不可控：一条消息进入队列后，必须等当前批次处理完才会被发送，如果前一批里有耗时任务，这条消息的响应就会被推迟。第二，顺序依赖：同一队列内消息严格按序处理，一个慢消息会阻塞它后面的所有消息。

实际开发中常见的错误是：在 onScroll 或 onLayout 这类高频回调里直接调用 setState 并触发原生测量。滚动事件每秒可能触发 60 次以上，每次都产生跨线程消息，队列很快被填满，滚动就开始卡。正确的做法是节流 + 合并：把高频输入压缩成低频输出，例如用 requestAnimationFrame 或时间戳判断，保证每帧最多处理一次。

// 高频滚动回调的节流合并示例
const lastRef = useRef(0);
const onScroll = (e) => {
  const now = Date.now();
  if (now - lastRef.current < 16) return; // 每帧最多一次
  lastRef.current = now;
  setOffset(e.nativeEvent.contentOffset.y);
};

三、线程阻塞识别：看什么指标、怎么定位

阻塞识别不能靠“感觉卡”，要落到可观测的信号上。常用的判断依据有三类：

帧率与掉帧：UI 线程每帧预算约 16.7ms（60fps）。如果连续多帧超过预算，说明主线程被长任务占用。可通过 Performance Monitor 观察 FPS 曲线是否出现规律性下探。
JS 线程帧耗时：在 Systrace / Perfetto 中查看 JS 线程的 slice 长度。单个 slice 超过 16ms 就值得关注，超过 50ms 基本可以判定为阻塞源。
交互响应延迟：点击按钮到界面反馈的时间。如果这个时间明显大于一帧，说明事件回调在 JS 侧排队，或 Bridge 队列积压。

定位时优先怀疑这几类代码：大数组的 map/filter/reduce 链式调用、深拷贝（JSON.parse(JSON.stringify())）、复杂正则、同步存储读写、以及一次性渲染超长列表。它们共同的特征是在 JS 线程上同步执行且耗时随数据量线性增长。

判断技巧：把可疑逻辑用 console.time / console.timeEnd 包起来，在低端机上跑一遍。如果单次执行超过 16ms，就应该考虑拆分或移出主流程。

四、任务拆分策略：把长任务切成可让出控制权的片段

拆分的目标不是“让任务变快”，而是让 JS 线程有机会在任务之间处理 Bridge 消息和渲染。常用策略有以下几种，按适用场景选择：

策略	适用场景	关键做法	注意事项
时间切片	大列表计算、批量数据转换	每处理 N 条后检查耗时，超过阈值就让出	需保存中间状态，逻辑要可中断
分帧渲染	长列表首屏	先渲染可视区，其余用 `InteractionManager` 延后	避免首屏白屏时间过长
虚拟化	超长列表	只挂载可视区域附近的 item	item 高度需可估算
Worker 卸载	纯计算、无 UI 依赖	把计算移到独立线程，结果回传	数据需可序列化
原生侧处理	图片解码、加密、文件 IO	交给原生模块异步执行	需维护原生模块接口

以时间切片为例，一个 5000 条数据的过滤任务可以这样拆：

function chunkedFilter(list, predicate, chunkSize = 500) {
  return new Promise((resolve) => {
    const result = [];
    let i = 0;
    function step() {
      const end = Math.min(i + chunkSize, list.length);
      for (; i < end; i++) {
        if (predicate(list[i])) result.push(list[i]);
      }
      if (i < list.length) {
        // 让出控制权，给 Bridge 和渲染留出时间
        setTimeout(step, 0);
      } else {
        resolve(result);
      }
    }
    step();
  });
}

这里每处理 500 条就让出一次，JS 线程得以处理积压的 Bridge 消息，UI 线程也能拿到新的帧。代价是总耗时略有增加，但交互流畅度明显改善。chunkSize 的选择需要权衡：太小会让出过于频繁，调度开销上升；太大则单次仍可能超过 16ms。一般从 200～500 开始试，结合低端机实测调整。

拆分不是万能的。如果任务本身依赖完整数据才能得出结果（例如全局排序），切片只能缓解卡顿，不能消除等待。此时应优先考虑把计算移到 Worker 或原生侧，或者改变交互设计，先展示部分结果。

五、协作机制下的优化原则

把以上内容收敛成几条可执行的原则：

减少跨线程消息数量：合并高频调用，避免在滚动、布局回调里直接触发原生操作。
控制单条消息体积：只传必要字段，避免把整个大对象塞进 Bridge。
保证 JS 线程可让出：任何可能超过 16ms 的同步逻辑都要考虑切片或异步化。
区分阻塞来源：先判断是 JS 线程长任务还是 UI 线程长任务，再选择对应手段，不要盲目加 setTimeout。
用数据验证：优化前后对比 FPS、JS 帧耗时和交互延迟，确认改动确实有效。

理解 Bridge 的队列模型和批处理行为后，你会发现很多“React Native 性能差”的抱怨，其实是在错误的位置做了错误粒度的工作。把长任务拆开、把高频消息合并、把重计算移出主线程，这三件事能解决大部分协作层面的卡顿问题。