引言
上一次写RN还是五年前，最近看到有了新架构，并且核心痛点始终围绕"JS与原生通信的性能损耗"------老架构依赖JSON序列化的异步桥接层，导致数据转换耗时、UI卡顿等问题。2026年，RN新架构（Fabric + TurboModules）已成为主流，其核心突破点是JSI（JavaScript Interface）------一套打通JS与C++的内存级接口，彻底重构了JS与原生的通信链路。本文将从底层原理出发，对比老架构JSON桥与新架构JSI的核心差异，结合执行流程拆解JSI的工作机制。
一、老架构：JSON桥接层的"低效通信"
1.1 核心原理
老架构的通信核心是"异步JSON桥"，JS与原生无法直接交互，所有调用都需经过"JSON序列化→异步队列→JSON反序列化"的链路，本质是"文本级间接通信"。
1.2 执行流程（Sequence Diagram）
Native OS (iOS/Android) C++ JSON桥接层 TypeScript (JS Realm) Native OS (iOS/Android) C++ JSON桥接层 TypeScript (JS Realm) 阶段一：运行时调用（异步执行） 将参数序列化为JSON字符串 {"a":1,"b":2} alt Android 平台 iOS 平台 全程异步，需等待队列调度 调用 NativeModules.MyModule.add(1, 2) 1 解析JSON，放入异步消息队列 2 异步分发JSON参数到原生线程 3 Java/Kotlin 解析参数并执行add方法 4 ObjC/Swift 解析参数并执行add方法 5 返回结果3，序列化为JSON {"result":3} 6 异步回调，反序列化JSON返回结果 7
1.3 核心痛点
- 序列化损耗：JS对象与原生数据的双向JSON转换占总调用耗时的60%以上，复杂数据（如列表、对象嵌套）损耗更明显；
- 异步队列阻塞：所有调用需排队执行，UI渲染相关的原生调用易被耗时操作阻塞，导致界面卡顿；
- 数据拷贝：JSON序列化本质是数据拷贝，内存占用高，频繁调用易引发移动端内存告警。
二、新架构：JSI的"内存级直连通信"
JSI是RN新架构的核心，本质是一套C++编写的通用接口，让JS引擎（Hermes/JSC/V8）能直接持有C++函数的内存引用，跳过JSON序列化，实现"内存级直连通信"。
2.1 核心执行流程（初始化+运行时）
Native OS (iOS/Android) TurboModule (C++ 适配层) JSI (C++ Interface) TypeScript (JS Realm) Native OS (iOS/Android) TurboModule (C++ 适配层) JSI (C++ Interface) TypeScript (JS Realm) 阶段一：初始化 (App 启动时) 此时 JS 全局对象中有了直接指向 C++ 内存的指针 阶段二：运行时调用 (同步执行) 不再序列化 JSON，直接通过引用调用 指针跳转 (Pointer Jump) alt Android 平台 iOS 平台 全程同步，无异步等待 初始化原生模块 1 创建 Host Object (C++ 对象) 2 注入 Host Object 的引用 (内存地址) 3 调用 global.MyModule.add(1, 2) 4 触发 C++ 层的 add 函数 5 通过 JNI 调用 Java/Kotlin 方法 6 直接调用 ObjC/Swift 方法 7 返回结果 (例如: 3) 8 将结果转换为 JSValue 9 返回 3 10
2.2 流程拆解
阶段一：初始化（App启动时）
- 原生模块初始化 ：App启动后，iOS/Android原生模块先完成初始化，注册可对外暴露的方法（如
add）； - C++适配层创建Host Object：TurboModule（C++适配层）将原生方法封装为标准C++函数，生成对应的Host Object（C++对象）；
- 注入内存引用到JS ：JSI将Host Object的内存地址注入到JS全局对象中（如
global.MyModule），此时JS端直接持有C++函数的内存指针，而非"方法名字符串"。
阶段二：运行时调用（同步执行）
- JS直接调用C++引用 ：JS端调用
global.MyModule.add(1, 2)时，无需序列化参数，直接通过内存指针触发C++层函数； - C++层转发到原生 ：
- Android平台：C++适配层通过JNI（Java Native Interface）直接调用Java/Kotlin方法；
- iOS平台：C++适配层直接调用ObjC/Swift方法（Objective-C++兼容特性）；
- 结果直返JS：原生执行结果返回给C++层后，直接转换为JS可识别的JSValue，通过JSI返回给JS端，全程无数据拷贝、无异步等待。
三、老架构VS新架构：核心差异对比
| 对比维度 | 老架构（JSON桥） | 新架构（JSI） |
|---|---|---|
| 通信本质 | 文本级（JSON字符串）间接通信 | 内存级（指针）直接通信 |
| 参数传递方式 | JS对象→JSON字符串→原生解析对象 | JS对象→内存指针→C++直接读取 |
| 调用方式 | 仅异步（依赖消息队列） | 同步/异步可选（默认同步） |
| 数据拷贝次数 | 至少2次（JS→JSON、JSON→原生） | 0次（内存直访） |
| 性能损耗核心 | JSON序列化/反序列化（占比60%+） | 仅函数调用基础开销（可忽略） |
| 跨平台适配层 | 无（JS直接对接OC/Java） | C++适配层（统一双端调用标准） |
| UI卡顿风险 | 高（队列阻塞） | 低（同步调用无等待） |
四、JSI的核心价值与落地意义
- 性能质变：剔除JSON序列化这个最大性能瓶颈后，RN原生调用耗时降低80%以上，列表滑动、原生组件渲染等场景接近原生应用流畅度；
- 调用模式灵活：同步调用解决了老架构中"UI渲染与原生调用时序不一致"的问题，异步调用可按需用于耗时操作（如网络请求）；
- 跨平台统一：C++适配层屏蔽了iOS/Android原生API的差异，让RN的跨平台能力从"JS层"下沉到"C++层"，降低原生模块开发成本。
总结
- RN新架构的核心优化是通过JSI实现"JS-C++内存直连"，彻底抛弃了老架构的JSON序列化链路；
- JSI并非直接暴露原生API内存地址，而是通过C++适配层实现JS与原生的安全、统一通信；
- 同步调用、零数据拷贝是JSI带来的核心性能提升点，也是2026年RN新架构成为主流的核心原因。