反应原住民在2020年的重新建筑

Reaction Native于2015年首次引入，作为使用ReactJS框架开发具有本机功能的跨平台应用程序的解决方案。该平台的最初设计并不是没有缺陷和缺陷，尽管该解决方案获得了社区的大力支持，并由于其Web同行的知名度而逐渐受到欢迎。

最初于2018年宣布的Reaction Native重新架构是Facebook团队正在进行的一项努力，目的是使平台更强大，并解决开发人员多年来带来的一些最常见的问题。我们将看看这种重新架构将如何影响和提高应用程序的性能和开发速度。

原生反应是所谓的平台无关的解决方案。在这种程度上，框架的主要目标是允许开发人员编写Javascript REACT代码，而在幕后，REACTION Native可以部署其机制，将REACTION协调树转录成任何本机基础设施都可以解释的内容。这意味着：

通常，对于Android/iOS生态系统，现在的机制看起来有点像这样：

JS线程是读取和编译所有JavaScript代码的地方，也是应用程序的大部分业务逻辑发生的地方。Metro将所有Javascript代码组合到单个文件中，并转换任何替代的Javascript语法(如JSX或TS)。然后将此代码发送到JavaScriptCore引擎，以便它可以运行。

本机线程是运行本机代码的位置。每当需要更新UI或访问本机函数时，它都会与JS线程通信。它可以分为原生UI和原生模块。本地模块在启动时都是武装的，这意味着蓝牙模块在Reaction Native使用的情况下将始终处于活动状态，即使它不是。

阴影线是计算布局的位置。它使用Facebook自己的布局引擎Yoga来计算FlexBox布局，并将其发送回UI线程。

为了在JS线程和Native线程之间通信，我们使用Bridge。在幕后，这个C++模块是围绕一个异步队列构建的。每当它从任一端获得数据时，它都会将数据序列化为字符串，并将其传递给队列，然后在到达时对其进行反序列化。

这意味着所有线程都依赖于通过网桥传输的异步JSON消息，这些消息被发送到任何一端，并期望(但不能保证)它们将在未来某个时候引起响应。而且还有拥堵的风险。

这造成性能问题的一个常见例子是滚动巨大的列表：每当onScroll事件在原生世界发生时，信息就会异步发送到JavaScript领域，但原生世界不会等待Javascript完成它的工作并以另一种方式将其发回。这会在信息出现在屏幕上之前出现空格的情况下产生延迟。

同样，计算一个布局需要经过很多环节才能显示在屏幕上，因为它需要一直走到瑜伽引擎，才能被原生世界计算出来。在计算布局之前，它需要经过很多环节才能显示在屏幕上，因为它需要一直走到瑜伽引擎才能被原生世界计算出来。当然，这意味着也要通过这座桥。

我们可以看到通过异步序列化来回发送JSON数据是如何造成性能问题的，但是除此之外，我们如何才能让我们的JavaScript与本地世界通信呢？这就是JSI发挥作用的地方。

Reaction Native重新架构将逐渐看到桥的废弃，取而代之的是一种称为JavaScript Interface(JSI)的新元素。

JSI允许一些令人兴奋的改进，第一个是JS包不再依赖JSC。换句话说，JSC引擎现在可以很容易地与其他可能更高性能的JavaScript引擎进行交换，比如V8。

第二个改进是这个新体系结构的基础："；通过使用JSI，JavaScript可以保存对C++Host对象的引用并调用这些对象上的方法。JavaScript和原生领域将真正相互了解。

换句话说，JSI将允许所有线程之间的完全互操作性。有了共享所有权的概念，JavaScript代码可以直接从JS线程运行本机方法，并且不需要将要传递的消息序列化为JSON，从而消除了桥上的所有拥塞和异步问题。

除了显著改善不同线程之间的通信外，这个新的体系结构还允许直接控制我们的本机模块。这意味着我们可以在需要的时候使用本机模块，而不是在启动时一次性引导所有模块。这会大大提高启动时间的性能。

这一新机制还可能使许多不同的用例受益。由于我们现在手中掌握了C++的强大功能，因此很容易看到如何使用Reaction Native来瞄准非常大的系统面板。

多年来，Reaction Native积累了许多现在已经过时、未使用或其他遗留下来的部件。由于主要目标是清理不必要的部分以及改善维护，Reaction Native框架正在看到自己的一些功能被清理掉。这意味着像WebView或AsyncStorage这样的核心模块正逐渐从Reaction Native核心中移除，以将它们转变为社区管理的存储库。