React Native 新架构完全指南：Fabric、TurboModules 与 Bridgeless 模式实战（2026）

最后更新：2026 年 6 月 8 日

React Native 新架构（New Architecture）是 Meta 在 2024 年底随 React Native 0.76 默认启用的全新底层渲染与通信体系，由 JSI（JavaScript Interface）、Fabric 渲染器、TurboModules 与 Codegen 四大支柱组成，并通过 Bridgeless 模式彻底移除了过去依赖异步桥（Bridge）的瓶颈。结果是更低的启动延迟、同步原生调用、并发渲染，以及与 React 19 完全对齐的 Suspense / Transition 行为。我自己去年把一个三年龄的 App 迁过来，启动时间确实掉了一大截，不过坑也踩了不少。本文以 2026 年 RN 0.79 为基准，带你完整理解新架构原理、迁移流程，并附上 TurboModule 与 Fabric Native Component 的可运行代码。

• 自 React Native 0.76（2024 年 10 月）起，新架构是默认架构；0.79（2026）开始旧架构进入弃用倒计时，仅作迁移兼容保留。
• 新架构的四大支柱：JSI 替代 Bridge 提供同步直接调用，Fabric 是新的并发渲染器，TurboModules 提供按需加载的原生模块，Codegen 在编译期生成类型安全胶水代码。
• Bridgeless 模式下，所有 JS↔Native 通信不再经过序列化的异步消息队列，启动时间在中端 Android 设备上平均缩短 25 到 40%。
• 新架构与 Hermes 引擎、React 19 的 useTransition、Suspense 边界深度集成，并发特性才真正可用。
• 迁移核心三步：升级到 RN 0.76+、为自定义原生模块编写 spec TypeScript 接口、运行 codegen 生成绑定。
• Expo SDK 52+ 已对新架构提供一键开关（"newArchEnabled": true），多数主流第三方库已完成兼容。

什么是 React Native 新架构？

说白了，React Native 新架构是 Meta 为解决旧架构（俗称"桥架构"）十年来的根本性性能瓶颈而设计的全面重构。它不是单一功能，而是一整套互相耦合的底层系统。JSI（JavaScript Interface）让 JS 引擎可以直接持有 C++ 宿主对象的引用、同步调用其方法；Fabric 是用 C++ 重写的并发渲染器，让 RN 终于可以利用 React 18/19 的并发模式；TurboModules 是按需懒加载、类型安全的新原生模块系统；Codegen 则负责从 TypeScript 接口生成 Java/Kotlin 与 Objective-C++ 胶水。

从开发者视角，新架构最直观的变化是 Bridgeless 模式。你的 JS 代码不再把参数 JSON.stringify 后塞进消息队列等待原生侧异步处理，而是直接拿到一个原生函数的引用并同步调用。这意味着 measure()、scrollTo() 这类历来"为什么不能立刻拿到布局值"的 API 终于可以同步返回。如果你之前读过我们的 FlatList vs FlashList v2 性能对比，会注意到 FlashList v2 本身就是为新架构而设计，它的同步 autoSizing 算法只有在 Bridgeless 下才能跑出宣称的性能。

为什么要从旧桥架构迁移？

旧架构的根本问题是异步、批量、序列化的"桥"（Bridge）。每一次 JS 调用原生（例如 NativeModules.MyModule.doSomething(arg)）都必须：把参数序列化成 JSON 字符串、放入消息队列、等待原生线程出队、反序列化、执行、再把结果序列化回来。老实说这套流程在 2015 年很合理，但到 2024 年已经撑不住现代 UI 的要求了。它导致几个臭名昭著的问题：

• 启动慢：所有原生模块在启动时被一次性枚举与初始化，即使绝大多数本次会话根本用不到。
• 无法同步读值：UIManager.measure 必须用回调，组件 ref 上没有可用的同步几何信息。
• 大对象抖动：传输大型数据（如二进制 buffer、长 list）需要完整 JSON 序列化，CPU 与 GC 开销巨大。
• 不兼容并发渲染：旧的 Java/Obj-C 渲染流水线假设单一同步提交，无法支持 React 18 的中断式渲染与优先级调度。

新架构在每一项上都给出针对性的答案。JSI 消除序列化、TurboModules 让原生模块懒加载、Fabric 支持优先级调度。React Native 官方架构总览给出了详细的设计文档，建议先扫一遍再读下文，对术语会更有概念。

JSI 与 Bridgeless 模式详解

JSI 是新架构的灵魂。它是一个轻量的 C++ 抽象层，定义了"JS 引擎"应当对外暴露的能力，例如 jsi::Object、jsi::Function、jsi::HostObject。Hermes、JavaScriptCore、V8 都实现了它。最关键的是 HostObject：一个 C++ 类可以被包装成 JS 对象，JS 侧拿到的就是一个普通对象，但每次访问属性都会触发同步的 C++ 回调。

下面是一个最小可运行的 JSI 模块（C++ 端），它向 JS 暴露一个同步的 multiply 函数：

// MyJsiModule.cpp
#include <jsi/jsi.h>
using namespace facebook;

