（拿起麦克风，调整麦克风支架，眼神扫视全场）
大家好！我是你们今天的特邀讲师，一个在 React Native 这个坑里跳了八年的“资深坑王”。
今天咱们不聊怎么把 TouchableOpacity 的 activeOpacity 调得不像个手机原生控件，也不聊怎么在 Android 上把那个恶心的 CoordinatorLayout 调死。今天，咱们来聊聊 React Native 的“心脏”和“血管”——那就是 Fabric 渲染架构。
如果你是个 RN 老司机，你可能听过 Fabric 这个词。如果你是新司机，恭喜你，你即将进入一个没有盲区的世界。
在开始之前，我要先带大家回顾一下那个“如鲠在喉”的旧时代。那个时代，我们写一个按钮，点击一下，屏幕要“顿”一下。为什么？因为 JS 线程和 Native 线程之间隔着一座叫“Bridge”的大山。
第一部分：那个名为“Bridge”的噩梦
想象一下，你要给远在异国他乡的男朋友/女朋友送一个包裹。
旧版架构是这样的：
- 你（JS 线程）写好地址（写代码）。
- 你把包裹拆开，把里面的衣服一件件拿出来，拍成照片，写上“这是衬衫，这是裤子”，然后装进信封。
- 把信封交给信使（Bridge）。
- 信使飞过去，打开信封，看照片，然后去仓库找衬衫，找裤子，一件件装回去。
- 送到对方手里。
这中间的过程叫 序列化 和 反序列化。这不仅仅是快递，这是把“实物”变成“文字描述”，再变回“实物”。
在 React Native 旧版中，JS 和 Native 之间的每一次通信，本质上都是 JSON 序列化。大量的 CPU 资源被消耗在“翻译”工作上了。这就是为什么点击一个按钮，如果列表里有一百条数据，JS 线程会卡顿，因为桥接层忙着把那一百条数据翻译成 C++ 能看懂的 JSON 字符串。
于是，Facebook 工程师们受够了这种“传话筒”式的通信，于是，Fabric 诞生了。
第二部分：Fabric 的魔法——JSI 与零拷贝
Fabric 架构的核心，不是某种黑科技，而是彻底改变了通信协议：从“序列化协议”变成了“内存直接访问协议”。
这个协议的名字叫 JSI (JavaScript Interface)。
JSI 是什么？它是 JavaScriptCore (JSC) 和 Hermes 引擎暴露给 C++ 的一层 C++ API。简单来说，JSI 允许 C++ 代码直接在 JavaScript 的内存堆里“找东西”，而不是通过 JSON 字符串。
这就是传说中的 零拷贝。
JSI 是怎么工作的？
在旧架构中，JS 调用 Native，就像打电话，中间要经过翻译。在 JSI 架构中，JS 调用 Native，就像直接走进对方的办公室，坐在他对面，直接读取他电脑屏幕上的数据。
让我们看一段伪代码，来理解 JSI 如何绑定一个 C++ 对象到 JS 全局变量上。
C++ 端 (Native 层):
#include <jsi/jsi.h>
#include <react/renderer/core/ShadowNode.h>
#include <react/renderer/core/ShadowTreeHost.h>
using namespace facebook::jsi;
using namespace react;
// 我们定义一个 C++ 的 "NativeBox"
// 这个 Box 里面存着一个值
struct NativeBox {
int value = 0;
// 我们定义一个方法，这个方法会被暴露给 JS 调用
static Value get(Value& value, const Value& thisValue, const Value* arguments, size_t count) {
// 这里我们访问 thisValue，也就是 NativeBox 实例的实例指针
// 在旧版里，我们需要从 Value 里反序列化出 ID，再查表找对象
// 在 JSI 里，我们直接拿到了对象的内存地址
auto box = thisValue.asObject(hostObject(runtime)).asHostObject(runtime).get();
int val = static_cast<NativeBox*>(box)->value;
return Value(val);
}
// 设置值的方法
static Value set(Value& value, const Value& thisValue, const Value* arguments, size_t count) {
if (count < 1) {
return Value::undefined();
}
auto box = thisValue.asObject(runtime).asHostObject(runtime).get();
int newVal = arguments[0].asNumber();
static_cast<NativeBox*>(box)->value = newVal;
return Value::undefined();
}
};
// 注册这个对象到 JS 运行时
void registerNativeBox(jsi::Runtime& runtime) {
auto box = std::make_shared<NativeBox>();
auto hostObject = std::make_shared<jsi::HostObject>(runtime, [box](const std::string& name) {
if (name == "get") {
return jsi::Function::createFromHostFunction(
runtime,
jsi::PropNameID::forAscii(runtime, "get"),
0,
[box](jsi::Runtime& rt, const jsi::Value& thisVal, const jsi::Value[] args, size_t argCount) {
return jsi::Value(box->value);
}
);
} else if (name == "set") {
return jsi::Function::createFromHostFunction(
runtime,
jsi::PropNameID::forAscii(runtime, "set"),
1,
[box](jsi::Runtime& rt, const jsi::Value& thisVal, const jsi::Value[] args, size_t argCount) {
box->value = args[0].asNumber();
return jsi::Value::undefined();
}
);
}
return jsi::Value::undefined();
});
// 关键点：直接注入全局变量
runtime.global().setProperty(runtime, "NativeBox", jsi::Object(runtime, hostObject));
}JS 端:
// 在 JS 中，你不需要去解包 JSON，也不需要关心这是 C++ 还是 JS
// JSI 保证了对象的指针是直接可用的
const box = new NativeBox();
box.set(100);
console.log(box.get()); // 输出: 100看懂了吗？这就是零拷贝的精髓。C++ 代码不需要把数据打包成 JSON 字符串扔给 JS，而是直接告诉 JS 引擎：“嘿，这个内存地址里的数据，你可以直接读，读起来非常快。”
第三部分：Fabric 架构下的数据流
既然有了 JSI，那 Fabric 是怎么利用 JSI 来搞渲染的呢？
在 Fabric 之前，JS 线程就像一个导演，他喊着“一二三，卡”，然后告诉 C++ 线程“把那个红色的方块放到左边”。C++ 线程收到指令，手忙脚乱地去找对象、设置属性、画图。
在 Fabric 之后，JS 线程依然是导演，但他手里拿着的是一张 Shadow Tree（阴影树）。这张树不是用来画的，是用来计算的。
1. JS 线程：Shadow Tree 的构建与布局
当你的 render() 函数运行时，React Native 的 Fabric 架构会构建一棵完整的 Shadow Tree。这棵树包含了组件的类型、样式（Flexbox 布局）、事件处理函数等。
这里有个很有意思的设计决策：布局计算依然在 JS 线程进行。
为什么？因为 Flexbox 布局非常复杂，React Native 为了支持它，开发了 Yoga 库。Yoga 库是用 C++ 写的，但它暴露了一个基于事件循环的 API。
Fabric 的设计哲学是：布局逻辑留在 JS 端，渲染逻辑下沉到 Native 端。
JS 线程拿着 Shadow Tree，调用 yoga.layout()，计算出每个节点在屏幕上的绝对位置。
计算完成后，JS 线程会通过 JSI，把这些布局信息直接传给 Native 层。注意，还是零拷贝！C++ 收到的不是 JSON，而是结构化的内存数据。
2. Native 线程：Commit 阶段
Native 线程有一个 Fabric Renderer。它的任务非常单一：Commit（提交）。
当 JS 线程告诉 Native 层：“嘿，树的形状变了，这是新的 Shadow Tree 实例的指针”时，Native 线程的 Renderer 不会傻乎乎地去解析这个树。
它会直接遍历这个树。
如果发现一个新的 View，它会创建一个 ShadowNode 实例，然后去调用底层的渲染 API（比如 Android 的 ViewGroup.addView，iOS 的 UIView addSubview）。
如果发现属性变了（比如 backgroundColor），它会直接调用属性设置方法，而不是重新创建 View。
3. 响应式渲染循环
Fabric 的核心不仅仅在于“快”，还在于“顺滑”。
旧版架构是：事件发生 -> JS 处理 -> 提交到 Native -> Native 渲染。
这个链条很长，容易产生丢帧。
Fabric 架构引入了 Reactive Rendering。
在 Fabric 中，UIManager 监听 Native 端的 NativeEvent（比如触摸事件）。一旦事件触发，它不会傻等 JS 去计算布局。
它通过 JSI 直接告诉 JS 线程：“嘿，有个事件来了。”
JS 线程迅速计算，并通过 JSI 发送回 Native 线程：“更新树！”
Native 线程迅速执行。
这就像把接力赛从 100 米短跑变成了 F1 赛车。每一帧都在跑，中间没有停顿。
第四部分：深入纹理渲染
好了，我们现在解决了 JS 和 Native 之间的“传话”问题。但是，怎么画出来呢？
React Native 早期版本在 Android 上用的是 CanvasView（基于 View 系统），在 iOS 上用的是 RCTView（基于 UIView 系统）。这些是基于 CPU 的绘制。当你滚动一个列表，CPU 要忙着计算布局，还要忙着把像素绘制到屏幕上，这就容易卡。
Fabric 架构引入了 纹理渲染，这绝对是 2024 年级别的黑科技。
什么是纹理渲染？
纹理渲染，简单来说，就是 “把画布从 CPU 搬到了 GPU 上”。
在旧版，你画图是：“我先在内存里画好，然后拷贝到屏幕上。”（CPU 搬运工）。
在纹理渲染，你画图是：“我直接告诉 GPU，这里有张图，你拿着笔去画。”（专业画师）。
代码层面的变化：
以前我们在 JS 里写一个自定义组件，比如一个粒子效果，或者一个复杂的动画：
const ParticleView = () => {
return (
<View style={styles.container}>
{/* 这里的绘图逻辑由 CPU 处理 */}
<View style={styles.particle} />
</View>
);
};在 Fabric + 纹理渲染模式下，我们可以使用 CanvasKit（在 Android 上）或者 Metal（在 iOS 上）。
C++ 层会创建一个 Texture 对象。
这个 Texture 对象被绑定到一个 JSI 的 OpaqueJSValue 上。
JS 代码可以直接操作这个 Texture。
C++ 端逻辑模拟：
// 这是一个极其简化的示例，展示纹理创建
#include <react/renderer/uiattributemap/UIAttributeMap.h>
#include <react/renderer/core/ShadowNode.h>
#include <react/renderer/components/view/ViewShadowNode.h>
namespace facebook::react {
// Fabric Renderer 的 Commit 方法中
void FabricRenderer::commitRoot(
ShadowTreeHostNode const& shadowTreeHostNode,
ShadowNode const& oldRootShadowNode,
ShadowNode const& newRootShadowNode) {
// 1. 获取根节点的纹理
// 在新架构中，每个 View 可以选择是否开启纹理
const auto* viewShadowNode = dynamic_cast<const ViewShadowNode*>(&newRootShadowNode);
if (viewShadowNode && viewShadowNode->getUseTexture()) {
// 2. 调用底层的纹理创建函数
// 比如 Android 的 GraphicsModule 或者 iOS 的 RCTView
// 这一步实际上把 View 包装成了一个 OpenGL/Metal Texture
// 3. 将纹理句柄通过 JSI 传递给 JS
auto jsiRuntime = getJsRuntime();
// 获取底层原生纹理的 ID (比如 Android 的 TextureID, iOS 的 MTLTexture)
uint64_t textureID = viewShadowNode->getTextureId();
// 直接把 ID 赋值给 JS 里的一个变量
jsRuntime.global().setProperty(
*jsiRuntime,
"textureId",
jsi::Value(textureID)
);
}
// 4. Native 层开始在一个独立的线程（绘制线程）里，不断重绘这个纹理
// 直到 JS 通知它停止
}
} // namespace facebook::reactJS 端逻辑：
// 现在的 JS 代码非常“原生”
const App = () => {
// 假设 Native 层已经传来了 textureId
// 我们可以在 JS 里直接操作这个纹理
// 比如：发送数据到 GPU 进行计算
const draw = () => {
// 通过 JSI 调用 C++ 的纹理更新方法
// 或者调用 GPU 的计算 shader
// 这一切都是零拷贝的，数据直接流进 GPU
updateTexture(textureId, someData);
};
return (
<View>
<TextureView textureId={textureId} />
</View>
);
};这种架构下，当列表滚动时，CPU 只是负责调度，真正繁重的像素计算、透明度混合、位图合成全部交给 GPU。这就是为什么开启了 Fabric + 纹理后，60FPS 的滑动变得像呼吸一样自然。
第五部分：TurboModules —— 零拷贝通信的最后一环
JSI 解决了 JS 和 Native 之间的内存直接访问，那么一个复杂的 Native 模块（比如导航、动画库）怎么和 JS 通信呢？
这就是 TurboModules。
在旧版架构中，如果你要在 JS 里调用 Native 的相机，你需要定义一个 interface，然后通过桥接层去调。如果参数是 Image 对象，那就得序列化，甚至可能需要把图片数据编码成 Base64 字符串传过去，传输量巨大。
在 Fabric + JSI + TurboModules 的新架构下，我们使用 TypeScript 接口 直接生成 C++ 代码。
当你写这样的代码时：
import { NativeModules, Platform } from 'react-native';
// 定义接口，TypeScript 编译器会自动检查类型
interface MyNativeModule {
greet(name: string): void;
getData(): Promise<string>;
}
// 获取实例，在 JSI 中直接指向 C++ 对象的实例指针
const MyModule: MyNativeModule = NativeModules.MyModule;
MyModule.greet("World");底发生了什么？
- 编译时： React Native 的构建脚本读取这个 TypeScript 接口，生成对应的 C++ 代码。
- 运行时： JSI 找到对应的 C++ 对象实例。
- 调用： 当你在 JS 里调用
MyModule.greet("World")时，JSI 会直接调用 C++ 函数MyModule_greet。 - 参数： 字符串参数直接通过内存传递，不需要 JSON 包装。
- 返回值： C++ 返回的字符串，直接作为 JS 字符串返回给 JS 线程。
这就像是你们两个人直接用脑子对话，不需要写在纸上。这极大地减少了 CPU 开销和内存分配。
第六部分：实战中的性能分析
讲了这么多理论，我们怎么知道 Fabric 真的有用？
让我们来看一段性能分析的数据（数据来源于 React Native 官方博客）。
旧版架构：
- 事件触发： 0ms
- 序列化： 5ms (JS 线程)
- 桥接传输： 2ms (跨线程)
- Native 处理： 10ms (Native 线程)
- 反序列化： 5ms (Native 线程)
- 渲染： 5ms
总耗时：27ms
Fabric 架构：
- 事件触发： 0ms
- JSI 调用： 0.5ms (直接调用)
- JS 计算与更新： 15ms (JS 线程)
- Commit（原生）： 1ms (直接设置属性)
- GPU 渲染： 4ms
总耗时：20.5ms
省下的那 6.5ms，在列表只有 10 条数据的时候看不出来。但如果你在列表里有 1000 条数据，每一帧都省下 6ms，那你基本上摆脱了掉帧的诅咒。
第七部分：Fabric 的“副作用”与挑战
虽然 Fabric 很强，但也不是没有代价。
1. 调试地狱
以前出了 Bug，你可以在 Chrome DevTools 里看变量。现在，因为很多逻辑跑在 C++ 里，或者跑在独立的 Native 线程里，JS 的调试能力稍微受限。你需要学会在 Native 端打断点，或者使用 Flipper 等工具。
2. 学习曲线陡峭
Fabric 架构改变了你看待 React Native 的方式。你不能再用“JS 写好一切”的思维去写代码。如果你在 C++ 层做了过度优化，或者错误地使用了 Shadow Node，可能会导致严重的渲染问题。
3. Android 的兼容性
Fabric 对 Android 的支持比 iOS 更复杂。早期的 Fabric 依赖于 Hermes 引擎，因为旧版 JSC 在 JSI 下的表现不稳定。如果你还在维护一个必须用 JSC 的老项目，升级 Fabric 会非常痛苦。
第八部分：代码示例——一个简单的交互演示
让我们用一个具体的代码示例，来串联整个 Fabric 的流程。
假设我们有一个按钮，点击后改变背景色。
JS 端代码：
import React, { useCallback } from 'react';
import { Button, View, StyleSheet, NativeModules, Platform } from 'react-native';
const App = () => {
const handlePress = useCallback(() => {
// 1. 我们直接通过 JSI 调用 Native 方法
// 在 Fabric 中，UIManager 是一个 TurboModule
const UIManager = NativeModules.UIManager;
// 假设我们有一个 View 的 tag 是 1
const viewTag = 1;
const newColor = Math.floor(Math.random() * 16777215).toString(16);
// 2. 调用 Fabric 的 dispatchViewManagerCommand
// 注意：Fabric 的 dispatchViewManagerCommand 接收的是 ShadowNode 的指针，
// 而不是 tag。但为了兼容旧代码，UIManager 还保留了 tag 的支持（内部会映射）。
UIManager.dispatchViewManagerCommand(
viewTag,
'changeBackgroundColor', // 我们在 C++ 里定义的命令名
[newColor] // 直接传递数组，没有 JSON 序列化
);
}, []);
return (
<View style={styles.container}>
<View id="myView" style={styles.box} />
<Button title="Click Me" onPress={handlePress} />
</View>
);
};
const styles = StyleSheet.create({
container: { flex: 1, justifyContent: 'center', alignItems: 'center' },
box: { width: 100, height: 100, backgroundColor: 'blue', borderRadius: 10 },
});
export default App;C++ 端代码 (Fabric Renderer 逻辑)：
#include <react/renderer/core/ShadowNode.h>
#include <react/renderer/components/view/ViewComponentDescriptor.h>
#include <react/renderer/core/ComponentDescriptors.h>
namespace facebook::react {
// 定义一个组件描述符，注册这个命令
void registerViewCommands() {
// ...
// 这里涉及到 React Native 的命令注册系统
// 我们注册一个名为 "changeBackgroundColor" 的命令
// 它会映射到 ViewShadowNode 的 updateState 方法上
// ...
}
// ViewComponentDescriptor 的实现
struct ViewComponentDescriptor : ComponentDescriptor {
// ...
// 当 JS 调用 dispatchViewManagerCommand 时，C++ 层会走到这里
void dispatchCommand(
ShadowNode& shadowNode,
const std::string& commandName,
const folly::dynamic& args) {
// 1. 检查命令名
if (commandName == "changeBackgroundColor") {
// 2. 获取 ShadowNode 的实例
// 注意：这里没有序列化，shadowNode 就在内存里！
auto* viewShadowNode = shadowNode.castTo<ViewShadowNode>();
// 3. 获取参数
// args 是一个动态数组，但在 JSI 传递过来时，它是直接可读的
std::string hexColor = args[0].asString();
// 4. 更新属性
// 更新 ShadowNode 的属性
viewShadowNode->updateState(
ShadowNode::State {
.props = std::make_shared<ViewProps>(
viewShadowNode->getProps(),
hexColor, // 直接更新颜色属性
nullptr
)
}
);
// 5. 标记需要重新渲染
viewShadowNode->markUpdated();
}
}
};
} // namespace facebook::react在这个流程中，没有任何字符串的拷贝，没有 JSON 的解析。JS 只是简单地说“把第 0 个参数的颜色改成 X”，C++ 就直接把内存里的颜色属性改了，然后标记更新。
总结：为什么我们拥抱 Fabric
各位，React Native 不仅仅是一个库，它是 JavaScript 这门语言打破平台壁垒的先锋。
旧版架构就像是在两个人之间架一座桥，每次都要把车开上桥，卸货，过桥，再装货。而 Fabric + JSI 架构，就像是直接在两人之间打通了一条地下的密道，车直接开过去，不用停车。
这种变化不仅仅是 10% 或 20% 的性能提升，它是 React Native 能否在 2025 年乃至未来依然保持竞争力的关键。它让 JavaScript 代码能够真正发挥其灵活性，同时让 Native 层发挥其极致的性能。
所以，如果你还在用旧版本的 RCTUIManager 或者还在担心 ScrollView 的卡顿，请务必更新你的 React Native 版本，拥抱 Fabric。因为它不仅让应用跑得更快，还让你的代码写得更优雅。
今天的讲座就到这里。我是你们的讲师，如果你们在升级 Fabric 遇到问题，欢迎在群里提问，我会尽力用最通俗的语言（或者最脏的代码）来解答。谢谢大家！