RN新架构（Fabric渲染 / Hermes引擎）

可视化演示

展示React Native新架构中Fabric渲染器的UI树同步流程与Hermes引擎的字节码优化机制。切换模式查看渲染管线、引擎性能与架构对比。

架构演进：从中央调度台到智能园区

老物流园区的中央调度台前，总有一群小推车来回跑。快递员把包裹（JS 要更新的 UI 指令）交给调度台，调度员记在本子上（序列化），再按顺序安排小推车（消息队列）送到各个仓库，等仓库反馈后，还得回程通知快递员（异步回调）。React Native 旧版架构就是这样：JS 与原生之间隔着一座异步 Bridge，每一次通信都要经历序列化、排队和回调。

新架构的目标不是“把桥修宽一点”，而是把整个园区重新设计。JSI 相当于在 JS 引擎和原生世界之间铺了一条高速传送带，对象引用可以直接共享；Fabric 相当于新的分拣机器人，先在后台搭好影子树再统一提交；Hermes 则是一台为园区定制的发动机。三者配合，从结构上消灭了“所有消息都在一座桥上排队”的瓶颈。

可以用一个简单的求和模型表达旧架构在 n 次通信上的总耗时：

老调度台的模式不是不能运转，而是每次扩建都只能增加更多小推车，治标不治本。新架构要做的，是把“中央调度台”整个换成“直连传送带 + 智能分拣”。

JSI机制：园区里的高速传送带

在智能园区里，最重要的是一条高速传送带。旧模式里，包裹要想从 JS 仓库送到原生仓库，必须拆包、登记内容、装到小推车上，到了对面再重新组装；而新传送带可以直接让两个仓库共享同一个货架托盘，不需要反复拆包。这条传送带就是 JSI（JavaScript Interface）。

JSI 是一层轻量 C++ 接口，它让 JS 引擎与原生世界能够共享宿主对象引用。JS 可以直接拿到原生对象并调用其方法，方法返回值也能直接回到 JS 侧，整个过程不需要 JSON 序列化，也不需要异步回调解包。正因为有 JSI，Fabric、TurboModules 等新架构组件才能像不同仓库之间直连货架一样高效协作。

通信开销的改善可以用新旧对比表达：

传送带让园区里的仓库不再隔墙喊话，而是直接通过管道递货。JSI 正是这样的管道，它让“桥”这个词正式成为历史。

Fabric渲染：提前搭好货架模型的分拣机器人

智能分拣机器人每次摆放货物前，不会直接乱放，而是先在电脑里建一套货架模型：哪个位置放什么、承重多少、取货顺序如何，确认无误后再指挥真实货架一次摆好。Fabric 渲染器就是这样工作的：在真正更新原生视图前，先在后台构建一棵“影子树”，用来描述界面结构、样式和布局，然后一次性提交给原生端。

影子树相当于 JS 侧界面状态的“施工图纸”。旧的异步桥接是“施工队边等图纸边干活”，图纸到的路径长，进度就慢；Fabric 则把布局计算放到后台线程，完成后再利用每一帧的空闲时间合批提交，避免 JS 线程被 UI 更新阻塞，也支持了 React 的并发渲染特性。

要保证动画不卡顿，单帧内的总耗时必须被牢牢控制：

分拣机器人不会让所有包裹都堆积在卸货口，而是按计划、按批次地移动，Fabric 让 UI 更新也有了自己的“调度表”，画面自然更顺滑。

Hermes引擎：提前提炼好燃料的特制发动机

园区里最省油的发动机，从不临时点火预热，而是使用一种在进园区前就提炼好的标准燃料块。Hermes 就是 React Native 专为移动端设计的 JS 引擎，它最大的特点是支持 AOT（预编译）：在构建 App 时就把 JavaScript 预编译为字节码，设备端运行时只需要加载字节码并执行，省去了传统 JS 引擎“先解析源码、再做 JIT 编译”的过程。

这带来的直接好处就是启动更快、内存占用更低。对手机这类资源受限的终端来说，减少解析和编译动作，就像货车不需要在园区门口临时炼油，油耗和等待时间都大幅下降。Hermes 也做了针对移动端的内存回收优化，GC 暂停时间更短，不容易在滚动切换时出现明显卡顿。

启动收益可以写成：

发动机变得更高效，园区里的每一趟运输都因此受益。Hermes 是 RN 新架构体验中最容易被感知的那一环。

TurboModules：只打开当前订单需要仓库门