void installMyModule(jsi::Runtime &rt) {
  auto multiply = jsi::Function::createFromHostFunction(
    rt,
    jsi::PropNameID::forAscii(rt, "multiply"),
    2,
    [](jsi::Runtime &rt, const jsi::Value &, const jsi::Value *args, size_t) -> jsi::Value {
      double a = args[0].asNumber();
      double b = args[1].asNumber();
      return jsi::Value(a * b);
    });
  rt.global().setProperty(rt, "__myMultiply", std::move(multiply));
}

JS 端调用 global.__myMultiply(6, 7) 会立刻拿到 42，没有任何序列化或线程切换。Bridgeless 模式就是把整个 RN 运行时建立在 JSI 之上：UIManager、Timer、AsyncStorage 替代品、事件分发，全部都是 JSI HostObject 或 HostFunction。

Fabric 渲染器如何工作

Fabric 是 RN 视图层的彻底重写，目标是支持 React 18+ 的并发渲染。它把过去散落在 Java/Obj-C 的"shadow tree → 布局 → mounting"流程统一搬到 C++，于是同一份 C++ 代码可以在 Android 与 iOS 共享，差异只剩平台原生视图的最终挂载。

Fabric 的关键概念：

• Shadow Tree（影子树）：React 渲染输出在 C++ 侧构建的不可变树，承载 props 与布局信息。
• Yoga 3：跨平台的 Flexbox 布局引擎，2025 年升级到支持 display: 'contents' 与 aspect-ratio 完整规范。
• Mount Layer：把 Shadow Tree 的 diff 应用到真实 UIView / android.view.View。
• Concurrent rendering：React 可以在低优先级渲染中途让步给用户输入，Fabric 不会把"半成品"提交给原生侧。

Fabric 还启用了 Synchronous Layout Effects，useLayoutEffect 在 RN 里终于和 Web 行为一致。这对实现自定义滚动联动、共享元素过渡至关重要。如果你结合我们 Reanimated 4 动画指南里的 worklet 模式，会发现 Reanimated 4 之所以能去掉 runOnUI 中间层，正是因为它直接坐在 Fabric 的同步提交流水线上。

TurboModules 与 Codegen 实战

TurboModules 是新架构下定义"自定义原生模块"的方式。和旧的 NativeModule 相比，它有三大优势：懒加载（只有 JS 首次访问时才实例化）、同步调用（通过 JSI）、类型安全（Codegen 从 TS 生成 Java/ObjC 接口签名）。

定义流程分三步。首先在 specs/NativeDeviceMeta.ts 写一个 spec 文件：

// specs/NativeDeviceMeta.ts
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  // 同步：直接返回字符串，不再需要 await
  getDeviceId(): string;
  // 异步：返回 Promise，仍然支持
  getBatteryLevel(): Promise<number>;
  // 常量：编译期写入
  readonly getConstants: () => {
    isTablet: boolean;
    osVersion: string;
  };
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceMeta');

然后在 package.json 里告诉 Codegen 去扫描这个 spec：

{
  "codegenConfig": {
    "name": "RNDeviceMetaSpec",
    "type": "modules",
    "jsSrcsDir": "specs",
    "android": { "javaPackageName": "com.example.devicemeta" }
  }
}

最后实现 Android 端（Kotlin）：

// android/src/main/java/com/example/devicemeta/DeviceMetaModule.kt
package com.example.devicemeta

import android.os.Build
import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.Promise

class DeviceMetaModule(ctx: ReactApplicationContext) :
    NativeDeviceMetaSpec(ctx) {     // ← 由 Codegen 生成的基类

  override fun getName() = "DeviceMeta"

  override fun getDeviceId(): String =
      Build.MANUFACTURER + "-" + Build.MODEL

  override fun getBatteryLevel(promise: Promise) {
    val bm = reactApplicationContext.getSystemService(BATTERY_SERVICE) as BatteryManager
    promise.resolve(bm.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY) / 100.0)
  }

  override fun getConstants(): MutableMap<String, Any> = mutableMapOf(
      "isTablet" to (reactApplicationContext.resources.configuration.smallestScreenWidthDp >= 600),
      "osVersion" to Build.VERSION.RELEASE
  )
}

iOS 端写法对应 Objective-C++ 或 Swift 上的 RCT_EXPORT_METHOD，签名同样由 RNDeviceMetaSpec.h 强制约束。签名不对，编译期就报错，旧架构那种"忘了在 Bridge 上注册"的运行时崩溃彻底消失。我上次迁一个旧的位置模块，本来预期半天，结果 Codegen 提前抓出两个参数类型不匹配，省下了至少一晚的真机调试。

编写 Fabric Native Component

原生视图（如自定义地图、视频播放器）走的是 Fabric Native Component 流程。它和 TurboModule 类似，也是用 TS spec + Codegen，但生成的是 ViewManager 与 Shadow Node。下面是一个最小的彩色方块组件：

// specs/ColorSwatchNativeComponent.ts
import type { ViewProps } from 'react-native';
import type { ColorValue } from 'react-native';
import codegenNativeComponent from 'react-native/Libraries/Utilities/codegenNativeComponent';

