React Native 的新架构介绍（三）：Fabric 和 TurboModules

本文的源作者是 LORENZO SCIANDRA，文章源链接为 The New React Native Architecture Explained: Part Three，我将其翻译成中文。

React Native 的重构最初在 2018 年提出，它是 Facebook 进行的一项巨大努力，来解决这个移动端跨平台解决方案长久存在的问题。

在本文中，我们深入重构的重头戏，几乎每个 React Native 开发者都听说过它：Fabric 和 TurboModules。

为了便于理解，我们对旧架构中的 Bridge 进行如下简化：

其中，这些元素主要负责两种操作：

• 定义 UI 长什么样以及有哪些操作操作(通过 Shadow Tree)
• 管理 Native 侧(通过 Native Modules)

如前面提到的，这些通信通过异步的 JSON 消息，他们成批发送、接收，在同一个通信通道中如此往复。

你会从中看出，这回导致拥塞，以及导致体验下降。

Facebook 团队打算将这个庞杂的 bridge 分为两个部分：

• Fabric：是重构后的 UI Manager
• TurboModules：是 Native 侧的下一代实现

Fabric 的目标是对 React Native 的展示层进行现代化改造。

在当前的实现中，所有 UI 操作都要经过 Bridge 进行处理，并且要经过多个步骤：

• React → Native → Shadow Tree → Native UI

在新的实现中，允许 UI Manager 直接在 C++ 中创建 Shadow Tree，这极大地提高了这个过程的速度，因为不用在 JS 侧和 Native 侧来回通信了。

基本来说，这会极大地提升 UI 的响应性。

同时，通过使用 JSI，Fabric 将 UI 操作作为函数暴露给 JavaScript：新的 Shadow Tree(它决定了屏幕上真正展示什么) 在 JS 侧和 Native 侧是共享的，两边可以直接交互。

如果这还不够提升的话那么还有：这种从 JavaScript 侧的直接控制，允许从新的 React 框架中对 UI 操作采用优先队列，为了拥有更优的同步执行性能。

这个基础对常见的痛点都有改善作用，比如：列表、导航、手势处理。

在当前的实现中，JavaScript 代码使用的 Native Modules (特别是蓝牙)，需要在 App 打开的时候进行初始化，就算你不用它它也会初始化，因为 React Native 的 Native 侧也不知道 JS 那边需不需要用。

在新的 TurboModules 方案中，允许 JavaScript 代码按需加载模块，并且持有对它的直接引用，这意味着不再需要向老的 Bridge 那样通过成批的 JSON 消息进行通信。

这会极大地提高哪些带有很多 Native Modules 的应用的启动时间。

第三块中的所有变化，依赖于前一篇文章中暴露出来的 JavaScript Interface。

如果我们想要汇总 Facebook 团队架构至今的架构，它会看起来像下面这样：

这就是重构中第三部分的解释。下周我们将发布这个系列的最后一篇。