本文对 React Native 中 JS 与原生线程通信的桥接机制进行详细解析，结合技术实现与架构演进，涵盖传统 Bridge、JSI/TurboModules 与 Fabric 的改进点及实际使用注意事项。
一、传统架构中的 Bridge 机制
线程模型与通信基础
- 双线程架构： JS 线程（处理业务逻辑）与原生线程（处理 UI 渲染）独立运行，通过 JSON 序列化的消息进行通信。
- 消息队列： JS 与原生端的交互通过异步消息队列实现，调用指令会被序列化为 JSON 格式并通过 Bridge 传递。
通信流程示例
// JS 端调用原生模块
NativeModules.Camera.takePhoto(options);
- JS 层： 生成包含
moduleName、methodName、params的 JSON 消息。 - Bridge 序列化： 通过 MessageQueue 将消息编码为字符串并发送给原生端。
- 原生层： 原生模块通过
RCT_EXPORT_METHOD注册方法，接收反序列化后的参数并执行相应操作。 - 结果回传： 原生端执行结果再次通过 Bridge 返回给 JS 线程（通常是通过回调、Promise 或事件）。
性能瓶颈
- 序列化开销： 在高频通信场景下（例如滚动列表事件）JSON 的编解码会消耗大量性能。
- 线程阻塞风险： JS 线程与原生线程互相等待可能导致卡顿，尤其是在大量、频繁的跨线程调用下。
二、通信模型关键技术
异步通信模型
- 单向数据流： JS 线程通常通过 Bridge 发起调用，原生端可以通过
RCTEventEmitter向 JS 推送事件。 - 批量处理优化： Bridge 会将多个操作合并为一次消息传递以减少通信频率与开销（batching）。
模块注册机制
- 原生模块发现： 模块在启动时通过
RCT_EXPORT_MODULE或相关宏/注解注册，框架在启动阶段建立模块映射表。 - 方法动态绑定： 使用
RCT_EXPORT_METHOD将原生方法暴露为 JS 可调用接口，运行时通过映射表完成方法调用分发。
三、新架构中的改进（JSI 与 TurboModules）
JSI（JavaScript Interface）
- 直接内存访问： JSI 允许 JS 与原生通过 C++ 层进行更接近原生的交互，消除 JSON 序列化步骤。
- 同步调用支持： 在需要时可以进行同步调用（例如某些布局计算或测量 API），从而减少异步回调的复杂性与延迟。
TurboModules 机制
- 按需加载： 模块在首次调用时初始化，降低启动时的内存与时间开销。
- 类型安全： 通过 Codegen 生成强类型接口（通常是基于 IDL/注解生成的绑定代码），减少运行时错误与反射开销。
Fabric 渲染引擎
- 跨线程同步： UI 操作指令可以通过更低延迟的通道（结合 JSI）传递，减少传统 Bridge 的序列化与队列延迟。
- 优先级调度： 对触摸事件等高优先级操作实现优先处理与插队机制，以改善交互流畅性。
四、技术演进对比
| 特性 | 传统 Bridge | JSI + TurboModules |
|---|---|---|
| 通信方式 | 异步 JSON 消息 | 直接内存访问 / 本地调用 |
| 序列化开销 | 高（JSON 编解码） | 无或极低 |
| 线程模型 | 强制跨线程调用 | 允许同线程或更灵活调用 |
| 模块初始化 | 启动时加载所有模块 | 按需懒加载 |
| 类型安全 | 运行时检查 | 编译时生成类型约束 |
五、实际应用注意事项
- 避免高频通信：对如滚动、触摸等高频事件使用本地节流/去抖或通过
nativeEvent传递必要信息，尽量减少跨桥调用次数。 - 线程敏感操作：耗时的原生操作应在后台线程执行，避免阻塞 UI 与 JS 主线程。
- 使用调试工具：使用 Flipper 的 “Native Modules” 面板或其它诊断工具跟踪模块调用、事件与性能瓶颈。
- 选择合适的架构：对于需要频繁同步交互或低延迟的场景，优先考虑 JSI/TurboModules 与 Fabric 的方案；对于兼容性和迁移成本较高的项目，可逐步迁移或混合使用。
参考与延伸阅读（可选）
- 官方文档：React Native 官方关于 [TurboModules、JSI 与 Fabric] 的文章与 RFC
- 社区实现与示例：许多开源库展示了如何基于 JSI 实现高性能原生模块
- 性能分析：使用性能分析工具（例如 Flipper、Android Systrace、Instruments）定位跨桥开销