export interface NativeProps extends ViewProps {
  color?: ColorValue;
  cornerRadius?: Float;
}

export default codegenNativeComponent<NativeProps>('ColorSwatch');

JS 侧像用普通组件那样：<ColorSwatch color="#ff5577" cornerRadius={12} style={{ width: 80, height: 80 }} />。Codegen 会为你生成 Android 的 ColorSwatchManagerDelegate 与 iOS 的 RCTColorSwatchComponentView 抽象基类，你只需实现具体的属性赋值。React Native New Architecture 工作组仓库里有完整的 starter 模板，照着抄基本能跑。

在现有项目中启用新架构

对于 RN 0.79+ 的全新项目，新架构默认开启，无需任何配置。对存量项目：

1. 升级到 React Native 0.76 或更新，并把 Hermes 设为 JS 引擎（hermesEnabled=true）。
2. Android：android/gradle.properties 设 newArchEnabled=true。
3. iOS：RCT_NEW_ARCH_ENABLED=1 bundle exec pod install。
4. Expo 项目：在 app.json 加 "expo": { "newArchEnabled": true }，然后 npx expo prebuild --clean。
5. 清理 node_modules 与原生构建产物：rm -rf node_modules ios/Pods android/build && npm install。

启动 App 时打开 React Native DevTools，会看到一行 Bridgeless: true / Fabric: true。这就是切换成功的标志。如果还看到 false，八成是某个老 podspec 缓存没清干净，重跑一次 prebuild 通常就好了。

迁移检查清单与常见坑

多数公开的第三方库已经在 2025 年完成迁移，但你仍要逐个核对。常见坑包括：

• 直接操作 NativeModules：旧的 NativeModules.MyModule.foo() 调用在 Bridgeless 下会返回 undefined。改用 TurboModuleRegistry。
• setNativeProps：在 Fabric 下完全移除，必须改用受控 props + state。
• findNodeHandle：仍可用但已被标记 deprecated，使用 ref 上的 measure、focus 等方法。
• Animated.event 的 useNativeDriver: false：在 Fabric 下性能反而比新架构原生驱动差，迁移到 Reanimated 4 的 worklet 模式。
• ViewManager 中持有的 ReactContext：Bridgeless 下 context 生命周期变了，必须用弱引用避免泄漏。
• 事件命名：自定义事件必须以 on 开头并与 spec 中类型一致，否则不会触发。

这一条 setNativeProps 我自己被坑过一次。我们有个老的进度条组件直接调它来避免 React 重新渲染，迁到 Fabric 后视图原地冻结，控制台没任何报错，花了大概一小时才反应过来。官方维护了一份 第三方库兼容性矩阵，包含 Reanimated、Gesture Handler、Skia、Vision Camera 等常用库的最低适配版本，开工前务必先查一遍。

性能基准与真实数据

根据 Meta 与社区 2025 年下半年公开的基准（Pixel 7、iPhone 14、release 模式），新架构带来的提升大致如下：

指标	旧架构（Bridge）	新架构（Bridgeless）	变化
冷启动到首帧（中端 Android）	1.9 s	1.2 s	−37%
JS→Native 单次调用延迟	0.6 ms（异步）	0.02 ms（同步）	−97%
1000 行长列表内存占用	118 MB	74 MB	−37%
原生模块初始化时间	启动期一次性	按需懒加载	启动 −60%
支持并发渲染（Suspense / Transition）	否	是	新能力

这些数字也意味着，状态管理库（如我们在 Zustand v5 + MMKV 持久化指南里推荐的组合）在新架构下的优势更明显。MMKV 通过 JSI 直接读取，读一个键值对的开销从约 0.4 ms 降到几乎不可测，这在启动期批量恢复 store 的场景里能省下肉眼可见的一帧。

常见问题

React Native 新架构什么时候成为默认？

React Native 0.76（2024 年 10 月发布）是首个默认开启新架构的稳定版本。0.79（2026 年）开始官方文档不再示范旧架构，第三方库新版本陆续放弃对桥模式的支持。

新架构需要重写整个应用吗？

不需要。React 层代码几乎零修改，需要工作量的是自定义原生模块（迁移到 TurboModules）和自定义原生视图（迁移到 Fabric Native Component）。多数项目实际迁移耗时在 2 到 5 天。

Expo 用户需要做什么？

Expo SDK 52 及以上版本在 app.json 加 "newArchEnabled": true，然后运行 npx expo prebuild --clean 即可。Expo Go 客户端自 SDK 53 起默认运行在新架构下。

Hermes 引擎是必需的吗？

强烈推荐但非强制。JSC（JavaScriptCore）也实现了 JSI，因此理论可用，但 Meta 优先优化 Hermes，且 Bridgeless 模式下 Hermes 的启动时间比 JSC 快约 30%。

如何确认我的 App 真的在 Bridgeless 模式运行？

在 JS 里执行 global.RN$Bridgeless === true，或在 React Native DevTools 面板顶部查看 "Bridgeless: true / Fabric: true" 状态栏。Android 还可以查看 Logcat 中的 ReactInstance 行确认 ReactHost 类型。