React 与 移动端原生 API 的深度通信：通过 JSI 实现高性能状态共享

各位下午好，请坐。

我知道你们在看幻灯片的时候在想什么。你们在想：“React Native？那是两年前的技术了吧？现在 Flutter 都成第一了，还有什么好聊的？”

停。把你的那个“Flutter 太快了所以 RN 已死”的念头先收一收。作为一个在移动端混迹了十年的老兵，我得告诉你们一个残酷的真相：移动端开发的鄙视链，从来都不是 Flutter vs RN，而是“高性能原生” vs “所有其他”。

很多所谓的“高性能”应用，表面上是 React Native 写的，底层却藏着一个个沉默的原生怪兽。它们怎么跟 JS 层说话的？靠那个古老的、像是在慢悠悠喝粥一样的 Bridge（桥接） 吗？

今天，我们就来聊聊怎么把那个慢吞吞的桥给拆了，用 JSI（JavaScript Interface） 搭建一条高速公路，实现 React 与原生 API 的深度通信。准备好了吗？我们要去“底层”探险了。

---

第一部分：那个让你深夜痛哭的“桥”

在讲 JSI 之前，我们必须先重温一下 React Native 的“原罪”——Bridge。

Bridge 是一个什么东西呢？你可以把它想象成一个勤劳但极其低效的信使。它住在 JS 线程和原生线程之间。

流程是这样的：

1. JS 侧：NativeModules.MyModule.doSomething(123);
2. JS 侧：把数字 123 转换成 JSON 字符串 "{"value": 123}"。这个过程叫序列化。
3. Bridge：把这个 JSON 字符串通过对象传递给 Native 侧。
4. Native 侧：收到字符串，解析 JSON。这个过程叫反序列化。
5. Native 侧：执行原生的 doSomething 方法。
6. Native 侧：把结果再包一层 JSON。
7. Bridge：传回 JS 侧。
8. JS 侧：再次解析 JSON，拿到结果。

朋友们，如果是发一封邮件，这没问题。但是，如果你每秒钟要发 60 封邮件呢？或者你要做高帧率的动画，每帧都要跨桥传数据呢？

这就像是在两个人之间放了一块磨盘。 每次通信，数据都要经过磨盘的碾压（序列化/反序列化），还要经过信使的搬运（线程切换）。你的 JS 代码在 CPU 上飞快地执行，结果原生代码还在那儿慢条斯理地解析字符串。结果是什么？掉帧。 UI 卡顿。用户体验崩盘。

React Native 0.60 以后引入了 TurboModules，它试图解决这个问题，但它依然是在“优化”桥接。而今天我们要聊的 JSI，是直接把桥给抽走了，直接在内存里握手。

---

第二部分：JSI 是什么？它是怎么工作的？

JSI（JavaScript Interface）是 React Native 内部的一个原生库。它的核心思想非常简单粗暴：直接暴露原生代码的内存给 JavaScript 引擎。

JSI 让 C++ (或者 Java/Kotlin/Swift/Obj-C) 可以直接访问 JavaScript 对象。这意味着什么？

意味着 0 序列化，0 拷贝。

当你在 JS 侧写 myObj.myProp = 123 时，JSI 允许你直接修改原生内存中的对象，而不需要把整个对象转成 JSON 再转回来。这就像是你直接拥有了那个对象的钥匙，而不是每次都要去配一把新的钥匙。

JSI 的底层依赖的是 V8 (Chrome) 或者 Hermes (React Native 默认)。V8 和 Hermes 都允许从 C++ 层直接操作 JS 的堆内存。

所以，当我们说“通过 JSI 实现深度通信”时，我们实际上是在做两件事：

1. JS -> Native：JS 调用原生 C++ 函数，传递原生对象。
2. Native -> JS：原生 C++ 创建 JS 对象，或者直接修改 JS 中的变量。

---

第三部分：实战！如何用 JSI 写一个原生插件

我们要写一个插件，叫 PerformanceTimer。这个插件不干别的，就是算时间。但我们要在 C++ 层用 std::chrono 精确计时，然后通过 JSI 把结果毫秒不差地传回给 React 组件。

这听起来很简单，对吧？但如果你用旧的方法，这得写几百行桥接代码。用 JSI？一行代码搞定。

