React-Native — 原理探究

作者: Tenloy | 来源:发表于2021-09-14 14:47 被阅读0次

本文主要大致介绍 React-Native 框架的底层原理，以及新架构的演变。

文章骨架主体来自React Native 原理与实践，很多细节上加以补充。关于新、旧架构的篇幅侧重增加了一些

一、什么是 React Native？

React Native 是一个由 Facebook 于 2015 年 9 月发布的一款开源的 JavaScript 框架，它可以让开发者使用 JavaScript 和 React 来开发跨平台的移动应用。它既保留了 React 的开发效率，又同时拥有 Native 应用的良好体验，加上 Virtual DOM 跨平台的优势，实现了真正意义上的：Learn Once,Write Anywhere.

二、React Native 的特点

2.1 跨平台

React Native 使用了 Virtual DOM(虚拟 DOM)，只需编写一套代码，便可以将代码打包成不同平台的 App，极大提高了开发效率，并且相对全部原生开发的应用来说，维护成本也相对更低。

2.2 上手快

相比于原生开发，JavaScript 学习成本低、语法灵活。允许让 Web 开发者更多地基于现有经验开发 App。React Native 只需使用 JavaScript 就能编写移动原生应用，它和 React 的设计理念是一样的，因此可以毫不夸张地说：你如果会写 React，就会写 React Native!

2.3 原生体验

由于 React Native 提供的组件是对原生 API 的暴露，虽然我们使用的是 JavaScript 语言编写的代码，但是实际上是调用了原生的 API 和原生的 UI 组件。因此，体验和性能足以媲美原生应用。

2.4 热更新

React Native 开发的应用支持热更新，因为 React Native 的产物是 bundle 文件，其实本质上就是 JS 代码，在 App 启动的时候就会去服务器上获取 bundle 文件，我们只需要更新 bundle 文件，从而使得 App 不需要重新前往商店下载包体就可以进行版本更新，开发者可以在用户无感知的情况下进行功能迭代或者 bug 修复。

但是值得注意的是，AppStore 禁止热更新的功能中有调用私有 API、篡改原生代码和改变 App 的行为。

2.5 Flutter vs React Native

首先来简单了解下 Flutter 和 React Native 的背景，Flutter 是由谷歌开发的软件开发工具包（SDK）。它可以帮助开发人员使用单一代码库构建 iOS 和 Android 应用程序。React Native 与 Flutter 具有相同的目的，但方式不同。它是由 Facebook 建立的，基于 React 用于创建移动应用程序，而不会影响应用程序的外观和感觉。

2.5.1 开发体验

React Native 在界面开发延续了 React 开发风格，支持 css-in-js(其实就是用 js 来写 css)，而且在 0.59 版本之后支持了 React Hook 函数式编程，开发的时候大多只关心样式界面的搭建，原生能力有客户端或者 Bridge 实现。

Flutter 最大的特点在于：Flutter 是一套平台无关的 UI 框架，并且在 Flutter 里面万物皆 Widget。很多时候开发一个控件需要嵌套多个 Widget 去实现，与 JS 里面的回调地狱有点像，而这也是被吐槽代码嵌套样式难看的原因。

2.5.2 状态管理

React Native 和 Flutter 对于状态管理，两者有着很高的相似度，虽然内部实现很大差别，但是都可以获取 state 和 setState 的方式去更新页面的状态。

2.5.3 产物

React Native 产生的是 bundle 文件，实际上就是 JS 脚本文件；而 Flutter 编译后 Android 产生的主要是一些应用程序指令段、数据段，虚拟机数据段、指令段，iOS 则是 App.framework，其实也是一些原生的数据集。

2.5.4 原生能力 & 性能

其实两者的在这方面的区别不是很大，性能方面 React Native 稍微差一点。

由于 React Native 和原生交互依赖的只有一个 Bridge，而且 JS 和 Native 交互是异步的，所以对需要和 Native 大量实时交互的功能可能会有性能上的不足，比如动画效率，性能是不如原生的。

