RN旧架构Bridge原理深度解析

一句话概括

RN 旧架构的 Bridge 就是一个”跨线程的异步 JSON 中转站”——JS 线程和原生线程不直接对话，所有通信都必须序列化成 JSON，通过一条共享的消息通道异步传递。这个设计在 2015 年是合理的，但到了今天，JSON 序列化开销 + 单通道阻塞 + 异步不阻塞这些”特性”，全都变成了”硬伤”。

核心知识点

1. 消息队列：Bridge 的核心机制

// Bridge 的本质：异步、批处理的消息队列
// JS 侧（简化）
class MessageQueue {
  constructor() {
    this._queue = []    // 待发送的调用
    this._callID = 0
  }

  // 调用原生模块 → 不会立刻执行，而是先入队
  callNativeModule(moduleID, methodID, params) {
    this._queue.push({ moduleID, methodID, params, callID: this._callID++ })
  }

  // 在每个事件循环末尾批量 flush：所有积压消息打包成一批
  flush() {
    const batch = this._queue.splice(0)
    if (batch.length === 0) return
    // 整个 batch 序列化成一个 JSON 字符串，一次性传给原生
    NativeModules.__batchedBridge(JSON.stringify(batch))
  }
}

一个完整的 Bridge 调用链路：JS call → 入队 → 批处理 flush → JSON.stringify → 跨线程传输 → JSON.parse → 查找模块 → 执行原生方法 → 如果有回调，整个过程再反向走一遍。这一来一回经过至少 4 次 JSON 序列化/反序列化。

2. 三线程模型：各自为政

RN 旧架构里三个线程分工：

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  JS Thread  │     │Shadow Thread│     │  Main Thread│
│  (JS代码)   │     │  (Yoga布局) │     │  (原生UI)   │
└──────┬──────┘     └──────┬──────┘     └──────┬──────┘
       │                   │                   │
       └───────────────────┼───────────────────┘
                           │
                    ┌──────┴──────┐
                    │   Bridge    │  ← 三条线都在争这一条通道
                    └─────────────┘

关键问题：Shadow 线程跑 Yoga 布局计算，但它既要从 JS 线程拿组件树（通过 Bridge），算完又要传给主线程渲染（还是通过 Bridge）。一次列表滚动可能产生上百条 Bridge 消息——JS 计算 diff → Bridge → Shadow 布局 → Bridge → Main 渲染，每一步都有延迟。

3. JSON 序列化：最隐蔽的性能杀手

// 为什么 JSON 序列化是 RN 最大的性能瓶颈？
// 来看一个 FlatList 渲染 100 条数据时发生了什么：

const items = Array.from({ length: 100 }, (_, i) => ({
  id: i,
  title: `Item ${i}`,
  subtitle: `Description for item ${i}`,
  imageUrl: `https://example.com/img/${i}.jpg`,
  price: Math.random() * 100,
  tags: ['tag1', 'tag2', 'tag3'],
}))
// 这 100 个对象 → JSON.stringify → 约 15KB 字符串
// 然后通过 Bridge 传给 Native
// Native 收到后 → JSON.parse → 重建 100 个对象
// 如果滚动时持续触发，每秒可能产生 200KB+ 的序列化吞吐

// 更糟糕的是——GC 压力
// stringify 创建大量临时字符串 → V8/Hermes 触发 GC
// GC 是 Stop-The-World 的 → JS 线程暂停 → UI 卡顿

三个连锁问题：① 数据被完整复制（没有零拷贝）② 类型信息丢失（Date 变字符串、undefined 变 null）③ GC 压力（临时对象大量产生导致频繁垃圾回收）。这就是为什么 RN 列表滚动时经常”卡一下”——不是渲染慢，是 GC 在运行。

4. 异步模型：表面上不阻塞，实际上不靠谱

// Bridge 调用是异步的——调完就忘记，结果通过回调回来
NativeModules.Calculator.add(1, 2)
// ❌ 不能这样用！这一行执行完，add 还没跑呢
console.log(result) // undefined！

// 只能用回调
NativeModules.Calculator.add(1, 2, (result) => {
  console.log(result) // 下一帧甚至几帧之后才拿到
})

