React Native调用原生功能的核心要点解析

React Native 调用原生功能：从桥接到 JSI 的深度实践

你有没有遇到过这样的场景？

• 用户点击“扫码”按钮，页面卡顿半秒才打开相机；
• 实时传感器数据在 JS 层抖动严重，像打了马赛克；
• 上传图片时内存飙升，甚至触发 OOM（内存溢出）；

这些问题的根源，往往不在于 JavaScript 写得不好，而在于JS 与原生之间的通信方式出了问题。

React Native 的魅力在于“一次学习，随处编写”，但它的边界也正藏在这句口号背后——JavaScript 永远无法直接操控硬件。要调用摄像头、读取传感器、处理蓝牙数据？必须跨过那道关键的鸿沟：原生层。

本文不讲基础 API 怎么用，而是带你穿透表象，看清 React Native 与原生交互的底层逻辑。我们将从最经典的 Bridge 架构出发，一步步走到如今性能飞跃的 TurboModules 和 JSI，解析每一个环节的设计取舍，并告诉你：什么时候该用什么方案，以及为什么。

原生模块不是魔法，是精心设计的“胶水”

我们常说“写一个原生模块”，听起来很高大上，其实它本质上就是一个“翻译官”：把 JS 的请求转成原生能听懂的话，执行完再把结果翻译回去。

以 Android 为例，想获取电池电量，Java 层可以轻松拿到系统广播：

Intent intent = registerReceiver(null, new IntentFilter(Intent.ACTION_BATTERY_CHANGED)); int level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);

但这段代码 JS 完全看不见。为了让 JS 能调用它，我们需要做一个“包装类”：

