RN 新架构到底牛在哪？一张图看懂「砍线程、省 Bridge、帧率拉满」

新旧架构的核心区别

“新架构把原来基于 Bridge 的异步 JSON 通信，变成了基于 JSI 的同步直接调用，并拆掉了启动时全量初始化、按需加载模块”。
下面从 6 个维度把差异展开说明。

维度	旧架构（≤0.67）	新架构（Fabric + TurboModules）
通信模型	Bridge：JS → JSON → 原生，异步、串行、易阻塞	JSI：JS 直接持有 C++ HostObject 引用，可同步调用
渲染管线	JS 线程 → Shadow 线程 → UI 线程；批量提交，瀑布式延迟	Fabric 在 C++ 侧维护 ShadowTree，支持增量、并发渲染，接近 60 fps
原生模块加载	启动时一次性初始化全部 Native Modules，无论是否用到	TurboModules 按需懒加载，首次调用时才初始化，启动时间显著缩短
线程模型	JS / Shadow / UI 三线程，频繁跨线程通信	去掉 Shadow 线程，JS 与 UI 线程可直接同步交互
类型安全 & 开发体验	手写桥接代码，易出类型不匹配；调试靠远程 JS 调试	Codegen 自动生成类型安全的绑定代码；Flipper 调试链路更清晰
性能表现	长列表滚动、手势动画易掉帧；内存占用高	首屏、滚动、动画更接近原生；Hermes + 懒加载内存更低

一句话总结：
旧架构像“通过服务员点菜的餐厅”，新架构像“顾客直接走到开放式厨房现场沟通”，少了中间人、少了等待，也少了浪费。

新旧架构对比

下面给你 2 张「官方风格」的示意图，左侧为旧架构（≤0.67），右侧为新架构（Fabric + TurboModules）。
可直接保存到本地，也可复制进文档/讲义使用。

---

1. 整体通信与渲染流程对比

┌─────────────────────────────────────────────────────────────┐
│         旧架构（Bridge）                                  新架构（Fabric + TurboModules）
│                                                             │
│  JS Thread                                                  JS Thread
│     │                                                          │
│     │  1. JSON 序列化                                         │  1. JSI 直接调用
│     ▼                                                          ▼
│ ┌─────────┐                                                ┌─────────┐
│ │ Bridge  │ 2. 异步队列                                     │  JSI    │
│ └─────────┘                                                └────┬────┘
│     ▲                                                          │
│     │ 3. JSON 反序列化                                        │ 同步
│     ▼                                                          ▼
│ Shadow Thread                                             C++ ShadowTree
│     ▲                                                          │
│     │ 4. 计算布局                                             │ 5. 增量/并发
│     ▼                                                          ▼
│   UI Thread                                               UI Thread
│                                                             │
│  5. 批量提交 → 掉帧                                         60 fps 无阻塞
└─────────────────────────────────────────────────────────────┘

---

2. 原生模块加载对比

┌──────────────────────────────────────────────────────────────┐
│             旧架构（TurboModules 之前）                     新架构（TurboModules）
│                                                              │
│  App 启动                                                    App 启动
│     │                                                           │
│     ▼                                                           ▼
│ ┌───────────────┐ 一次性                                      ┌───────────────┐
│ │ 所有 Native   │ 初始化                                      │ 按需懒加载    │
│ │ Modules       │                                             │ 首次调用时    │
│ └───────────────┘                                             │ 才 init       │
│     │                                                           │
│  长白屏/高内存                                                首屏更快/省内存
└──────────────────────────────────────────────────────────────┘

---

3.线程模型对比

旧架构是「JS → Shadow → UI」三层跨线程、异步串行；新架构是「JS ↔ UI」两层、直接同步，并可并发调度。

维度	旧架构（≤0.67）	新架构（Fabric + TurboModules）
线程数量	3 条： 1. JS Thread 2. Shadow Thread（布局） 3. UI/Main Thread	2 条： 1. JS Thread 2. UI/Main Thread（Shadow Thread 被合并到 C++ 侧）
通信链路	JS → JSON → Bridge → Shadow → UI，异步串行	JS ↔ UI，JSI 直接指针调用，可同步
并发能力	无；Shadow 线程与 UI 线程串行执行，易阻塞	支持 React 18 并发特性：中断渲染、优先级调度
同步读取布局	做不到；必须等 Shadow → UI 批量提交完成	可以，UI/Main Thread 与 JS Thread 可同步读布局
事件循环	无明确事件循环，任务按 FIFO 在 Bridge 排队	实现标准事件循环，可按优先级插队处理事件
线程切换开销	多次：JS ↔ Shadow ↔ UI，每次都要序列化/反序列化	最少一次：JS ↔ UI，零序列化

直观对比图（简化）

旧：JS ──(Bridge, async)──► Shadow ──(async)──► UI  
新：JS ───────────(JSI, sync)──────────► UI

因此，新架构不仅“砍”掉了 Shadow 线程，还把原来必须异步的操作变成可同步，同时支持并行更新，显著减少掉帧和首帧延迟。