第一步：C++ 层（iOS 以 Objective-C++ 为例）

首先，我们要创建一个类，继承自 turbo_module::JSI::NativeModule。等等，这个路径有点长，我们简化一下。在 React Native 的最新架构（Fabric + Turbo Modules）中，我们通常定义一个 C++ 类，并将其注册到 Runtime 中。

看下面这段代码，它是老派（但依然有效且高性能）的 JSI 使用方式，也是很多高性能库（如 Lottie）的底层实现逻辑。

// NativePerformanceModule.mm
#import <jsi/jsi.h>
#import <react-native/ReactNative.h>
#import <CoreFoundation/CoreFoundation.h>

// 1. 定义我们的 C++ 类
class NativePerformanceModule : public facebook::jsi::HostObject {
public:
    NativePerformanceModule(facebook::jsi::Runtime &runtime) {
        // 初始化时获取当前时间戳
        currentTimestamp_ = getCurrentTimestamp();
    }

    // 2. 实现索引操作符 [this][index]
    // 当 JS 写 obj['getTime'] 时，调用这个方法
    facebook::jsi::Value get(facebook::jsi::Runtime& runtime, const facebook::jsi::PropNameID& name) {
        // 把 JS 的字符串转成 C++ 字符串
        std::string key = name.utf8(runtime);

        if (key == "getCurrentTimestamp") {
            // 返回一个 JS 函数给 JS 侧调用
            return facebook::jsi::Function::createFromHostFunction(
                runtime,
                name,
                0, // 参数个数
                [this](facebook::jsi::Runtime& runtime, const facebook::jsi::Value& thisValue, const facebook::jsi::Value* args, size_t count) -> facebook::jsi::Value {
                    // C++ 层的高性能计算逻辑
                    uint64_t time = getCurrentTimestamp();

                    // 直接返回数字给 JS，不需要 JSON 序列化！
                    return facebook::jsi::Value(static_cast<double>(time));
                });
        }

        throw facebook::jsi::JSError(runtime, "Unknown method: " + key);
    }

private:
    uint64_t currentTimestamp_;

    uint64_t getCurrentTimestamp() {
        struct timeval tv;
        gettimeofday(&tv, NULL);
        return (uint64_t)tv.tv_sec * 1000 + (uint64_t)tv.tv_usec / 1000;
    }
};

// 3. 注册函数：创建一个全局对象，暴露给 JS
void install(facebook::jsi::Runtime& runtime) {
    // 在 JS 的全局对象上挂载一个属性叫 'NativePerformance'
    // React Native 启动时会调用这个 install 函数
    auto performanceModule = std::make_shared<NativePerformanceModule>(runtime);

    runtime.global().setProperty(
        runtime,
        "NativePerformance",
        facebook::jsi::Object::createFromHostObject(runtime, performanceModule)
    );
}

看懂了吗？没有 JSON，没有反射，没有复杂的桥接协议。 这就是 JSI 的魅力。我们直接创建了一个 JS 函数，并在它背后挂载了一个 C++ 函数。当 JS 调用 NativePerformance.getCurrentTimestamp() 时，直接跳转到了 C++ 代码执行，没有任何中间商赚差价。

第二步：在 React Native (JS) 侧调用

现在，你可以在你的 App.tsx 里这样写了。注意看，这跟普通的 NativeModules 调用几乎一模一样，但性能完全不同。

// App.tsx
import React, { useState, useEffect } from 'react';
import { NativePerformance } from './NativePerformance'; // 假设你封装了一个桥接层

const App: React.FC = () => {
  const [time, setTime] = useState<number>(0);

  // 模拟一个高频调用的场景
  useEffect(() => {
    const interval = setInterval(() => {
      // 哇！这一行代码现在快得像闪电
      NativePerformance.getCurrentTimestamp().then((timestamp: number) => {
        setTime(timestamp);
      });
    }, 16); // 大约 60 FPS

    return () => clearInterval(interval);
  }, []);

  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text style={{ fontSize: 24 }}>
        JSI 下的高性能时间戳: {time}
      </Text>
    </View>
  );
};

export default App;

如果你在控制台里看，你会发现这个 setInterval 调用的开销几乎可以忽略不计。如果你用的是旧的 Bridge 调用，每秒钟 60 次序列化开销就已经能让你掉好几个帧了。

