React Native Fabric架构源码解析：ShadowTree、挂载事务与UI线程的工程实践

1. 为何Fabric值得单独做一次源码级阅读：旧渲染管线的四个痛点

如果你在一线写过一段时间React Native，大概率经历过这类现象：列表稍微复杂一点，滚起来就掉帧；输入框输入快了，字母会延迟半拍；明明只是改了一个Text的颜色，整个页面却感觉卡了一下。这些问题的根源，并不全在JS业务代码，而是旧渲染管线在架构层面就把自己限制住了。

1.1 Bridge的异步边界让UI操作变成"排队"

旧架构里，JS和原生之间靠Bridge通信，JS调用一个原生方法，不是直接函数调用，而是把调用序列化成一个消息，塞进队列，再由原生侧线程去取、去解析、去执行。整个过程是异步的，消息收发还带着序列化和反序列化的开销。

这种设计像极了办公楼里只有一个电梯：所有人都得等，高峰期必然拥堵。一条JS指令要想到达Android的View层，中间要过JS线程、Bridge队列、原生线程，而只要某个环节塞住，后面所有UI操作全部延迟。更麻烦的是，如果JS想在某个关键节点立刻得到原生返回结果，就得借助同步调用，而同步调用对Bridge来说代价极高，容易造成线程阻塞。

1.2 JS线程上的长任务会拖住UI更新

旧架构里，布局计算最终要依赖JS侧的逻辑。JS线程一旦被业务计算卡住，UI更新就得排队等着。比如列表里某个组件的render函数写得比较重，JS线程长时间被占用，紧接着触摸反馈、滚动事件、setState触发的重渲染都会跟着一起延迟。用户感受到的结果就是：点下去没反应，滚起来不跟手。

这不是简单的代码优化能解决的问题，而是调度模型的问题。旧Bridge架构下，JS渲染和原生UI天然就是两条异步的单行线，中间没有精确的优先级控制。UI想插队，但排队规则不允许。

1.3 Fabric的三大设计目标与源码分析的意义

Fabric架构要解决的核心问题，就是扭转以上这些局面。它的三个设计目标可以概括为：

• 渲染过程不必等JS线程慢慢传递消息，而是由C++层统一接管ShadowTree的构建和布局计算，JS通过JSI直接调用C++接口，去掉序列化。
• 渲染计算支持并发，布局可以放在更多线程上做，UI线程和JS线程的依赖关系被重新梳理。
• 跨端渲染核心统一，Android和iOS共用一套C++渲染逻辑，平台差异被压缩到ViewManager和挂载层。

这些目标听起来很美好，但只在PPT层面理解是没用的。要看它到底怎么做到、瓶颈转移到了哪里，最好的方式就是直接去读源码。这篇文章我把Android端的Fabric骨架拆开，讲清楚初始化、渲染、挂载、事件这几条链路，并分享一些实际阅读时的收获与踩坑。

2. Android端Fabric的整体分层：从入口类到C++引擎的调用关系

Fabric涉及的语言边界比较复杂，Java（Kotlin）、C++、JS三层互相调用，不先把整体分层理清楚，一上来就盯某个类很容易迷失。

2.1 FabricUIManager与ViewManagerRegistry：Android侧的两个主角

在Android端，Fabric的大总管是FabricUIManager。它不是一个抽象概念，而是一个真实存在、承担挂载调度的核心类。旧架构的UIManager主要负责把JS业务消息翻译成原生View操作，而FabricUIManager的工作方式完全不同：它消费的是来自C++层的挂载指令，并不直接解析JS消息。

ViewManagerRegistry则负责维护所有ViewManager的注册表。所谓ViewManager，在Android端就是某个组件类型的"生产说明书"：它知道怎么创建这个View、怎么更新属性、怎么执行命令。比如一个Text组件，在Android里对应一个ReactTextViewManager，能创建ReactTextView，能设置字号、颜色、行数，能响应onLayout等事件。

FabricUIManager拿到C++层发来的挂载命令后，第一步就是去ViewManagerRegistry里面找对应的Manager，然后再实施创建View、插入子View、更新属性这些动作。所以这两者的关系很简单：UIManager是调度总指挥，ViewManagerRegistry是具体施工队的花名册。

2.2 Java与C++的边界：JNI、FabricJSI、SurfaceHandler

Fabric最大的架构变化，是把渲染核心下沉到C++。Java层不要自己算布局，不要去碰Yoga计算，只做View的创建、挂载和事件上报。

这里有几个重要的桥接概念：

