React Native was first introduced in 2015 as a solution for developing cross-platform applications with native capabilities using the ReactJS framework. The original design of the platform did not come without its set of flaws and drawbacks, despite the solution gaining strong community support and seeing gradual increase in popularity due to the fame of its Web counterpart.
React Native于2015年首次引入，是一种使用ReactJS框架开发具有本机功能的跨平台应用程序的解决方案。 尽管该解决方案获得了强大的社区支持，并且由于其Web同行的名声而逐渐普及，但该平台的原始设计并非没有其缺点和缺点。
Originally announced in 2018, the React Native re-architecture is an undergoing effort by the Facebook team to make the platform more robust and address some of the most common issues brought by developers over the years. We'll take a look on how this re-architecture will affect and improve both app performance and development velocity.
最初于2018年宣布， React Native重新架构是Facebook团队正在进行的一项工作，旨在使平台更强大并解决多年来开发人员带来的一些最常见问题。 我们将研究这种重新架构将如何影响并提高应用程序性能和开发速度 。
旧建筑 (The old architecture)
In essence, React Native aims to be a platform-agnostic solution. To that extent, the framework's main goal is to allow developers to write Javascript React code while, under the hood, React Native can deploy its mechanisms to transcribe the React reconciliation tree into something interpretable by whatever is the native infrastructure. This means:
本质上，React Native旨在成为一个与平台无关的解决方案。 在某种程度上，该框架的主要目标是允许开发人员编写Javascript React代码，而React Native可以在幕后部署其机制，以将React 和解树转录为可由本机基础结构解释的内容。 这表示：
- Displaying the UI correctly 正确显示用户界面
- Accessing native capabilities 访问本机功能
Typically, for the Android/iOS ecosystems, the mechanisms in place right now look a little bit like this:
通常，对于Android / iOS生态系统而言，目前存在的机制如下所示：
There are 3 parallel threads running in every React Native app:
每个React Native应用程序中运行着3个并行线程：
The JS thread is where all the JavaScript code is read and compiled, and where most of the business logic of the app happens. Metro generates the js bundle when the app is “bundled” for production, and the JavaScriptCore runs that bundle when the app starts.
JS线程是读取和编译所有JavaScript代码以及应用程序大多数业务逻辑发生的地方。 Metro将应用“捆绑”用于生产时会生成js捆绑包，而JavaScriptCore会在应用启动时运行该捆绑包。
The Native thread is responsible for handle the user interface. It communicates with the JS thread whenever there is a need to update the UI, or access native functions. It can be split into Native UI and Native Modules. Native Modules are all armed at startup, meaning that a Bluetooth module will always be bundled in case of use by React Native, even if it's not. It just wakes up when the app needs to use it.
本机线程负责处理用户界面。 每当需要更新UI或访问本机函数时，它将与JS线程通信。 它可以分为本机UI和本机模块 。 Native Modules都在启动时进行了武装，这意味着即使React Native不能使用，Bluetooth模块也将始终捆绑在一起。 它只是在应用需要使用时唤醒。
The Shadow thread is where the layout is calculated. It uses Facebook's own layout engine called Yoga to calculate flexbox layouts and send them back to the UI thread.
阴影线程是计算布局的地方。 它使用Facebook自己的名为Yoga的布局引擎来计算flexbox布局，并将其发送回UI线程。
To communicate between the JS thread and the Native thread, we use the Bridge. Under the hood, this C++ module is mostly built around an asynchronous queue. Whenever it gets data from one of either side, it serializes the data as a string and pass it through the queue, and deserialize it on arrival.
为了在JS线程和Native线程之间进行通信，我们使用Bridge。 在引擎盖下 C ++模块主要围绕异步队列构建。 每当它从任一方获取数据时，它都会将数据序列化为字符串并将其传递通过队列，并在到达时反序列化。
What this means is that all threads rely on asynchronous JSON messages transmitted across the bridge, and these are sent to either side with the expectation (but not a guarantee) that they will elicit a response some time in the future. And there's also a risk of congestion.
这意味着所有线程都依赖跨网桥传输的异步JSON消息 ，并且将它们发送到任何一方，但期望(但不能保证 )它们将在将来的某个时间引发响应。 而且还存在拥塞的风险。
A popular example of why this creates performance issues is seen with scrolling huge lists: Whenever an onScroll event happen on the native world, information is sent asynchronously to JavaScript land, but the native world doesn't wait for Javascript to do its thing and send it back the other way. This creates a delay where there’s a blank space before the info appears on the screen.
滚动巨大的列表可以看到一个为什么会导致性能问题的流行示例：每当本机世界发生onScroll事件时，信息都会异步发送到JavaScript领域，但是本机世界不会等待Java 脚本做事并发送反过来。 这会造成延迟，在屏幕上出现空白信息之前会出现空白。
Similarly, calculating a layout needs to go through many hoops before it can be displayed on the screen, as it needs to go all the way to the Yoga engine before it can be calculated by the native world. And this implies, of course, going through the bridge too.
类似地，计算布局需要经过很多次才能在屏幕上显示，因为它需要一直传递到Yoga引擎，然后才能被原生世界计算出来。 当然，这也意味着要经过这座桥 。
We can see how sending JSON data back and forth through async serialization creates performance issues, but how else can we make our JavaScript communicate with the native world? This is where JSI comes into play.
我们可以看到如何发送JSON数据来回通过异步串行化产生的性能问题，但我们还能 怎么做我们JavaScript与本土世界沟通？ 这就是JSI发挥作用的地方。
新架构 (The new architecture)
The React Native re-architecture will progressively see the deprecation of the bridge in favor of a new element called the JavaScript Interface (JSI). An enabler for Fabric and TurboModules.
React Native的重新架构将逐渐看到该桥的弃用，取而代之的是一个名为JavaScript Interface( JSI) 。 Fabric和TurboModules的启动器。
The JSI allows for a few exciting improvements, the first one being that JS bundle is not bound to the JSC anymore, it can use any other JS engine. In other terms, the JSC engine can now easily be swapped with other — potentially more performant — JavaScript engines, like V8 for example.
JSI进行了一些令人振奋的改进，第一个是JS捆绑包不再与JSC绑定，它可以使用任何其他JS引擎。 换句话说，现在可以轻松地将JSC引擎与其他(可能是性能更高的)JavaScript引擎(例如V8)互换。
The second improvement is the foundation of this new architecture: "By using JSI, JavaScript can hold reference to C++ Host Objects and invoke methods on them. JavaScript and Native realms will be truly aware of each other."
第二个改进是该新体系结构的基础：“通过使用JSI，JavaScript可以保留对C ++ 主机对象的引用并在其上调用方法。JavaScript和本机领域将真正相互了解。”
In other terms, JSI would allow for complete interoperability between all threads. With the concept of shared ownership, the JavaScript code could communicate with the native side directly from the JS thread, and there won’t be any need to serialize to JSON the messages to pass across, removing all congestion and asynchronous issues on the bridge.
换句话说，JSI将允许所有线程之间完全互操作 。 使用共享所有权的概念， JavaScript代码可以直接从JS线程与本机端进行通信，并且不需要将要传递的消息序列化为JSON，从而消除了网桥上的所有拥塞和异步问题。
In addition to improving considerably the communication between the different threads, this new architecture also allows for direct control over our native modules. Meaning that we can use native modules when we need them, as opposed to loading them all once at startup. This results in massive performance improvements of startup times.
除了显着改善不同线程之间的通信之外，这种新架构还允许直接控制我们的本机模块。 这意味着我们可以在需要时使用本机模块，而不是在启动时全部加载一次。 这样可以大大提高启动时间的性能。
This new mechanism could potentially also benefit many different use cases. As we have now the power of C++ in our hands, it's easy to see how React Native could be used to target a very large panels of systems.
这种新机制还可能使许多不同的用例受益。 既然我们已经掌握了C ++的强大功能，那么就很容易看出如何将React Native用来定位非常大的系统面板。
不仅如此！ (And that's not all!)
Over the years, React Native has accumulated a lot of parts that are now outdated, unused or otherwise legacy. With the main objective of cleaning the non-essential parts as well as improving maintenance, the React Native framework is seeing itself cleaned out of some its features. Meaning that core modules like Webview or AsyncStorage, are gradually being taken out of the React Native core to turn them into community managed repositories.
多年来，React Native已经积累了许多已经过时，未使用或以其他方式保留的零件。 以清理不必要的部分并改善维护为主要目的，React Native框架正在清除自身的某些功能。 这意味着诸如Webview或AsyncStorage之类的核心模块正逐渐从React Native核心中移出，以将其转变为社区管理的存储库。
With a new, lean core, and impressive mechanics of interoperability between the JavaScript code and the native code, the React Native re-architecture is set to see many performance improvements and a better developer workflow all-around.
凭借新的精益核心以及JavaScript代码与本机代码之间令人印象深刻的互操作性机制，React Native重新架构将带来许多性能改进和全方位更好的开发人员工作流。
With a roadmap aiming at a complete re-structuration done in the next few years, I am excited to make my apps more performant and my developer experience much, much smoother!
有了旨在在未来几年内进行全面重组的路线图，我很高兴能够提高我的应用程序的性能，使我的开发人员的工作经验更加流畅！
A big thanks to Lorenzo S. for the help and overall knowledge on the topic.
非常感谢 Lorenzo S. 提供了有关该主题的帮助和全面知识。
If you'd like to go deeper, I highly recommend his talk on this subject from which the slides in this article are taken from: https://www.youtube.com/watch?v=7gm0owyO8HU
如果您想更进一步，我强烈建议他就此主题进行演讲，本文中的幻灯片摘自该文章： https : //www.youtube.com/watch?v=7gm0owyO8HU
翻译自: https://medium.com/swlh/react-natives-re-architecture-in-2020-9bb82659792c
898
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