---

第四部分：不仅仅是函数调用，而是状态共享

JSI 的强大之处不仅仅在于调函数。刚才那个例子太简单了，甚至不需要 JSI，TurboModules 也能搞定。

真正的 深度通信，是指 双向、异步、无锁的状态共享。

想象一个场景：你的 React Native 应用里有一个物理引擎（比如 Box2D）。JS 层（React）只负责渲染 UI，它根本不应该知道物理引擎内部是怎么算的。物理引擎在 Native 线程疯狂计算，每帧都在改变几百个物体的位置。

如果用 Bridge：

1. 物理引擎更新物体 A 的位置为 (100, 200)。
2. 生成 JSON：{"id": "A", "x": 100, "y": 200}。
3. 发送给 JS。
4. JS 接收，转成对象，调用 setNativeProps。
5. 更新 UI。

这一套下来，物理引擎的一帧可能都跑不完，UI 就卡死了。

用 JSI 呢？

我们可以让物理引擎直接在 C++ 内存里维护一个 std::vector<PhysicsBody>。当物理引擎算完一帧后，它不需要生成 JSON。它直接利用 JSI，找到对应的 JS 对象（比如那个 physicsBody 对象），直接修改它的属性。

// 在物理引擎的 C++ 循环中
void PhysicsEngine::update(facebook::jsi::Runtime& runtime, const facebook::jsi::Object& bodiesJsObject) {
    // 假设 bodiesJsObject 就是 React 侧传过来的对象引用
    // 里面可能包含 ["body1", "body2"]

    // 直接在 JS 对象上设置属性，不需要序列化！
    // 这是一个极快的内存操作
    bodiesJsObject.setProperty(runtime, "body1_x", facebook::jsi::Value(100.5));
    bodiesJsObject.setProperty(runtime, "body1_y", facebook::jsi::Value(200.5));

    // React 的 Proxy 或者 getter 会自动捕捉到这个变化并更新 UI
}

React 侧可以这样定义这个对象，利用 Proxy 来实现“React 响应式”和“原生状态”的同步。

// React 侧
const physicsBodies = useRef({});

useEffect(() => {
  // 注册一个 Proxy 来监听属性变化
  const handler = {
    set: (target, prop, value) => {
      // 当 C++ 修改了 physicsBodies.x 时，这里会自动触发
      // 你可以做更复杂的逻辑，比如保存到 Redux，或者标记需要重绘
      target[prop] = value;
      return true;
    }
  };

  physicsBodies.current = new Proxy({}, handler);

  // 把这个 Proxy 对象传给原生层
  NativePhysics.setBodies(physicsBodies.current);

}, []);

这种模式下，JS 和 Native 共享了一块内存区域。C++ 写了什么，JS 读到的一模一样。没有数据拷贝，没有格式转换。

---

第五部分：性能分析——为什么我们要这么做？

如果你们还在用 console.time('bridge') 测量你们的 NativeModules，我建议你们停手。JSI 的性能提升是指数级的，不是线性的。

为了直观感受，我们来做个“数据搬家”的实验。

场景 A：传一个包含 1000 个浮点数的数组。

• Bridge (JSON)：

  1. C++ 构造 1000 个 double。
  2. nlohmann::json 库把 1000 个 double 转成字符串（大约 20KB+）。
  3. 发送到 JS。
  4. JS 的 JSON.parse() 读取字符串，分配内存，转换成 Array。
  5. 耗时：~1.5ms – 3ms。

• JSI (Direct Memory)：

  1. C++ 构造 1000 个 double。
  2. 获取 JS 数组的指针。
  3. memcpy 或者直接遍历赋值。
  4. 耗时：~0.05ms – 0.1ms。

差距是 20 到 50 倍！

在 60 FPS 的游戏里，每帧只有 16ms。你花掉 2ms 做数据传输，剩下的 14ms 还能干嘛？充其量只能画几个像素。

而且，JSI 还有一个巨大的优势：线程安全。

JS 运行在 JS 线程，原生代码运行在 Main 线程或者单独的物理线程。Bridge 是通过队列传递消息的，天然是线程安全的。但 JSI 的内存操作如果不加锁，是会崩溃的。不过，React Native 的 Runtime 库通常提供了 acquireLock 和 releaseLock 的机制，或者我们可以利用 Isolate 的隔离特性来保证安全。