React Native 始终是依赖原生的能力，所以摆脱不了对原生的依赖，相对 Flutter 的自己来画 UI 来说，React Native 显得有些尴尬。

但是在原生灵活性上 React Native 要有优势。

最后，目前来看两者是不分上下，各有所长。不过随着RN新架构的展开，性能方面的劣势会有很大改善。

三、React Native 原理

3.1 当前架构

在 React Native 里面，真正有三个重要的线程在执行，他们分别是 Shadow thread、UI thread 和 JS thread。

JS thread。是读取和编译所有 JavaScript 代码、处理应用程序大部分业务逻辑的地方。
- Metro（打包工具）将React源码打包成一个单一JS文件(就是图中JSBundle)。然后传给JS引擎执行（现在ios和android统一用的是JSC）。
- JS thread 负责 JS 和原生代码的交互，因为 JS 是单线程模型，所以需要一个单独的线程来驱动，并且 JS 和 Native 交互(Bridge)是异步的。
UI Thread(Main Thread/Native thread)。这个线程主要负责两部分：
- 原生渲染（Native UI）：负责页面的交互，以及当显示、更改UI时，完成控件绘制逻辑。
- 调用原生功能(Native Modules)：比如蓝牙等。当我们使用应用程序时，所有本地模块都会启动。这意味着即使不需要使用蓝牙模块，React Native 也将始终激活它。
Shadow Thread。是 React Native 计算布局的地方。
- 这个线程会创建Shadow Tree来模拟React结构树。Shadow Tree可以类似虚拟dom。
- 它使用 Facebook 自己的名为 Yoga 的布局引擎来计算 flexbox 布局，然后将结果发送到 Native UI（RN使用Flexbox布局，但是原生是不支持，所以Yoga就是用来将Flexbox布局转换为原生平台的布局方式）。

3.2 JavaScriptCore

JavaScriptCore 是 JavaScript 引擎，通常会被叫做虚拟机，专门设计来解释和执行 JavaScript 代码。在 React Native 里面，JavaScriptCore 负责 bundle 产出的 JS 代码的解析和执行。

3.2.1 JS Engine

React Native 需要一个 JS 的运行环境，因为 React Native 会把应用的 JS 代码编译成一个 JS 文件（x x.bundle），React Native 框架的目标就是解释运行这个 JS 脚本文件。

如果是 Native 拓展的 API，则直接通过 bridge 调用 Native 方法，最基础的比如绘制 UI 界面，映射 Virtual DOM 到真实的 UI 组件中。

脱离 React Native，纯原生端是如何与 JS 交互的？来看下 iOS 里面是如何实现的。

在 Native 创建一个 JS 上下文：

// 创建一个ctx的JS上下文
JSContent *ctx = [[JSContent alloc] init];
// 创建一个变量name
[ctx evaluateScript:@"var name = 'Hellen'"];
// 创建一个方法
[ctx evaluateScript:@"var hello = function(name) { return 'hello ' + name }"];

Native 调用 JavaScript 方法：

