37.2.3 React Native与原生桥接：RN与原生端通信事件机制

可视化演示

演示RN与原生端的通信机制：JS Bridge序列化消息传递、事件订阅模式与JSI直连的延迟差异。

Bridge 桥接机制

想象一家跨国公司的两个分部：JS 分部只讲 JavaScript 语，负责界面逻辑和业务编排；原生分部只讲 Java/Objective-C 语，掌管摄像头、定位、文件系统等“硬技能”。两个分部位于大洋两岸，既不能直接对话，也不能共享办公室，一切协作都只能通过公司内部唯一的“桥接邮局”——Bridge——来完成。邮局的吞吐效率，就是两个分部协作效率的天花板。

在 React Native 的架构里，Bridge 就是这座邮局。JS 跑在一个独立的 JavaScriptCore（或 Hermes）运行时里，原生代码跑在各自平台的运行时里，两者完全隔离，互不感知。任何一次跨端请求，都必须先写成一封“标准信件”——一个 JSON 格式的消息对象——才能投递给对方。这套设计让两端彻底解耦、互不阻塞，但也意味着每一次协作都要走完整的“写信—寄信—收信”流程，产生肉眼不可见但真实存在的时延。

Bridge 自 2015 年随 RN 发布以来，一直维护着 JS 调用原生的消息队列、原生回调 JS 的队列以及事件消息队列。所有消息都被序列化为 JSON 字符串，通过桥接线程异步搬运。端到端总时延可以写成四个环节的叠加：

这座“邮局”奠定了 RN 的一切能力基础，却也埋下了性能隐患。后续所有架构演进，本质上都是在优化这四个环节中的某一个。

消息传递流程

现在把镜头拉近，看一封“跨洋信件”从 JS 分部寄到原生分部的完整旅程。写信人（JS 代码）要先确认三件事：寄给哪个部门（模块 ID）、办什么业务（方法 ID）、附上什么材料（参数）。邮局工作人员把这些信息严格填入标准表单，投进待发邮箱。

在代码层面，当 JS 调用原生模块方法时，React Native 的 MessageQueue 并不会立即把请求发出去，而是先构造一条消息：模块 ID + 方法 ID + 参数 + 回调 ID，然后推入 JS 侧消息队列。队列不会逐条投递，而是攒到一定数量或到达特定时机后，才批量打包发送给原生线程。这个过程在通信事件机制里叫“队列批量发送”。

原生端收到一批消息后，逐条反序列化并执行相应的原生方法；执行完毕，把结果连同回调 ID 一起回传到 JS 侧队列，JS 侧根据回调 ID 找到最初的调用点，触发回调或 resolve Promise。消息在队列里堆积得越多，整体等待越久：

就像发往同一城市的信件会凑成一麻袋统一装车，批量确实节省了运输成本；但一旦赶上“双十一”，分拣中心信件堆积成山，每一封的等待时间反而暴涨。RN 开发者遇到的许多卡顿，根源往往不是原生执行得慢，而是“邮局门口堵车了”。

事件订阅机制

上面的流程都是 JS 主动“寄信”给原生。但原生想主动通知 JS 怎么办？比如网络从 Wi-Fi 切到 5G，或后台下载完成——总不能等 JS 每隔一秒“查岗”。原生分部于是建了一座“广播电台”：它发射信号（事件名 + 数据），JS 分部只需要订阅收听即可。

这套广播收听的机制，在 RN 里由 NativeEventEmitter 和 DeviceEventEmitter 提供。原生模块像电台一样广播事件，JS 端通过 addListener 注册监听回调。当事件消息通过桥接到达 JS 侧时，RN 根据事件名查表，找到对应的监听器列表并逐个调用回调。这就是事件订阅模式的核心。

事件机制有两个坑。第一，事件消息同样要走 Bridge，仍然有序列化和排队开销；第二，JS 端必须手动维护监听生命周期。组件卸载时若忘记 removeListener，监听器会继续残留在事件表里，形成“幽灵订阅”——这是内存泄漏的经典来源：

这就像搬家后忘了向广播电台退订，电台依然每天往旧地址寄节目单。回调对象永远不会被回收，App 越用越臃肿，最终被系统“制裁”。记住通信事件机制的铁律：注册与释放，永远成对出现。

通信性能瓶颈

为什么老一代 RN 在列表快速滚动或频繁交互时会明显卡顿？回到邮局场景：每一封信都要手工誊写（序列化），高峰期排长队（队列积压），邮路还只有一条（单线程桥接）。业务量小的时候游刃有余，流量一大，瓶颈立刻现形。

从工程角度，传统 Bridge 的延迟主要来自四个方面。一是序列化开销随消息体量线性增长；二是高频小消息让队列频繁批处理，排队时延被不断拉高；三是单条大消息会长时间独占桥接线程；四是 JS 线程与原生线程之间的切换本身也有成本。其中序列化开销是最大的元凶。

把 JS 对象转成 JSON 字符串、再把字符串解析回原生对象，这个过程的 CPU 消耗与负载大小成正比：

传一个 10 字节的小参数，开销只有几十微秒；但若把整张图片的 base64（几百 KB）塞进桥，一次序列化就能让 UI 线程明显掉帧。这正像邮局里每封信都要称重贴票、录入系统，碰到一个“巨大的包裹”，整个柜台都要被占用很久。于是设计师开始思考：与其让所有业务挤在一条邮路上，不如给关键部门装一部“直拨电话”。

TurboModule 改进

面对邮局拥堵，管理层推出的第一轮改革叫 TurboModule——相当于把旧邮局升级成现代化快递分拣中心：寄件人不再手写地址，而是用电子面单（接口定义）自动录入；不再每次都在柜台翻箱倒柜找收件人，而是事先建好客户档案（模块常驻引用）。