// 动画里这个问题最致命：
// 手势拖动 → 每帧都需要最新的位置信息
// 但 Bridge 异步，JS 算完位置 → 发给原生 → 原生下一帧才用上
// → 视觉上就是"跟手性差"，因为原生总是用上一帧的数据在渲染

异步意味着每次交互都有 1-2 帧的延迟。动画 60fps 下每帧 16ms 预算，Bridge 一次来回就吃掉 3-5ms，留给实际渲染的时间所剩无几。

5. 新架构怎么解决的？（一句话版）

旧架构：JS → JSON → Bridge → JSON → Native  （拷贝，慢）
新架构：JS → JSI(C++ 引用) → Native         （引用，快）

JSI 的核心：让 JS 能直接持有 C++ 对象的引用
不再需要 JSON.stringify/parse
就像 Web Worker 从 postMessage 进化到 SharedArrayBuffer

TurboModules 按需加载（不再一次加载所有原生模块），Fabric 简化渲染管线（去掉 Shadow 线程），Codegen 编译时生成类型安全的接口代码——每一项都在修补 Bridge 留下的坑。

其实你每天都在用

1. NativeModules.xxx.yyy() 调用 → 背后全是 Bridge — 你调 NativeModules.CameraManager.takePicture()，实际走的是：参数序列化 → 入队 → flush → JNI/ObjC 桥 → 执行
2. RN Debug 模式更慢 → 因为 JS 跑在 Chrome 里，Bridge 要加一层 WebSocket — 消息路径变成了：JS → stringify → WebSocket → Chrome → WS → stringify → Bridge → Native，多了一趟网络往返
3. useNativeDriver: true 为什么动画流畅？→ 因为动画逻辑直接在原生线程跑，不需要走 Bridge — Animated API 的 useNativeDriver 就是把动画计算从 JS 线程”偷”到原生线程，彻底绕过 Bridge
4. FlatList 的 getItemLayout 为什么能优化？→ 跳过 JS 计算高度、跳过 Bridge 传输、原生直接用 — 每一项的高度 JS 不计算、不传输，原生直接布局
5. 模块热更新（CodePush）的原理 → 只替换 JS bundle，原生代码不变，但如果原生模块签名变了，Bridge 通信就炸 — Bridge 靠模块 ID 和方法 ID 匹配，bundle 变了可能导致 ID 错位

常见误解（FAQ）

❌ 误区：「Bridge 的异步设计是优点，不阻塞 UI」 异步本身不是问题，问题是异步 + 无优先级控制 + 共享单通道。所有 Bridge 消息（UI 更新、相机调用、网络回调）全挤在一条通道上，手势事件密集时 UI 更新被阻塞，”不阻塞 UI”变成了”随机延迟 UI”。新架构 JSI 虽然也异步，但有了优先级调度，关键帧优先。

❌ 误区：「只要不用原生模块，Bridge 就没有开销」 即使用纯 JS 组件，React 的渲染结果（虚拟 DOM → 原生 View 指令）也必须通过 Bridge 传输。每次 setState 触发的 UI 更新都在走 Bridge。具体路径：React diff → 生成 Shadow Tree 更新 → JSON 序列化 → Bridge → Shadow 线程 → Yoga 布局 → Main 线程渲染。纯 JS 操作只是省了「原生模块调用」这一层，渲染指令的 Bridge 传输省不掉。

❌ 误区：「Debug 模式慢只是因为手机性能差」 Debug 模式下 JS 跑在电脑的 Chrome 里，Bridge 通信多了一层 WebSocket。消息流变成：真机原生 → Bridge → JS bundle（在真机上）→ WebSocket → Chrome → JS 执行 → WebSocket → Bridge → 原生。多出来的网络往返延迟（即使 localhost）比 JSON 序列化还大一个数量级。

❌ 误区：「Hermes 引擎解决了 Bridge 的性能问题」 Hermes 优化的是 JS 侧的启动速度和内存占用，Bridge 的传输瓶颈（JSON 序列化、单通道、异步延迟）不受引擎影响。就像换了个更快的快递员，但配送路线和货车还是一样。

一句话总结

RN 的 Bridge 不是「设计缺陷」，而是 2015 年的「合理上限」；真正的问题在于前端对移动端性能的要求在十年里涨了十倍，而 Bridge 的架构容量没有跟着涨——JSI + Fabric + TurboModules 不是修修补补，是整个通信范式的推翻重来。