当我们使用 JSI 进行深度通信时，我们实际上是在构建一个 Multi-threaded Actor Model（多线程 Actor 模型）。原生层是 Actor，JS 层是另一个 Actor，它们通过 JSI 这条总线通信，而不需要通过笨重的消息队列。

---

第六部分：Lottie 是怎么做到的？

你们都用过 Lottie 吧？那个在 React Native 里播放 GIF 动画的神器。

为什么 Lottie 播放 100 个复杂动画依然能保持 60 FPS？

因为 Lottie 的底层核心就是 JSI。

当你在 JS 侧写 <LottieView source={...} /> 时，Lottie 并没有用 Bridge 去每一帧告诉原生层“播放第 20 帧”。
相反，它把动画数据（JSON）直接映射到了内存中，用 C++ 写了一个渲染引擎。渲染引擎每帧更新视图，通过 JSI 直接告诉 JS 引擎当前的状态，或者更常见的是，直接操作视图的属性（比如 transform，opacity），绕过了 Bridge。

这也就是为什么现在 React Native 的官方架构推荐使用 TurboModules。TurboModules 本质上就是 JSI 的标准封装。

---

第七部分：如何开始使用？不要只是看，要动手

如果你现在正看着这篇讲稿，手里拿着键盘，我想告诉你：不要怕 C++。

你不需要成为 C++ 大师才能用 JSI。React Native 提供了非常高级的封装。

1. 安装依赖：

   npm install react-native-jsi

   （注：实际使用中，你需要直接在 React Native 项目里创建 .cpp 文件，或者使用 react-native-community/cli 生成 C++ 模板）。

2. 创建 TurboModule：
   React Native CLI 可以帮你生成一个 C++ 模板。

   npx react-native createTurboModuleTemplate

   这会给你生成一个 MyTurboModule.cpp。在这个文件里，你就可以像我在第一部分展示的那样，直接写 jsi::Value 代码了。

3. 连接：
   在 JS 侧，你会得到一个 NativeMyTurboModule 实例。使用它！你会惊讶地发现，它调用的速度比以前快了不是一点点。

---

第八部分：陷阱与注意事项

虽然 JSI 很强大，但它是“核武器”，不是“瑞士军刀”。如果你滥用，你的应用会炸的。

1. 内存泄漏：
   JSI 允许你持有 JS 对象的引用。如果你在 C++ 里创建了一个对象，然后忘了释放，而 JS 侧也把这个对象扔了，你就造成了一个内存泄漏。JSI 的 GC（垃圾回收）机制跟 JS 的不一样，你需要手动管理 std::shared_ptr。

2. 类型转换：
   JS 是弱类型的，C++ 是强类型的。虽然 JSI 提供了很多转换函数，但在处理复杂的嵌套对象时，你可能会遇到类型不匹配的问题。

3. 调试困难：
   当你在 C++ 层打断点时，如果逻辑很深，你很难在 Chrome DevTools 里看到变量的具体值。这时候，你需要学会使用 std::cerr 或者 Xcode/Android Studio 的日志系统。

---

第九部分：总结——打破界限

今天我们聊了很多。

我们吐槽了那个慢吞吞的 Bridge，就像吐槽那个每次都要慢动作回放才能看清动作的拳击手。
我们介绍了 JSI，那是那一记直球，是瞬间移动。

通过 JSI，React Native 不再是 JS 去调用原生方法的工具，它变成了一个真正的混合应用架构。C++ 负责算（物理、图像、音频），JS 负责展示（UI、逻辑）。它们在内存里面对面坐着，交换眼神，传递信息，没有延迟，没有噪音。

这就是高性能状态共享的终极形态。

当你下次遇到“React Native 卡顿”或者“JSON 序列化太慢”的时候，别只想着优化你的 JS 代码。去原生层看看吧。 如果数据流在原生侧跑了一半，你就在原生侧把它截住，用 JSI 把它传给 JS。

记住，最好的优化是减少通信。 而减少通信的最快方式，就是消除通信。

好了，今天的讲座就到这里。我是你们的专家，现在，轮到你们去写那个 60 FPS 的物理引擎了。别搞砸了，我在源码里看着你们呢。

下课！