TurboModule 是 RN 新架构的四大支柱之一。旧版 Bridge 中，JS 每次调用原生模块，都要在模块表里动态查找、组装消息、装箱拆箱。TurboModule 则通过 Codegen 代码生成器，在构建期就根据接口定义生成类型安全的胶水代码，JS 端持有原生模块的常驻引用，调用时直接进入原生方法，省去了大量动态查找和类型转换操作。

结合前面的时延模型，TurboModule 的收益可以这样量化：

TurboModule 还支持懒加载：JS 端第一次真正用到某个模块时才初始化，App 启动时不再把几百个原生模块全部加载一遍。从旧邮局到现代化快递中心，TurboModule 确实让“寄件”快了不少，但它仍然没有根治问题——信件该序列化还是序列化，该排队还是排队。真正釜底抽薪的，是下一轮通信架构的革命。

JSI 新架构

如果说传统 Bridge 是邮局，那么 JSI（JavaScript Interface，JavaScript 接口层）就是两个分部之间拉起的“直拨专线”。不需要写信，不需要寄件，不需要邮车——两个部门的人拿起电话就能直接通话，甚至可以把同一份文件同时摊在两张桌子上看。

JSI 是 RN 新架构的底层基石，取代了旧的 Bridge 通信通道。它提供了一层轻量级 C++ 接口，让 JavaScript 引擎可以直接持有原生 C++ 对象的引用，并直接调用其方法。对象引用直接传递，不再需要 JSON 序列化和反序列化；调用既支持异步，也支持同步执行。

在 JSI 模式下，前文的时延模型被大幅改写：

从“跨洋寄信”到“专线通话”，JSI 让 JS 与原生不再是两个只能靠邮局沟通的孤岛，而更像是同一间办公室里随时可以转头讨论的同事。当然，专线电话需要铺设光缆——JSI 引入了大量 C++ 代码，性能提升背后是复杂度的上升。理解这层取舍，才是真正的架构智慧。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-# 简化模拟: RN Bridge 的消息队列批量发送与事件订阅/释放import jsonfrom collections import deque  class BridgeSimulator:    """模拟传统 Bridge: 消息批量入队/批量发送, 支持事件订阅与释放"""     def __init__(self, batch_size=5):        self.call_queue = deque()       # 待发送的调用消息队列        self.listeners_map = {}         # 事件名 -> 回调函数列表        self.batch_size = batch_size    # 每次批量发送的消息条数        self.next_callback_id = 0       # 回调 ID 自增器        self.total_calls = 0            # 累计调用计数     def call_native(self, module_id, method_id, args, callback):        """JS 端发起调用: 序列化后入队, callback 等待原生回传结果"""        msg = {            "module_id": module_id,            "method_id": method_id,            "args": args,            "callback_id": self.next_callback_id,        }        self.call_queue.append(json.dumps(msg))  # 模拟 JSON 序列化        self.next_callback_id += 1        self.total_calls += 1        callback("ok")     def flush(self):        """原生端批量取出消息并反序列化, 模拟批量发送"""        batch = []        while self.call_queue and len(batch) < self.batch_size:            raw = self.call_queue.popleft()            batch.append(json.loads(raw))  # 模拟反序列化        return batch     def emit_event(self, event_name, data):        """原生端广播事件: 给所有订阅者投递消息, 模拟 NativeEventEmitter"""        if event_name not in self.listeners_map:            return        payload = json.dumps({"event": event_name, "data": data})        for callback in list(self.listeners_map[event_name]):            callback(payload)     def add_listener(self, event_name, callback):        """JS 端添加监听, 等价 NativeEventEmitter.addListener"""        self.listeners_map.setdefault(event_name, []).append(callback)     def remove_listener(self, event_name, callback):        """JS 端移除监听, 等价 NativeEventEmitter.removeListener"""        if event_name in self.listeners_map:            self.listeners_map[event_name].remove(callback)  def on_network_change(raw):    msg = json.loads(raw)    print("收到事件: {} -> {}".format(msg["event"], msg["data"]))  def main():    bridge = BridgeSimulator(batch_size=3)    # JS 端订阅事件    bridge.add_listener("networkChange", on_network_change)     # JS 端发起两次原生调用    bridge.call_native("NetInfo", "getStatus", [], lambda r: print("回调:", r))    bridge.call_native("Camera", "open", {"mode": "photo"}, lambda r: print("回调:", r))     # 原生端批量处理队列    batch = bridge.flush()    print("原生批量处理 {} 条消息:".format(len(batch)))    for msg in batch:        print("  - module={} method={}".format(msg["module_id"], msg["method_id"]))     # 原生端主动广播事件    bridge.emit_event("networkChange", {"online": True, "type": "wifi"})     # JS 端取消订阅: 注册与释放必须成对    bridge.remove_listener("networkChange", on_network_change)    bridge.emit_event("networkChange", {"online": False})  # 不再有任何输出  if __name__ == "__main__":    main()

1. self.call_queue.append(json.dumps(msg))模拟 JS 端调用原生时，把消息序列化为 JSON 字符串后投入桥接队列。
2. batch = bridge.flush()模拟原生端一次性从队列中批量取出多条消息进行处理。
3. json.loads(raw)模拟原生端反序列化 JSON，恢复出模块 ID、方法 ID 和参数。
4. bridge.add_listener("networkChange", on_network_change)等价于 RN 中 NativeEventEmitter 的 addListener，注册事件回调。
5. self.listeners_map.setdefault(event_name, []).append(callback)按事件名维护监听器列表，事件到达时按列表分发。
6. bridge.remove_listener("networkChange", on_network_change)模拟 removeListener 手动释放监听，防止泄漏。

常见误区

面试题