React Native中C++原生模块桥接与JSI桥接的差异及JSI性能优势探究

你提到的用react-native-builder-bob做C++桥接的方案，其实本质上还是基于React Native传统的桥接机制（也就是早期的Bridge模块），而JSI（JavaScript Interface）是React Native推出的更底层、更高效的JS与原生交互层，它带来的特性和性能提升主要体现在这几个方面：

一、直接跳过中间桥接层，实现JS与原生的无缝绑定 #

传统的C桥接方案，JS和C之间的通信还是要经过序列化/反序列化的步骤：比如你在JS里传一个对象，需要先把它转成JSON或者二进制格式，通过桥接传递到C侧后再解析成C的数据结构；反过来也是一样。这个过程不仅耗时，还会产生额外的内存开销。

而JSI允许C代码直接持有JS值的内存引用，你可以在C里直接调用JS函数、访问JS对象的属性、修改数组元素，完全不需要中间的序列化步骤。相当于JS和C++共享了同一份数据的访问权，省去了数据转换的所有开销。

二、支持同步调用，告别异步回调嵌套 #

传统桥接方案几乎都是异步的——因为JS线程和原生线程是分离的，通信必须通过跨线程消息队列，这就导致你必须用Promise或者回调来处理结果，代码逻辑容易变得嵌套复杂，而且每次异步调用都有线程上下文切换的开销。

JSI打破了这个限制：它支持在同一个线程中同步调用JS与原生代码。比如你在JS里调用一个JSI绑定的C++函数，可以直接拿到返回值，不需要等待异步回调。这不仅让代码逻辑更简洁，还避免了线程切换带来的性能损耗。

三、跨平台一致性与官方原生支持 #

虽然之前的C方案也能实现跨平台复用，但JSI是React Native官方推出的底层交互标准，它和JS引擎（比如现在默认的Hermes）的集成更紧密。你用JSI写的C模块，在Android和iOS上可以复用90%以上的代码，而且不需要分别针对Java/Kotlin、Objective-C/Swift写适配层，维护成本更低。同时，React Native的后续更新会优先对JSI方案做优化，兼容性和稳定性更有保障。

四、灵活扩展JS引擎能力 #

JSI允许你直接向JS引擎注入自定义的对象、函数，甚至可以实现自己的JS值类型。比如你可以在C里写一个高性能的计算模块，直接作为全局对象暴露给JS使用，而不需要通过桥接层做中转。这种灵活性是传统C桥接方案无法比拟的——传统方案只能基于现有的桥接API做交互，无法直接操作JS引擎的内部状态。

为什么JSI能带来性能提升？ #

核心原因就是消除了不必要的开销：

1. 序列化开销的消除：如前面所说，复杂数据的序列化/反序列化是传统桥接的最大性能瓶颈之一，JSI直接通过内存引用交互，完全跳过了这一步，数据处理速度能提升数倍，尤其是在传递大数组、复杂对象时效果更明显。
2. 线程切换的减少：同步调用避免了频繁的线程上下文切换，而JSI也支持更灵活的线程调度，你可以根据需求选择在JS线程还是原生线程执行代码，减少不必要的线程切换开销。
3. 与JS引擎的深度集成：JSI是Hermes引擎的核心组成部分，用JSI写的模块可以直接利用Hermes的底层优化，比如字节码直接执行、高效的内存管理，而传统C++桥接方案是基于上层API，无法触及这些底层优化点。

举个简单的例子：如果要在JS和C之间传递一个包含1000个元素的数组，传统桥接需要把数组转成JSON字符串（耗时+内存占用），C侧再解析成vector；而用JSI的话，C++代码可以直接遍历JS数组的引用，逐个读取元素，全程没有数据转换，性能差异非常明显。

内容的提问来源于stack exchange，提问作者Enzo Manuel Mangano