• JNI：Java和C++之间的调用通道。Java层调用C++对象，C++层回调Java方法，都靠JNI函数桥接。
• FabricJSI：让JS侧通过JSI直接访问C++对象。JS不是发消息，而是直接调用一个C++绑定对象的方法。
• SurfaceHandler：一个逻辑上的"渲染面"，对应一个页面Root节点。每个React Native页面在进行初始化时，会创建Surface，然后通过SurfaceHandler设置布局约束、执行启动等。

在源码阅读时，我建议以SurfaceHandler作为入口链路：从JS启动一个App开始，到Java侧的ReactHost，再到C++侧的SurfaceManager，一层层往下追，就能看到整个渲染能力的初始化路径。

2.3 一次React元素在Android端的完整旅程

假设现在渲染一个最简单的<View><Text>hello</Text></View>，在Fabric架构下，它的旅程大致分为五个阶段：

1. JS侧创建元素描述，通过JS调用C++绑定的方法，进入Fabric渲染核心。
2. C++层根据元素描述创建ShadowNode，构建出一棵ShadowTree。
3. Yoga引擎在C++里对这棵ShadowTree做布局计算，算出每个节点的x、y、width、height。
4. C++层生成挂载事务，里面包含一批挂载指令，通过JNI传给Java层FabricUIManager。
5. FabricUIManager在UI线程逐条处理挂载指令，驱动ViewManager完成Android View的创建、插入和属性设置。

整个流程中，JS线程只负责描述和事件，C++负责树和布局，Java只负责View操作。职责划分得相当干净。这也是读源码时最好用的"地图线"：碰到一个类，先问它在哪个阶段、谁调它、它调谁。

3. ShadowTree与ShadowNode：Fabric的"虚拟树"体系解析

ShadowTree是整个Fabric渲染架构里最核心的抽象。很多人一开始读这部分会觉得绕，因为ShadowNode不是Android View，也不是React组件，而是一个专门服务于渲染流程的中性节点。搞清楚它，等于搞清楚了Fabric一半。

3.1 不可变ShadowNode的设计逻辑

ShadowNode最重要的设计特点是不可变。每次渲染更新，不是直接修改现有节点，而是克隆出一个包含新状态的新节点，然后把新节点挂到树上。这句话看上去很简单，但背后的设计哲学很关键。

不可变设计带来的直接好处是安全并发。渲染核心可以拿着当前的ShadowNode快照做布局计算，同时另一个线程可以继续对最新树做更新，两者不会互相碰坏数据。这跟函数式编程里不可变数据结构能天然支持并发是同一个道理。在实际追源码时你会发现，克隆并不是整棵树全部复制，节点之间会尽量共享可复用的子树，所以性能损失不像想象中那么大。

另外，不可变特性也给diff提供了天然的便利。拿到新旧两棵树的根节点，只要节点引用没变，就说明子树没变；变了，就去比较变化的部分。这样能精准地把更新收敛到最小范围，而不是像旧架构那样动不动整棵视图树重新过一遍。

3.2 Props、State、EventEmitter的三位一体

在ShadowNode源码结构里，经常能看到三类数据同时存在：

• Props：来自JS侧的属性描述，表示"现在应该长什么样"。
• State：由组织本身维护的、不完全来自JS的内部状态，比如一个视频播放器的当前播放进度、一个文本输入框的本地光标。
• EventEmitter：事件回调的绑定关系，告诉这个节点"发生了某种交互时应该触发哪个JS回调"。

传统开发里大家最容易只盯着Props，其实State机制也是Fabric一个很值得关注的点。它允许部分组件在原生侧维护动态数据，而不用把每一次轻微变化都通过JS走一圈。这样既减少JS线程的压力，也使得像动画进度、输入光标这类高频更新可以不依赖JS就能反映到原生视图。

3.3 一次属性更新在ShadowNode上的路径

以一个常见的场景为例：JS里setState改变了一个Text的颜色，触发重渲染。这条更新路径大致是：

1. JS调用渲染函数，得到新的元素树。
2. 通过JSI把更新意图传到C++的渲染核心。
3. C++找到对应的旧ShadowNode，克隆出一份带新Props的新ShadowNode。
4. 新节点挂接到树的正确位置，局部生成新的树结构。
5. Yoga对受影响的节点做布局计算。
6. C++对比新旧树，生成差异化的挂载事务，交给挂载管线。

这个流程里最值得注意的一点是：第3步到第5步完全是C++层在运作，Java层和JS线程都不需要参与计算。这是Fabric在架构层面能做到高刷新率的最大前提。

