原文地址：formidable.com/blog/2019/f…
原文作者：Lorenzo Sciandra
发布时间：2019年4月9日
第三部分: Fabric和TurboModules
React Native重新架构于2018年首次公布，是Facebook为解决这一跨平台移动解决方案的一些长期问题而进行的大规模努力。
在这个系列中，我们将对构成React Native新架构的主要元素进行概述。我们将避免展示代码，以使这一解释尽可能地易于理解，并将分享我们对这一新实现的兴奋。
在这篇文章中，我们将深入到重新架构的 "肉 "的部分，也就是每个React Native开发者可能都听说过的部分。Fabric和TurboModules。
正如我们之前所探讨的那样，新的React允许队列的概念，JSI使JavaScript代码能够意识到 "另一边 "的Native代码。
为了便于理解，我们将旧架构的桥块 "过度简化 "为什么。
这组元素基本上负责两种不同的行为：定义UI的外观和行为（通过影子树）和管理原生侧（通过原生模块）。如前所述，这些通信是通过异步JSON消息发生的，这些消息会被分批发送，在一个通信通道上来回传送，正如你所预料的那样，这可能会变得拥挤并导致次优体验。
Facebook团队决定将这个庞大的桥梁分成两个独立的角色。Fabric是UI管理器的重新架构，TurboModules是与原生端交互的 "新世代 "实现。
Fabric旨在使React Native的渲染层现代化。在当前的实现中，所有的UI操作都是通过一系列跨桥 "步骤"（React -> Native -> Shadow Tree -> Native UI）来处理的。而新的实现则允许UI管理器直接在C++中创建Shadow Tree，这样就减少了跨领域的 "跳转 "次数，大大提高了处理的迅速性。基本上，这大大提高了用户界面的响应速度。
另外，通过使用JSI，Fabric将UI操作以函数的形式暴露给JavaScript：新的Shadow Tree（决定屏幕上真正显示的内容）在两个领域之间共享，允许两端直接交互。
而且，如果这还不是一个很大的改进的话，这种来自JavaScript方面的直接控制允许拥有新的React（在第一篇文章中提到的）的UI操作的优先级队列，以便在有利于性能的地方有选择地同步执行。这个基础将允许改善常见的陷阱，如列表、导航和手势处理。
在当前的实现中，JavaScript代码使用的Native Modules（例如蓝牙）需要在打开应用时初始化--即使在不使用它们的时候也是如此--因为第一篇文章中提到的境界之间的 "无意识"。新的TurboModules方法允许JavaScript代码只在真正需要的时候才加载每个模块，并对其持有直接引用，这意味着不再需要在旧桥上使用批量JSON消息进行通信。这将大大改善拥有大量Native Modules的应用的启动时间，以及其他文章中提到的直接通信。
第三块的所有变化，如前所述，都依赖于前文中探讨的JavaScript接口。如果我们要总结一下Facebook新团队的架构到这一步的情况，应该是这样的。
至此，我们对重构架构的探索第三部分结束。下周我们将发布本系列的最后一篇文章。同时，记得与你的开发者朋友们分享这篇文章，或者在Twitter上联系后续问题（DMs是开放的）。
我们希望我们已经激发了大家对这些强大的变化将如何影响你的代码库的兴奋，而不需要任何重写。
所有的人都加入到炒作的行列中来吧
其他部分。
通过www.DeepL.com/Translator （免费版）翻译