// 通过ctx上下文对象，获取到hello方法
JSValue *helloFUnction = ctx[@"hello"];
// 运行js方法
JSValue *greetings = [helloFunction callWithArguments:@[@"bytedancers"]; // hello bytedancers

所以，JavaScript 代码只要将变量暴露在 JS 上下文全局，Native 就能获取到，并运行 JS 的代码。

JavaScript 调用 Native，首先需要在 Native 端，将一个变量暴露在 JS 上下文全局，在 JavaScript 全局变量里面就能获取到并执行这个方法：

ctx[@"createdByNative"] = ^(NSString *name) {
    // do something
    return someResult
}

React Native 同样借助 JS Engine 的能力，基于 JavaScriptCore 来执行 JS，但是是通过 Bridge 来进行交互的，JS 不会直接引用 Native 层的对象实例，Native 也不会直接引用 JS 层的对象实例(在 React Native 里所有 Native 和 JS 互调都是通过 Bridge 层的几个最基础的方法衔接的)。

3.2.2 Hermes Engine

Hermes 是 Facebook 在 2019 年发布的新一代 JS Engine，Hermes 是一款小巧轻便的 JavaScript 引擎，专门针对在 Android 上运行 React Native 进行了优化：应用启动时间减少、减少内存使用量并缩小应用程序大小，此外因为它采用 JavaScript 标准实现，所以很容易在 React Native 应用中集成。

3.2.3 Hermes vs JavaScriptCore vs V8

经过官方的数据验证，Faceback 团队提出的关键性指标相较于原先的 JavaScriptCore 方案都有了显著提高。首先，是产物文件的大小方面，RN 所依赖的必要 so 库，Hermes 比 JavaScriptCore 减少了约 16%，V8 则要远大于 Hermes 和 JavaScriptCore。

3.3 Bridge

上面我们有提到 JS Engine，Native 可以把原生方法暴露到全局，同样的 JS 也可以把方法暴露给 Native，但是 React Native 并没有这样做，原因之一是这样会导致大量的全局变量污染，所以为了规范这个通信过程，React Native 自己实现了 Bridge。

Bridge 定义了 JS Thread 和 Native Thread 的通信规范，实现原生端和 JavaScript 之间的交互。
Bridge 给 React Native 内嵌的 JS Engine 提供原生接口的扩展，供 JS 调用（做定制化的时候会对 Bridge 添加修改代码）。
所有的本地存储、图片资源访问、图形图像绘制、3D 加速、网络访问、震动效果、NFC、原生控件绘制、地图、定位、通知等都是通过 Bridge 封装成 JS 接口以后注入 JS Engine 供 JS 调用。

理论上，任何原生代码能实现的效果都可以通过 Bridge 封装成 JS 可以调用的组件和方法，以 JS 模块的形式提供给 RN 使用。

3.3.1 Bridge的运行过程

为了让，我们需要使用一个名为 Bridge 的 C++ 模块。

当我们写了类似下面的React源码。

<View style={{
        backgroundColor: 'pink',
        width: 200, 
        height: 200}}/>

JS thread会先对其序列化，形成下面一条消息

UIManager.createView([343,"RCTView",31,{"backgroundColor":-16181,"width":200,"height":200}])

通过Bridge发到ShadowThread。Shadow Tread接收到这条信息后，先反序列化，形成Shadow tree，然后传给Yoga，形成原生布局信息。
接着又通过Bridge传给UI thread。
UI thread 拿到消息后，同样先反序列化，然后根据所给布局信息，进行绘制。

从上面过程可以看到三个线程的交互都是要通过Bridge，因此瓶颈也就在此。

Bridge的三个特点：

异步。这些消息队列是异步的，无法保证处理事件。

所有基于 JSON 信号流的线程都通过 Bridge 异步传输，并且它们将被发送到任何一方，希望（但不是保证）会收到响应。未来，您也可能会遇到信息拥塞并且永远不会收到响应。
序列化。每当它从任何一方（JS 线程或本地线程）接收数据时，这些数据将被序列化为 JSON 并发送到队列，最终在到达时进行解码。

通过JSON格式来传递消息，每次都要经历序列化和反序列化，开销很大。
批处理。对Native调用进行排队，批量处理。

3.3.2 Bridge的实现细节

1. RCTRootView

原生项目如果想用 React Native，那么就需要用到 RCTRootView，它是 React Native 加载的地方，可以把它看作是一个容器。

// RCTRootView.m
- (void)javaScriptDidLoad:(NSNotification *)notification{
  RCTAssertMainQueue();
  RCTBridge *bridge = notification.userInfo[@"bridge"];
  if (bridge != _contentView.bridge) {
    [self bundleFinishedLoading:bridge];
  }
}

- (void)bundleFinishedLoading:(RCTBridge *)bridge{
  // 省略创建RCTRootContentView...

  [self runApplication:bridge];

  // 省略添加一个RCTRootContentView...
}

- (void)runApplication:(RCTBridge *)bridge{
  NSString *moduleName = _moduleName ?: @""; // 这里是@"NewProject"
  NSDictionary *appParameters = @{
            @"rootTag": _contentView.reactTag,
            @"initialProps": _appProperties ?: @{},
  };

  [bridge enqueueJSCall:@"AppRegistry"
                 method:@"runApplication"
                   args:@[moduleName, appParameters]
             completion:NULL];
}

上面的源码(iOS)可以看出 RCTRootView 其实做了这些事情：

创建了负责 React Native 和 Native 通信的 RCTBridge 实例的初始化。
初始化了真正展示视图的 RCTRootContentView。
通过 runApplication 方法把必要的参数（moduleName, params）传给 JS 侧的 AppRegistry 的 runApplication 方法，从而运行起了 React Native 的功能。（在 React native 中，根组件是需要通过 AppRegistry 的 registerComponent 方法进行注册的。所谓根组件，就是 Native to JS 的入口文件）

渲染过程：

2. Native 调用 JS

在 React Native 里面，JS 的方法可以通过 global.batchedBridge.callFunctionReturnFlushedQueue 这个方法进行调用，所以在 Native 侧，只需将 React Native 里面的 global.batchedBridge 对象中的方法和 Native 侧的 JSIExecutor 方法进行绑定（本质上 Native 指针指向 JS 函数）

JSIExecutor::callFunctionReturnFlushedQueue_ = global.batchedBridge.callFunctionReturnFlushedQueue

Native 侧的 callFunctionReturnFlushedQueue 主要做了这样的事情：

通过 moduleid 和 methodid 完成方法的调用，通过这两个参数可以找到 JS 侧定义的方法模块。

3. JS 调用 Native

React Native 中的 Native 模块如何暴露给 JS？

我们知道，React Native 可以调用 Native 侧的方法，并且只要 Native 侧只要遵循一定的规则，是可以将方法暴露给 JS 调用的：

// iOS端原生代码
#import <Foundation/Foundation.h>
#import <React/RCTBridgeModule.h>

@interface NativeLogModule : NSObject<RCTBridgeModule>

@end

#import "NativeLogBridge.h"

@implementation NativeLogModule
RCT_EXPORT_MODULE()
RCT_EXPORT_METHOD(nativeLog:(id)obj) {
  NSLog(@"%@",obj);
}
@end

// JS端调用
import { NativeModules } from 'react-native';
NativeModules.NativeLogModule.nativeLog('从JS侧来的消息');

可以看到，上面的代码中使用了RCT_EXPORT_MODULE() 宏将 Native 类以 module 的形式暴露给了 JS，然后使用了RCT_EXPORT_METHOD将 Native 的方法暴露给 JS，最后在 JS 侧直接引用一个模块，便可以直接调用暴露的方法与 Native 通信。

JS 调用 Native

当 JS 调用 Native 模块的时候，会调用一个 Native 暴露出来的全局方法：nativeFlushQueueImmediate，并通过传入要调用的 moduleName 、methodName、callback 参数给这个方法，然后这个方法再通知给 Native 侧找到相应的模块并执行。

3.3.3 Bridge的问题

异步设计的好处是不阻塞，这种设计在大部分情况下性能满足需求，但是在某些情况下就会出问题，比如瀑布流滚动。

当瀑布流向下滑动的时候，需要发请求给服务端拿数据进行下一步渲染。

滚动事件发生在UI thread，然后通过Bridge发给JS thread。JS thread 监听到消息后发请求，服务端返回数据，再通过Bridge返回给Native进行渲染。由于都是异步，就会出现空白模块，导致性能问题。

从上面可以看出，性能瓶颈主要是存在JS线程和Native有交互的情况，如果不存在交互，RN的性能良好。

因此，对于RN的优化，主要集中在Bridge上，有下面3个原则：

JS和Native端不通信。最彻底的方式，消息不走Bridge。
JS和Native减少通信。在两端无法避免的情况下，尽量通信减少次数。比如多个请求合并成一个。
较少JSON的大小。比如图片转为Base64会导致传输数据变大，用网络图片代替。

RN里面可以通过MessageQueue来监听Bridge通信，主要代码如下

import MessageQueue from 'react-native/Libraries/BatchedBridge/MessageQueue.js';

const spyFunction = (msg) => {
  console.log(msg);
};

MessageQueue.spy(spyFunction);

下面是监听到的信息

3.4 Virtual DOM

在认识 Virtual DOM 之前，我们先来看看浏览器的工作原理：

浏览器有一套完整的 UI 控件，样式和功能都是按照 HTML 标准实现的。
浏览器能够解析 HTML 和 CSS，通过 HTML 告诉浏览器需要生成什么类型的 UI 控件，并通过 CSS 样式文件来描述该 UI 控件的外观（大小，背景，布局等等...）。
浏览器的主要作用就是解析 HTML 和 CSS 来形成渲染树，并通过 Render Engine 将页面渲染出来。

了解浏览器的工作原理之后，Virtual DOM 是如何工作的？

首先 Virtual DOM 和真实 DOM 都有一个共同点：都是用来描述页面 UI 控件。
Virtual DOM 具有平台无关性：它描述的 UI 控件只是数据结构层的，具体渲染工作是交给了原生渲染引擎（浏览器、iOS、Android）去处理。

3.4.1 React (Native)的 Virtual DOM

在 React Native 里面，是如何把 Virtual DOM 渲染成真实的 UI 的呢？

首先，在 React 里面，用来表示 dom 属性的对象有以下关键属性：

var ele = {
    ...
    type: type, // 元素的类型
    key: key, // 元素key标示
    ref: ref, // 元素的引用
    props: props, // 元素的参数，包含children
    ...
}

// example 1
<div>hello</div>
// 会被描述为

{type: 'div',
    props: {
        children: ['hello']
    }
}

// example 2
<CustomerComponents />
// 会被描述为
{
    type: CustomerComponents
}

React 里面的 Virtual DOM 把真实 DOM 分为了以下几种类型：

原子类型
- 类型为字符串，结构上不可再分解，渲染由平台底层支持。
- 在浏览器端：原子类型表示为浏览器支持的原始标签，例如 div、ul、li、p、a、span 等等。
- 在 Native 端：原子类型表示为 Native 端的各种基础 UI 组件，例如 RCTText、RCTView 等等
组合类型
- 类型为函数构造器，它给我们提供了一种自定义元素 UI 和行为的能力，当渲染器遇到组合类型的元素时，会使用它的构造器创建一个实例并运行 render 方法得到一个新元素（原子类型，或者组合类型），然后再拿该元素继续进行渲染或者分解。
- 用户自定义的组件元素。

3.4.2 渲染器 — 浏览器端

在浏览器端和 Native 端，React (Native)中 Virtual DOM 用来渲染真实 DOM 的渲染器是不一样的：

在浏览器端：

// 文本类型渲染器工作原理
mountComponent: function(
    transaction,
    hostParent,
    hostContainerInfo,
    context
) {
    // 获取到DOM对象
    var lazyTree = DOMLazyTree(ownerDocument.createDocumentFragment());
    // 判断是不是文本类型
    if (this._stringText) {
        DOMLazyTree.queueChild(
            lazyTree,
            DOMLazyTree(ownerDocument.createTextNode(this._stringText))
        );
    }
    return lazyTree
}

// 原子类型渲染器工作原理
mountComponent: function(
    transaction,
    hostParent,
    hostContainerInfo,
    context
) {
    var ownerDocument = hostContainerInfo._ownerDocument;
    // 创建原子type类型dom
    var el = 
ownerDocument.createElement(this._currentElement.type)
    ...

    // 创建子节点
    this._createInitialChildren(transaction, props, context, lazyTree);
    ...
}

// 组合类型渲染器工作原理
mountComponent: function(
    transaction,
    hostParent,
    hostContainerInfo,
    context
) {

    // 运行构造器，获取到组件实例

    var inst = this._constructComponent({
        doConstruct,
        publicProps,
        publicContext,
        updateQueue,
    });

    ...

    // 获取到虚拟dom
    if (renderedElement === undefined) {
      renderedElement = this._renderValidatedComponent();
    }

    ...

    // 获取到分解后的组件类型（ReactXXXComponent,可以看作是三种组件类型的集合）
    this._renderedComponent = this._instantiateReactComponent(
      renderedElement
    );
    // 最后通过ReactReconciler.mountComponent间接的调用不同类型的渲染器的mountComponent方法获取到生产的node节点，并返回。
    var markup = ReactReconciler.mountComponent(
      this._renderedComponent,
      rootID,
      transaction,
      this._processChildContext(context)
    );

    return markup
}

看以下代码结构：

3.4.3 渲染器 — Native端

在 Native 端：

在浏览器里面，JavaScript 可以调用 DOM API 去完成创建 UI 的工作，而在 React Native 里面，是通过 UI Manager 来创建视图的，基于 Virtual DOM ，React Native 把不同平台创建视图的逻辑封装了一层，不同平台通过 Bridge 调用 UI Manager 来创建不同的 Native 视图。

3.5 热更新

React Native 的产物 bundle 文件，本质上是 JS 的逻辑代码加上 React Native 的 Runtime 的集合，所以在应用一启动的时候就会去获取 bundle 文件，之后解析 bundle 文件，最后再由 JS Engine 去执行具体的业务代码逻辑。这就可以允许开发者在云端去更新 bundle 文件，然后应用启动的时候获取最新的 bundle 文件，这一整个流程下来就实现了热更新。

3.5.1 增量更新（拆包）

对于 React Native 的代码打包之后只会生成一个 Bundle 文件，这里面包含了基础业务逻辑、React Native 的基础库类，所以我们可以把一个包拆分成：一个基础包+ n 个业务包，其中基础包是不变的，这就是 runtime，业务包就是具体的业务，后面如果有更新，也只需要再打出一个业务包就行。

目前行业的解决方案有 facebook 官方提供的 metro bundle：facebook.github.io/metro/

四、React Native新架构

FB团队逐渐意识到Bridge存在的一些问题，同时也受到Flutter的压力，在2018年提出了新架构：移除了Bridge，取而代之的是一个名为 Javascript Interface (JSI) 的新组件。

新的架构主要由 JSI、Fabric、TurboModules、CodeGen、LeanCode组成。

4.1 JSI

JSI(Javascript Interface)是整个架构的核心和基石，所有的一切都是建立在它上面。用于取代原先的 bridge，提高通信效率，JSI 已经跟随 RN 0.59 (JSIExecuter.cpp) 发布。

JSI 本身不是 React Native 的一部分——它是一个统一的、轻量的、通用适用于任何(理论上) JavaScript 虚拟机的接口层。让各种平台可以方便地使用不同的 JavaScript 解析引擎（JavaScript virtual machine 包含 JavaScript Engine）。

当把 JSI 加入到新架构中后，它使得一些真正重要的改进成为可能。

第一个改进很直观 —— 有了JSI，JS引擎不再局限于JSC。换句话说，JSC 引擎现在可以与其他具有更好性能的 JavaScript 引擎交换，比如微软的 ChakraCore 和谷歌的 V8等，进一步提高JS解析执行的速度。
通过JSI，JS对象可以直接持有C++宿主对象(Host Objects)引用，并调用它们的方法。

宿主对象：由宿主环境提供的对象，对应Native Object。如JavaScript中，浏览器宿主环境中的window对象以及其下边所有的子对象(如bom、dom等等)，node宿主环境中的globla及其子对象。

这意味着：自此三个线程通信再也不需要通过Bridge，JavaScript 和 Native 之间真正地相互知晓，并且不再需要通过 JSON 序列化传递消息，这会消除 Bridge 的阻塞问题。不像原来那样用一层 bridge 来排队等待原生层返回的消息，让同步通信成为现实。具体的用法可以看官方例子。

JS -> JSI -> C++ -> ObjectC/Java

4.2 Fabric

Fabric是整个架构中的新UI层，包括了新架构图中的renderer和shadow thread。

下图是旧的通信模型。

三个线程通过Bridge异步通信，数据需要拷贝多份。

有了JSI以后，JS可以直接掉调用其他线程，实现同步通信机制。另外数据可以直接引用，不需要拷贝，于是就变成了下面新的通信模式.

除了同步能力，直接引用，另外一个好处是Fabric现在支持渲染优先级比如React的Concurrent和Suspense模式

下面两张图是从启动到渲染阶段，加入Fabric前后的变化。

改造为Fabric之后

4.3 TurboModules

TurboModules主要和原生应用能力相关，对应新架构图上的Native Modules，这部分的优化是：

通过JSI，可以让JS直接调用Native模块，实现一些同步操作。比如调用摄像头能力。
Native模块懒加载。之前RN框架启动的时候会加载所有Native模块，导致启动慢，时间久。现在有了TurboModules后，可以实现按需加载，减少启动时间，提高性能。

4.4 CodeGen

通过CodeGen，自动将Flow或者Ts等有静态类型的JS代码翻译成Fabric和TurboModules使用的原生代码。

4.5 Lean Core

这部分主要是包的瘦身，以前所有的包都放在RN核心工程里面。现在RN核心只保留必要的包，其他都移到react-native-community 或者拆出单独的组件，比如Webview和AsyncStore。

4.6 开发进度

2018 年 6 月，Facebook 曾在宣布了大规模重构 RN 的计划和路线图；
期间，JSI、LeanCore、Fabric、TurboModules一项一项陆续开发完成；
2021 年 7 月 14 日，React Native 核心团队的 Joshua Gross 在 Twitter 说，RN 的新架构已经在 Facebook 内部落地了，并且 99%的代码已经开源。

4.7 性能评价

引自React Native 迎来重大架构升级，性能将大幅提升

重构目的是为了让 RN 更轻量化、更适应混合开发，接近甚至达到原生的体验。具体包括以下几个方面：

改变线程模型。UI 更新不再同时需要在三个不同的线程上触发执行，而是可以在任意线程上同步调用 JavaScript 进行优先更新，同时将低优先级工作推出主线程，以便保持对 UI 的响应。
引入异步渲染能力，允许多个渲染并简化异步数据处理。
简化 JSBridge，让它更快更轻量。

这次升级过后，RN 在性能上能够追平 Flutter。首先，JavaScript 和 Dart 语言上都支持了 AOT 预编译，打个平手。其次，JavaScript 和 Dart 和底层交互都是通过 C++ 进行的，也是打个平手。最后，RN 原生组件绘制有平台的优化加成，相对于 Flutter 自绘引擎绘制，可能还会好上一些。

除了显着提升线程之间的通信性能外，这种新架构还让我们可以直接控制 Native Modules。也就是说，可以仅在需要时使用原生模块，而不是在启动应用程序时将它们全部激活。

这为应用程序启动时间提供了显着的性能改进。这种新机制有可能在许多不同的用例中使我们受益。例如，现在我们掌握了 C++ 的强大功能，很容易看出 React Native 是如何用于大型系统目标的。