4. Mounting管线：从ShadowTree"落地"到Android View的四步关键路径

ShadowTree计算得再快，最终也得落到真实的Android View上，用户才能看见。这个落地的过程在Fabric里叫作Mounting（挂载）。

4.1 MountItem的语义：创建、插入、更新、删除、命令

C++层向Java层传递挂载事务时，事务里不是整棵树的详细描述，而是两类东西：一批MountItem和一个事务元数据。MountItem的类型决定了UI线程要对View做什么操作。大致可以归纳成以下几类：

这里面的设计重点不是单个操作，而是如何把这些操作批量且有序地组织起来。C++每次产生的不是零零散散的单个指令，而是按事务打包、带有序号的指令集，Java层只需按序消化即可。

4.2 FabricUIManager在UI线程上的事务处理

FabricUIManager收到挂载事务后，会在UI线程上进行批量处理。它并不会每来一条就立刻执行一条，而是把同一个事务中的MountItem聚合起来，在一个专门的调度流程里统一执行。这样做的直接好处是减少UI线程的唤醒次数和布局计算次数。

在阅读源码的时候，你会看到事务处理里有类似"排队"、"消费"这样的实现逻辑。我的理解是：它本质上是一个生产者-消费者模型。C++层是生产者，不断计算出最新的挂载事务；Java层的UI线程是消费者，专门负责把事务里的指令转换成View操作。生产者和消费者之间通过回调机制进行协作，UI线程不至于每帧都被压到极限。

4.3 局部更新与差量计算的价值

旧架构里一次setState，往往会对整棵视图树做较大范围的更新处理，因为很多节点到底变没变，原生侧并不清楚，只能做防御性更新。Fabric的倒挂设计则天然具备差量能力。

由于ShadowNode的不可变特性和树级diff，C++层能够明确知道哪些节点变了、谁新增了、谁被删了。传给Java层的MountItem本身就是差值结果，Java层不用自己去“猜”。所以一个局部状态变化，最终到UI线程可能只是几个Update操作，而不是全量重绘。

这也是Fabric在复杂长列表和频繁交互场景下，实际表现优于旧架构的根本原因。但要注意，这并不意味着业务代码可以随便写。如果业务里一次render生成了内容完全不同的十万个节点，diff照样会产生大量MountItem，性能压力依然存在，只是比旧架构更可控。

5. Android事件与状态同步：触摸事件不经过Bridge怎么回到JS

新架构里JS和原生不再是“隔空喊话”，而是通过JSI直接互调。事件分发这条链路，也顺理成章地做了重构。

5.1 事件从View到JS的完整链路

Android View接收到一次触摸事件后，Fabric架构下的大致走向是：

1. 原生View在触摸回调里识别出手势，或者触发onClick、onScroll等事件。
2. 事件信息通过事件发射器写入C++事件系统。
3. C++层根据ShadowNode上的EventEmitter绑定关系，找到对应的事件回调路径。
4. JS侧的事件处理器被触发，执行业务逻辑。

注意，这里没有旧架构那套"先封装成WritableMap、再序列化丢到Bridge队列、等JS线程取走执行"的过程。整个链路是直接调用，数据传递的损耗和延迟都被压缩了。

5.2 新旧事件系统的本质差异

旧架构下，事件从原生到JS需要经过消息队列，JS侧收到事件再去调用setState更新UI，更新又得走一遍Bridge回到原生，一来一回延迟很高。在某些需要即时响应的手势场景里，这种延迟会直接变成用户感知到的掉帧。

新架构把这条链路变成了一条更短的“直连通道”。事件触达JS的速度更快，JS做出的更新意图也能更快地反馈到渲染管线。源码阅读层面，你重点看事件从平台EventEmitter进入C++后，是怎么定位到具体组件和具体JS回调的，这一个过程理解了，整个事件系统就通了。

5.3 StateWrapper：原生状态“半自动同步”机制

另一个值得关注的设计是StateWrapper。某些组件比较特殊，它的实时状态由原生持有，比如播放器进度、地图当前区域、输入框光标位置。如果每次变化都通过JS转一圈再更新视图，那纯粹是浪费性能。

StateWrapper提供了一种模式：原生侧可以在内部State变化时，直接更新与ShadowNode关联的State数据，JS侧需要读取状态时也能快速访问。这让“原生自己状态自己管，JS只拿结果”成为可能。读源码时，看到有的组件方法里涉及到对State的搬运和更新，不要困惑，它走的不是普通Props路线，而是StateWrapper这条特殊通道。

