新旧架构的核心区别
“新架构把原来基于 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 线程，还把原来必须异步的操作变成可同步，同时支持并行更新，显著减少掉帧和首帧延迟。
