鸿蒙NEXT（五）：鸿蒙版React Native架构浅析

鸿蒙版React Native架构

如图，React Native for OpenHarmony 在 React Native 的新架构（0.68以及之后的版本）的基础上，进行了鸿蒙化的适配。按照功能可以进行如下的划分：

• RN 应用代码：开发者实现的业务代码。
• RN 库代码：在 React Native 供开发者使用的组件和API的封装与声明。
• JSI（JavaScript Interface）：JavaScript 与 CPP 之间进行通信的API。
• React Common：所有平台通用的 CPP 代码，用于对 RN 侧传过来的数据进行预处理。
• OpenHarmony 适配代码：接收并处理 React Common 传过来的数据，对接原生的代码，调用 ArkUI 的原生组件与 API。主要包括了两个部分：分别是 TurboModule 与 Fabric。
• OS代码：对接系统底层功能，根据适配层代码传过来的数据进行渲染，或完成对应的功能。

React Native库代码

在现行的 React Native 中，有很多属性是在React侧完成的封装，也有很多属性是平台独有的。为了达成这个效果，React Native 在JS侧根据Platform增加了很多判断。所以，React Native 的鸿蒙化适配也需要增加HarmonyOS相关的平台判断，与相应的组件属性的封装。为此，鸿蒙化团队提供了react-native-harmony的tgz包，并通过更改metro.config.js配置，将该tgz包应用到 Metro Bundler中。

React Native 还提供了很多库的封装，例如Codegen、打包工具等。为此，鸿蒙化团队提供了react-native-harmony-cli的包，对这些库进行了HarmonyOS平台的适配，用于向开发者提供相关的功能。

Fabric

Fabric 是 React Native 的组件渲染系统。接收 React Native 传过来的组件信息，处理后发送给原生OS，由OS完成页面的渲染。

在适配方案中，组件不通过复杂的流程对接到ArkUI的声明式范式上，而是直接使用XComponent对接到ArkUI的后端接口进行渲染，缩短了流程，提高了组件渲染的效率。C-API的性能收益包括以下的几个部分：

• C端最小化、无跨语言的组件创建和属性设置；
• 无跨语言前的数据格式转换，不需要将string，enum等数据类型转换为object，可以在CPP侧直接使用对应的数据进行处理；
• 可以进行属性Diff，避免重复设置，降低了属性设置的开销。

渲染流水线请参考渲染三阶段。

TurboModule

TurboModule 是 React Native 中用于 JavaScript 和原生代码进行交互的模块，为RN JS应用提供调用系统能力的机制。根据是否依赖 HarmonyOS系统相关的能力，可以分为两类：cxxTurboModule和ArkTSTurboModule。

1. ArkTSTurboModule：

• ArkTSTurboModule为 React Native 提供了调用ArkTS原生API的方法。可以分为同步与异步两种。
• ArkTSTurboModule依赖NAPI进行原生代码与CPP侧的通信。包括JS与C之间的类型转换，同步和异步调用的实现等。

2. cxxTurboModule：

• cxxTurboModule主要提供的是不需要系统参与的能力，例如NativeAnimatedTurboModule主要提供了数据计算的相关能力。
• cxxTurboModule不依赖于系统的原生API，为了提高相互通信的效率，一般是在cpp侧实现，这样可以减少native与cpp之间的通信次数，提高性能。

React Native线程模型

RNOH线程模型

RNOH的线程一共有3个：

enum TaskThread {
  MAIN = 0, // main thread running the eTS event loop
  JS, // React Native's JS runtime thread
  BACKGROUND, // background tasks queue
};

MAIN/UI线程

RN业务主线程，也是应用主线，应用UI线程。该线程在应用中有唯一实例。

RN在MAIN线程中主要承