6. 读Android端Fabric源码时，几个容易让人绕晕的细节

源码本身是可读的，但中间很多命名和实现细节，会让第一次深入的人产生误解。我整理几个实际阅读过程中最容易困扰的问题。

6.1 版本差异：别拿老版本的理解套新架构

React Native的版本演进非常快，Fabric相关代码在不同版本里的组织方式并不一样。有些早期版本里Fabric只是特性开关，新旧代码混在一起；到了后续版本，FabricUIManager的职责被进一步优化，某些方法彻底从旧UIManager中剥离。

所以阅读前第一件事，是确认你本地项目使用的准确版本，并锁定与该版本匹配的源码分支。老版本里某个类的作用，可能在新版本里已经被拆分或改名了。网上很多分析文章年代跨度很大，直接照搬结论会踩坑。

6.2 理清"异步布局计算"和"异步UI挂载"的区别

这是我在实际阅读中绕得最久的一个点。Fabric虽然强调“并发渲染”，但绝不意味着Android View可以在后台线程创建和修改。Android的View操作必须发生在UI线程，这一点在任何架构下都不会改变。

Fabric的并发体现在：布局计算、ShadowTree构建、diff这些工作可以在非UI线程完成，而且可以多线程并行。真正到View层，依然会回到UI线程做挂载。所以源码里你会看到两类机制：一类是计算层的并发调度，另一类是挂载层的UI线程批量处理。把这两者分开理解，就不会被“并发”两个字误导。

6.3 从哪个源码入口开始最省力

如果让我只推荐一条阅读路径，我会这样排顺序：

1. 全局搜FabricUIManager，重点看onMountItems相关方法，理解Java层是怎么消费挂载事务的。
2. 看SurfaceHandler的启动流程，知道页面渲染是从哪里开始的。
3. 找ShadowTreeRegistry，理解一棵树是怎么被登记、查找和管理的。
4. 看ViewManagerRegistry以及一个简单ViewManager的实现，对照理解Manager如何处理创建和更新。
5. 挑一个最简单的组件（比如View），从JS渲染到Android View显示，完整走一遍代码，建立整体闭环。

这样一条线走下来，比零散阅读更容易形成系统认识。配合Android Studio的debugger，在关键方法处打断点，观察挂载事务到底带了哪些MountItem，会远比只看代码直观。

6.4 新架构特性开关与兼容层

很多项目升级到新架构后，代码里仍然保留着旧架构时期的模块和文件名。如果你在源码里看到某些标记为旧架构兼容的代码，不要惊讶。当时为了平滑迁移，新老两套渲染体系在较长时间内是并行保留的。阅读时优先盯“新架构”分支，忽略那些兼容旧接口的路径，不然逻辑会很混乱。

7. 由源码分析回到实际工程：我的实践体会与建议

走完ShadowTree、挂载事务、事件系统这三条大链路之后，我对Fabric的认识完全不一样了。以前只知道它“性能好”，读完源码才明白好在哪里：好在对渲染路径的简化，好在计算和UI执行的职责分离，也好在差量更新的精确调度。

在实际项目里，我建议从这几个角度去验证Fabric的真实收益：

• 观察高频交互场景的掉帧率，比如长列表快速滚动、搜索框实时过滤、图片墙懒加载。
• 关注JS线程的繁忙程度，如果你经常写重计算逻辑，新架构确实能把JS和UI之间的耦合拉低。
• 收集ANR和点击延迟的线上数据，用数据说话，不要只看基准测试。

代码层面，做性能优化时你会发现，Fabric虽然强，但也没有改变常识：该用不可变数据结构的地方继续用，该做组件拆分的继续拆，避免一次渲染生成超出合理范围的节点量。架构只负责把路修好，车怎么开还是取决于业务代码。

最后分享一个我自己觉得非常实用的调试技巧：在开发构建里把日志标记打开，观察挂载事务的批次大小和频率。正常情况下，一个简单页面的初次渲染会有一个较大的事务批次，但后续更新的事务应当小而细。如果你看到每次交互都产生巨大的事务批次，说明业务代码里有大范围的无效更新，这才是真正要去优化的点，而不是一味怀疑架构本身。

Fabric的源码阅读过程确实不算轻松，但一旦把Java/C++/JS三层的关系串起来，再看任何渲染问题都会有一种“地图在手”的感觉。希望这篇走读笔记能帮你省掉一些弯路，把精力花在真正关键的主干逻辑上。