@ReactModule(name = "BatteryManager") public class BatteryModule extends ReactContextBaseJavaModule { @Override public String getName() { return "BatteryManager"; } @ReactMethod public void getBatteryLevel(Promise promise) { // 上面那段获取电量的逻辑... promise.resolve(batteryPercentage); } }

就这么简单？没错。加上@ReactMethod注解的方法，就会被自动注册到 JS 可访问的名单里。

JS 端只需要这样调用：

const { BatteryManager } = NativeModules; const level = await BatteryManager.getBatteryLevel();

看似轻描淡写的一行await，背后却经历了一场跨越线程的长途旅行。

Bridge：异步消息队列撑起的通信世界

那么，这行await到底发生了什么？

答案是：Bridge。

React Native 启动时，会扫描所有标记为@ReactModule的类，收集它们的方法名和参数信息，然后告诉 JS 引擎：“这些模块你可以调用了”。

当你在 JS 中写下BatteryManager.getBatteryLevel()时，实际流程如下：

1. JS 线程将调用封装成一条消息：
   { module: 'BatteryManager', method: 'getBatteryLevel', args: [] }
2. 这条消息被序列化为 JSON 字符串；
3. 通过 C++ 层转发到原生线程；
4. 原生侧反序列化，查找对应模块和方法；
5. 执行 Java/Kotlin 或 Objective-C/Swift 代码；
6. 结果再次打包，沿原路返回；
7. JS 收到响应，resolve Promise。

整个过程就像两个人隔着一堵墙传纸条，不能面对面说话，只能靠写信来回沟通。

三个线程，各司其职

• JS Thread：跑 JavaScript，别让它忙；
• UI Thread：负责渲染界面，绝对不能卡；
• Native Modules Thread：处理原生逻辑，通常是线程池中的某个 worker。

默认情况下，@ReactMethod是异步执行的，不会阻塞 UI。这是安全的默认选择。

性能瓶颈在哪？

虽然 Bridge 解耦了两端，但也带来了四个主要开销：

其中最致命的是高频小数据调用。比如每 10ms 发一次加速度计数据，每次只传三个数字。看起来数据量很小，但频繁地走完整个 Bridge 流程，CPU 很快就被调度开销吃光了。

📌 经验法则：如果每秒跨桥超过 30 次，就要警惕性能问题。

如何避免掉进 Bridge 的“慢车道”？

面对 Bridge 的固有限制，聪明的做法不是硬扛，而是绕开。

✅ 最佳实践一：批量传输，减少调用次数

假设你要上传一批传感器采样点：

❌ 错误做法：

for (let point of data) { NativeModules.Sensor.record(point.x, point.y, point.z); // 每次都跨桥！ }

✅ 正确做法：

// 聚合成数组一次性发送 NativeModules.Sensor.recordBatch(data.map(p => [p.x, p.y, p.z]));

哪怕只是把 100 次调用合并成 1 次，也能让性能提升一个数量级。

✅ 最佳实践二：只传路径，不传内容

图片、音频这类大文件，绝不能 base64 编码后塞进 Bridge！

❌ 危险操作：

const base64 = await FileSystem.readAsStringAsync(uri, { encoding: 'base64' }); NativeModules.ImageProcessor.process(base64); // 几 MB 数据跨桥 → 卡死

✅ 安全做法：

NativeModules.ImageProcessor.process(uri); // 只传文件路径

原生端拿着 URI 自己去读磁盘，效率高得多，还省内存。

✅ 最佳实践三：原生端聚合事件，定时上报

对于实时性要求高的场景（如陀螺仪），应在原生端做缓冲：

List<WritableMap> buffer = new ArrayList<>(); @ReactMethod public void startGyroscope() { sensorManager.registerListener(listener, sensor, SENSOR_DELAY_FASTEST); } SensorEventListener listener = event -> { WritableMap data = Arguments.createMap(); data.putDouble("x", event.values[0]); data.putDouble("y", event.values[1]); data.putDouble("z", event.values[2]); buffer.add(data); if (buffer.size() >= 50) { emitBatch("gyroData", buffer); buffer.clear(); } };

这样原本每 5ms 一次的调用，变成了每 250ms 一次批量推送，系统负载大幅下降。

主动通知：原生如何“叫醒”JS？

除了 JS 主动调用原生，还有很多时候需要反过来：原生主动通知 JS。

比如定位更新、网络状态变化、后台任务完成等事件。

这就需要用到事件发射机制。

Android 示例：位置变更事件

public class LocationModule extends ReactContextBaseJavaModule { @ReactMethod public void startLocationUpdates() { LocationListener listener = location -> { WritableMap event = Arguments.createMap(); event.putDouble("latitude", location.getLatitude()); event.putDouble("longitude", location.getLongitude()); getReactApplicationContext() .getJSModule(DeviceEventManager.class) .emit("locationChanged", event); }; // 启动 GPS... } }

JS 端监听：

import { NativeEventEmitter, NativeModules } from 'react-native'; const eventEmitter = new NativeEventEmitter(NativeModules.LocationModule); const subscription = eventEmitter.addListener('locationChanged', (e) => { console.log('新位置:', e.latitude, e.longitude); }); // 记得销毁！否则内存泄漏 return () => subscription.remove();

⚠️ 特别注意：必须手动移除监听器，否则即使页面关闭，事件仍会被持续接收，造成内存泄漏。

新架构登场：TurboModules + JSI，打破性能天花板

如果说 Bridge 是一辆稳重的老式客车，那TurboModules + JSI就是一辆高速磁悬浮列车。

传统 Bridge 的根本问题是：每次通信都要拷贝数据、序列化、跨线程传递。这个模型注定了它的延迟下限在毫秒级。

而 TurboModules 的核心武器是：JSI（JavaScript Interface）。

JSI 到底强在哪？

JSI 允许原生代码直接持有 JS 对象的引用，无需序列化，也不依赖 Bridge 队列。

这意味着：

• 方法调用可以直接执行，延迟降至微秒级；
• 数据可以共享内存，不再需要复制一份；
• 支持同步调用，且不会卡主线程（因为共享运行环境）；

更厉害的是，接口由 TypeScript 定义，通过 Codegen 自动生成原生代码，实现真正的跨平台类型安全。

接口即契约：用 TS 定义原生能力

// NativeBatteryManager.ts import type { TurboModule } from 'react-native/Libraries/TurboModule/RCTExport'; import { TurboModuleRegistry } from 'react-native'; export interface Spec extends TurboModule { getBatteryLevel(): Promise<number>; addListener(eventName: string): void; removeListener(eventName: string): void; } export default TurboModuleRegistry.get<Spec>('BatteryManager');

你写的这个.ts文件，不仅是文档，更是生成 iOS/Android 原生模板的蓝图。一旦定义好，三端接口完全一致，编译期就能发现类型错误。

性能对比：Bridge vs TurboModules

在我们的实测项目中，将地图 SDK 的坐标转换逻辑从 Bridge 迁移到 TurboModule 后，帧率从 48fps 提升至 58fps，触控响应明显更跟手。

架构演进：现代 React Native 应用长什么样？

一个典型的采用新架构的 App，其结构已经完全不同：

+------------------+ +---------------------+ | React Native | <===→ | TurboModules | | (JS Layer) | | (iOS/Android Native)| +------------------+ +---------------------+ ↑ ↑ ↑ | | JSI 直接内存访问 | 系统 API | ↓ ↓ | +------------------+ +------------------+ +—| Fabric Renderer | | Device Hardware | | (原生 UI 管道) | | (Camera, GPS...) | +------------------+ +------------------+

关键变化：

• JSI 替代 Bridge：不再是“发消息”，而是“直接调用”；
• Fabric 渲染器：UI 更新也走 JSI，彻底摆脱 Bridge 的渲染瓶颈；
• Codegen 统一接口：TS 定义驱动多端实现，保障一致性；
• 按需加载：模块不再启动时全量注册，降低冷启动时间。

实战建议：什么时候该用哪种方案？

🟢 推荐使用 TurboModules 的场景：

• 高频调用（>30次/秒）
• 实时性强（如游戏、AR、传感器）
• 复杂对象传递（避免序列化损耗）
• 团队有能力维护新架构配置

🟡 可继续使用传统 Bridge 的场景：

• 功能简单、调用稀疏（如弹窗、分享）
• 第三方库尚未支持 New Architecture
• 项目处于维护阶段，无升级动力

🔴 绝对禁止的行为：

• 在 Bridge 中传递大图或音视频数据（应传 URI）
• 忘记移除事件监听导致内存泄漏
• 在 UI 线程执行耗时原生操作（必须异步）

写在最后：从“会用”到“精通”的分水岭

掌握原生通信机制，是区分普通 RN 开发者与高级工程师的关键。

很多人只会调NativeModules.xxx()，出了性能问题就归咎于“RN 不行”。但真正的问题往往出在如何使用上。

当你开始思考：
- 这个调用走的是 Bridge 还是 JSI？
- 参数要不要拆分？能不能合并？
- 数据是不是可以在原生端处理完再给 JS？
- 有没有必要自己写一个 TurboModule？

你就已经走在通往精通的路上了。

随着 React Native 新架构的逐步成熟，TurboModules 将成为标配。现在投入时间学习，未来半年到一年内就会显现出巨大优势。

毕竟，跨平台开发的终极目标从来都不是“凑合能用”，而是既要开发效率，也要原生体验。

而这道桥梁，终究要靠我们亲手搭建。