RN 新架构全量落地半年了，聊聊 Fabric、TurboModules 和那个消失的 Bridge

RN 新架构全量落地半年了，聊聊 Fabric、TurboModules 和那消失的 Bridge

React Native 的新架构喊了好几年，之前一直觉得是”未来可期”。但到了 2026 年中回头看，这件事已经彻底变了——RN 从 0.82 开始，旧架构连根拔了。如果你还在用 Bridge 那一套写 RN，是时候认真看看这个新架构到底长什么样了。

新架构到底多了什么

先别被 Fabric、TurboModules、JSI、Bridgeless 这一串名词吓到，其实新架构就干了三件事：

第一件事：把 Bridge 拆了。 旧架构里 JS 和 Native 通信全靠 Bridge——异步、序列化 JSON、丢来丢去。每次调用走一套”JS 序列化 → C++ 桥 → Native 反序列化 → 执行 → 再反序列化回来”的流程，单次延迟 5-15ms。

JSI（JavaScript Interface）直接把这条链路变成了 JS 和 Native 共享内存指针，Native 方法像调用本地函数一样直接。可以理解成原来两家中间有个翻译官，现在两边直接对话了。

// 旧 Bridge 模式：异步回调
NativeModules.CalcModule.add(2, 3, (result) => {
  console.log(result);
});

// JSI 模式：直接调
const result = await TurboModuleRegistry
  .get<CalcSpec>('CalcModule')
  .add(2, 3);

第二件事：重新做了渲染层。 Fabric 不是新的渲染引擎，它是新架构里 UI 渲染管线的代号。以前 Shadow Thread 算完布局往 UI Thread 丢也是一套 JSON 序列化，Fabric 直接拿 C++ 结构体跨线程传，Props 用扁平对象，计算量少了一个数量级。

第三件事：原生模块按需加载。 旧架构里所有 Native Modules 在 App 启动时全量注册，不管用不用都占内存。TurboModules 改成懒加载——用到哪个模块才真正初始化哪个。

三个改进合在一起，效果用一句人话总结就是：RN 终于不是”优雅但卡”了。

RN 0.82 是个分水岭

去年 10 月发布的 RN 0.82 是第一个完全砍掉旧架构的版本。官方拿 Expensify 测试的数据挺实在的：

这些数据看着不算夸张，但要知道 0.82 之前很多项目就已经跑在新架构上了。等于是把”兼容模式”删掉后，纯新架构的基准性能。

另外 0.82 同步推了 Hermes V1 编译器，结合 AOT 字节码预编译，冷启动时间能砍 30-50%。

但最有意思的数字不是基准测试——我在团队的实际项目里做了对比，一个带长列表和交互动画的页面：

• 旧架构（RN 0.66 + Bridge）: 平均帧率 45-50fps，列表快速滑动偶发掉到 30fps
• 新架构（RN 0.82 + JSI + Fabric）: 平均帧率 55-60fps，快速滑动基本不掉

说起来只有 10fps 的差距，但实际体感是”能用了”和”还挺丝滑”的区别。

迁移不是一键搞定，但有套路

如果你的项目还在 RN 0.70 以下，迁移到新架构确实要费点功夫。我踩过几个坑，直接记下来：

1. Native Modules 全部要写 Spec

Codegen 会根据 TypeScript 的 Spec 文件自动生成跨语言的胶水代码。参数类型必须限制在 string、number、boolean 和扁平对象，Date、Map、Set 这些没法直接映射到 C++ 的类型得自己转。

// RepoDetailModule.spec.tsx
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface RepoDetailResult {
  readonly fullName: string;
  readonly description: string | null;
  readonly stars: number;
  readonly forks: number;
  readonly language: string | null;
}

export interface RepoDetailSpec extends TurboModule {
  getCachedDetail(fullName: string): Promise<RepoDetailResult | null>;
  fetchDetail(fullName: string): Promise<RepoDetailResult>;
}

export default TurboModuleRegistry.register<RepoDetailSpec>(
  'RepoDetailModule',
  (rawModule) => rawModule,
);

2. Fabric 组件的 Props 不能传函数

这是 Fabric 的硬约束——Props 必须可序列化成 C++ 结构体。以前喜欢把 onPress 当 prop 传的做法要改成收事件系统。

// ❌ 旧写法：Prop 传函数
<MyButton onPress={() => handleClick()} />

// ✅ 新写法：通过事件系统
<MyButton
  onPress={event => handleClick(event.nativeEvent)}
/>

3. 第三方库的适配状态

到 2026 年中，主流社区库基本都适配了新架构。react-native-gesture-handler、react-native-reanimated、react-native-fast-image 这些大库在 2.0+ 版本都原生支持 Fabric。少数小众库如果还没适配，可以检查它们的 package.json 里有没有 codegenConfig。

4. 渐进式迁移的坑

如果你的 App 既有 New Architecture 模块又有旧 Bridge 模块，RN 0.76+ 提供了一个兼容层来自动降级。但注意：Bridge 代理层有额外开销，混合使用的时候新架构的性能优势会打折扣。最好定一个截止时间，集中把旧模块清掉。

值得关注的其他变化

新架构落地后，RN 生态还有几个趋势值得留意：

React Native Web + 新架构 RNGH（React Native Gesture Handler）全面支持 Fabric 后，Web 端的手势体验也提升了一大截。跨端项目用同一套手势逻辑不再是做梦。

热更新依然是杀手锏 跟 Flutter 那种编译成机器码的方案不同，RN 的 JS Bundle 热更新机制在新架构下依然完好。国内互联网场景下，CodePush 或自建热更新服务仍然是对抗审核周期的利器。

Expo 的门槛持续降低 Expo SDK 52-54 的迭代对新架构的支持越来越完整。如果你的项目是绿场启动，从 Expo 起步基本把原生配置的痛全避开了。

所以要不要升

如果你是新项目：直接上 RN 0.82+，新架构默认开启，没理由回头。

如果你是老项目：分两种情况—— – 如果还在 RN 0.66 以下，先升级到 0.72 左右，把社区库适配好后，再跳到 0.82 启用新架构，一步到位容易炸。 – 如果已经在 0.74-0.78 区间，可以直接冲 0.82，社区库适配度已经很高了。

总体来说，RN 新架构不是噱头，它是实打实的底层重写。2015 年生的 React Native，十一岁的时候终于把”慢”这个标签撕掉了。