智能园区把大仓库改成了很多小隔间，每个隔间按需开门：当前订单只碰几个隔间，而不会让所有隔间的门一整天全敞着，白白耗电。TurboModules 就是这样的原生模块体系，它让 JS 侧在真正需要某个原生能力时才加载对应模块，而不是 App 启动时就把所有原生模块全部初始化。

TurboModules 另一个关键点是“代码生成”：配合 Codegen，开发者用一份类型定义描述原生模块，构建时自动生成类型安全的 JS 与 C++/Java/OC 胶水代码。旧架构中运行时才知道的方法名、参数类型和错误，在编译期就能被发现，也不需要桥接层再做动态对象映射。

首屏加载收益可以这样衡量：

按需开门、类型保障、直连调用，让每一个原生模块都像园区里的智能隔间——用到才打开，打开即能用，不用不占资源。

性能优化：园区监控室的三个仪表盘

智能物流园区的总监控室会盯紧三个指标：首单送达时间、高峰期吞吐量、油耗。对应到 RN 新架构，就是可交互时间 TTI、渲染帧率和内存占用。优化的目标不是单点跑到最快，而是让“整条业务链”在真实设备上都稳定。

具体策略上：用 Fabric 的异步布局减少 JS 线程的阻塞；用影子树的增量 diff 减少无效 UI 更新；用 Hermes 降低启动解析耗时；用 TurboModules 减少首屏初始化；再配合性能监控工具观察长任务、掉帧和内存曲线，定位是渲染问题还是 JS 逻辑问题。这里可以用一个 TTI 模型串起各部分：

监控室的价值不是挂一堆仪表盘，而是看到哪段运输最耗油。性能优化也如此：先量化，再动手，让每次治理都有数据支撑。

迁移兼容：老仓库带着新传送带一起运转

老园区不会一夜之间把所有仓库全拆掉，而是先建新传送带，再通过“兼容连廊”让旧仓库继续发货，等旧仓库逐个改造完成后，再拆掉连廊。RN 新架构的迁移也是如此：通过新架构开关让 App 在原有代码基础上启用 Fabric 和 JSI，同时提供兼容层让旧桥接模块继续工作，再按模块逐步迁移到 TurboModules。

工程上通常采用灰度发布：先让一小部分用户开启新架构，观察崩溃率、帧率和内存后再扩大范围。迁移风险主要来自尚未替换的旧桥接模块——它们越多，新架构能发挥的直连红利就越少。

可以用一个风险估算模型来辅助决策：

迁移不是“一键重写”，而是有节奏的园区改造。兼容连廊帮我们守住稳定底线，新传送带则逐渐释放性能红利。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-import heapq class FrameTask:    def __init__(self, tid, priority, cost):        self.tid = tid        self.priority = priority        self.cost = cost class FabricSimulator:    """模拟 Fabric 按优先级分帧提交的过程"""    def __init__(self, budget_ms=16.0):        self.budget = budget_ms        self._queue = []        self._task_count = 0        self.committed_lists = []     def add_task(self, priority, cost):        self._task_count += 1        heapq.heappush(            self._queue,            (-priority, self._task_count,             FrameTask(self._task_count, priority, cost))        )     def tick_frame(self):        used_ms = 0.0        finished = []        while self._queue and used_ms + self._queue[0][2].cost <= self.budget:            _, _, task = heapq.heappop(self._queue)            used_ms += task.cost            finished.append(task)        if finished:            self.committed_lists.append(finished)        return used_ms     def run(self, frames):        for i in range(frames):            used_ms = self.tick_frame()            status = "commit" if used_ms > 0 else "defer "            print("Frame {:>2}: {:5.1f}ms used -> {}".format(i, used_ms, status))        print("Total committed frames:", len(self.committed_lists)) if __name__ == "__main__":    sim = FabricSimulator()    sim.add_task(3, 4.0)    sim.add_task(1, 9.0)    sim.add_task(2, 5.0)    sim.add_task(4, 14.0)    sim.add_task(2, 6.0)    sim.run(4)

1. heapq.heappush(self._queue, (-priority, self._task_count, FrameTask(...)))用负优先级构造最小堆，确保高优先级任务先被弹出。
2. while self._queue and used_ms + self._queue[0][2].cost <= self.budget:当前帧剩余预算足够时才执行任务，否则留给下一帧。
3. self.committed_lists.append(finished)把这一帧内完成的任务合并成一批，对应 Fabric 的合批提交。
4. status = "commit" if used_ms > 0 else "defer "如果这一帧没有任何任务完成，就说明上一帧预留了缓冲，避免 UI 掉帧。
5. sim.run(4)连续运行 4 帧，观察调度器如何分配高优先级任务。

常见误区

面试题