Taro x 纯血鸿蒙​

在过去的一年中，Taro 经历了显著的蜕变，Taro on Harmony 方案完成从 ArkTS 方案到 C-API 方案的升级，成功实现了对纯血鸿蒙的完全适配，扩展了 Taro 的兼容平台家族，实现了对 H5、小程序、RN、原生鸿蒙多端的统一开发。

去年 9 月，京东 APP 纯血鸿蒙 在鸿蒙应用商城正式上线，APP 中核心购物链路，如首页、搜索、商详、购物车、订单、结算和我京等页面，都是通过 Taro on Harmony C-API 版本进行开发，并且一上线就获得了华为的 S 级应用认证。

今天，我们正式开源 Taro on Harmony C-API 版本，这次版本的发布，将带来更丰富的样式适配、更高效的渲染性能、更全面的组件支持，让开发者以 Web 范式的方式来开发出媲美原生鸿蒙性能的应用，为鸿蒙应用生态的丰富注入强大的动力。

对于开发者来说，Taro on Harmony 技术方案为开发者提供了显著优势：显著降低鸿蒙应用开发门槛，让开发者能够运用熟悉的 Web 技术栈快速构建纯血鸿蒙应用。同时，基于鸿蒙 CAPI 构建的高性能渲染管线，在保证开发高效率的同时实现了与原生应用媲美的性能表现。更重要的是，开发者可以充分复用现有研发生态，将存量 Taro 项目快速适配迁移至鸿蒙平台，大幅加速业务在鸿蒙生态的布局与上架进程。

整体技术架构​

Taro on Harmony 技术方案支持开发者使用 React DSL 来开发纯血鸿蒙应用，整体架构可以简单分为三层：

最上层是应用业务代码所在的 ArkVM 层，这一层在 C-API 版本中主要运行业务代码、React 的核心代码以及少量的 Taro 运行时代码。

中间层是 Taro 的 CSSOM 和 TaroElement 树，负责处理上层 Taro 运行时代码传递下来的指令，比如 TaroElement 节点树创建，绑定关系以及设置属性等操作。

最下层存放的是 TaroRenderNode 虚拟节点树，这棵节点树和真正的上屏节点树是一一对应的关系，同时在 TaroRenderNode 节点树内会创建对应的 Yoga 节点。

同时 Taro 还基于鸿蒙提供的 VSync 机制设置一套任务处理管线，来处理中间层和下层节点树产生的样式匹配、节点测量、节点布局、样式设置以及节点上屏等任务，来保证任务的时序性和最后上屏渲染结果的正确性。

重点特性​

丰富的能力支持​

常用组件和 API 支持​

在 C-API 版本的 Taro on Harmony 中，我们不仅完整支持了 React 18+，另外支持了 View、Text、Image、Video 等近 33 个 Taro 组件，对于常用的 API，如 getSystemInfo、getStorage 等也是在 C-API 版本中得到了完整的支持，而且针对逻辑较为复杂的 API 如：createSelectorQuery 以及 createIntersectionObserver，我们将这些 API 在 C++ 侧进行了重新的实现，大幅提升了他们的执行性能。

常用样式支持​

在 C-API 版本中，我们对支持了大部分常见的 CSS 能力：

• 支持常见的 CSS 样式和布局，支持 flex、伪类和伪元素
• 支持常见的 CSS 定位，绝对定位、fixed 定位
• 支持常见的 CSS 选择器和媒体查询
• 支持常见的 CSS 单位，比如 vh、vw 以及计算属性 calc
• 支持 CSS 变量以及安全区域等预定义变量

同时，我们参考浏览器 CSSOM 的实现方式，在 C++ 实现了一套 CSSOM 逻辑，里面包含了样式解析、样式匹配、样式合成和应用整个链路的样式处理逻辑。

另外，Taro 引入了 Yoga 布局引擎来计算渲染节点的位置和大小，最大程度保证 Taro 构建出来的鸿蒙应用中渲染样式和 W3C 规范的一致性。

媲美原生 ArkTS 的高性能​

运行时逻辑下沉至 C++​

在 C-API 的版本中，我们将 ArkVM 层的 Taro 运行时内容削减到极致的薄，将 TaroElement 的大部分内容都下沉到了 C++ 侧，并在 ArkVM 层取消了他们之间父子关系的绑定，极大地提升了 TaroElement 相关逻辑的性能。

另一方面，在 C++ 侧 Taro 会指令式地调用 ArkUI 在 C++ 侧提供的 API，来高效地创建节点、设置属性、绑定事件以及绘制上屏。

提供长列表组件应对长列表场景​

Taro 还针对长列表场景针对性地提供了长列表类型组件，并对长列表类型组件进行了优化，提供了懒加载、预加载和节点复用等功能，有效地解决大数据量下的性能问题，提高应用的流畅度和用户体验。

支持 C-API 混合原生的渲染模式​

Taro 的组件和 API 是以小程序作为基准来进行设计的，因此在实际的鸿蒙应用开发过程中，会出现部分所需的组件和 API 在 Taro 中不存在的情况，因为针对这种情况，在 C-API 版本中，Taro 提供了原生混合开发的能力，支持将原生页面或者原生组件混合编译到 Taro 鸿蒙项目中，支持 Taro 组件和鸿蒙原生组件在页面上的混合使用。

使用教程​

项目开源地址​

Taro 本地开源地址：https://github.com/NervJS/taro

Taro 鸿蒙 C-API 开源地址：https://github.com/NervJS/taro-harmony-capi-library

安装和使用​

安装 harmony 插件​

# 使用 npm 安装
$ npm i @tarojs/plugin-platform-harmony-cpp
# 使用 pnpm 安装
$ pnpm i @tarojs/plugin-platform-harmony-cpp

添加插件配置​

import os from 'os'
import path from 'path'

const config = {
  // ...
  plugins: ['@tarojs/plugin-platform-harmony-cpp'],
  harmony: {
    // 当前仅支持使用 Vite 编译鸿蒙应用
    compiler: 'vite',
    // Note: 鸿蒙工程路径，可以参考 [鸿蒙应用创建导读](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V2/start-with-ets-stage-0000001477980905-V2) 创建
    projectPath: path.join(os.homedir(), 'projects/my-business-project'),
    // Taro 项目编译到对应鸿蒙模块名，默认为 entry
    hapName: 'entry',
  },
  // ...
}

编译项目​

# 编译鸿蒙应用
$ taro build --type harmony_cpp
# 编译鸿蒙原生组件
$ taro build native-components --type harmony_cpp

如果需要编译鸿蒙应用，同时使用编译鸿蒙原生组件，可以在页面配置中添加  entryOption: false  表示该页面是组件，同时可以用过  componentName  指定组件导出名。

export default {
  navigationBarTitleText: 'Hello World',
+  componentName: 'MyComponent',
+  entryOption: false,
}

总结与展望​

Taro on Harmony C-API 版本经历了京东鸿蒙 APP 的实践，综合性能、生态以及开发体验来讲，毫无疑问已经成为了开发鸿蒙应用的最佳框架选型之一。

当下，我们也仍然在不断完善着鸿蒙的适配方案，基于当前的 Taro on Harmony C-API 方案，我们会进行多线程的架构升级以及 React 的 C++ 化，进一步提升 Taro 在鸿蒙端侧的性能，并极大地降低应用的丢帧率，整体进展也已经处于验证和测试阶段。

也欢迎大家一起参与 Taro on Harmony 的共建，你们的每一个建议，每一次提交，都是推进 Taro 继续往前走最大的动力。

纯血鸿蒙逐渐成为全球第三大操作系统，业界也掀起了适配鸿蒙原生的浪潮，用户迁移趋势明显，京东作为国民应用，为鸿蒙用户提供完整的购物体验至关重要。

去年 9 月，京东 APP 纯血鸿蒙 在鸿蒙应用商城正式上线，APP 中核心购物链路，如首页、搜索、商详、购物车、订单、结算和我京等页面，都是通过 Taro on Harmony 方案进行开发，并且一上线就获得了华为的 S 级应用认证。

Taro 介绍​

Taro 是由京东发起并维护的开放式跨端跨框架解决方案，支持以 Web 的开发范式来实现小程序、H5、原生 APP 的跨端统一开发，从 18 年开源至今，在 GitHub 已累计获得 36,000+ Stars。

在过去的一年中，Taro 完成了鸿蒙适配方案的开发，Taro on Harmony 方案支持开发者使用 React DSL 来快速开发高性能原生鸿蒙应用，让 Taro 具备了一份代码同时跨鸿蒙、小程序、H5、React Native 多端的能力，可以让开发者以熟悉的方式来开发鸿蒙应用，大幅降低鸿蒙开发门槛，并且存量的 Taro 业务也能快速转成鸿蒙原生应用，可以节约大量研发成本。

Taro on Harmony 适配方案的演进​

基于 ArkTS 的初始版本​

Taro 适配鸿蒙方案经过了多个版本的演进迭代，最初版本我们采用的是对接到鸿蒙原生 ArkTS 语言的方式来实现，这和 Taro 适配微信小程序的方案类似，都是通过模拟浏览器 DOM/BOM 环境，然后运行 React 代码构建出虚拟 DOM 树，再将虚拟 DOM 树以递归遍历的方式构建出宿主环境（小程序/鸿蒙）的渲染节点树，从而实现页面渲染。

但这个方案的缺陷非常明显，那就是在 ArkTS 之上再桥接一层转换，导致性能相比原生存在一定差异，并且这个差异几乎没有办法可以抹平。

基于 C API 的全新版本​

恰逢此时，鸿蒙为了方便三方框架与应用接入鸿蒙生态，在官方开发语言 ArkTS 之外，开放了更底层 C API 能力，提供了 C++ 层的 UI 节点创建、属性设置等能力（类似于 C++ 版本的 DOM），三方框架和应用可以基于 C API 构建高性能的解决方案和应用。

C API 就是 Taro 想要的能力，与 Taro 的架构完美契合，Taro React 构建出来的虚拟 DOM 树可以通过 C API 直接去创建原生 UI 节点，省去了很多流程环节，并且可以将我们大部分的渲染管线处理沉到 C++ 中去，获得飞跃式的性能提升，所以基于 C API 我们首先设计并开发了单线程架构版本。

单线程架构版本​

单线程架构版本的示意图如下，整个渲染过程均在主线程实现，业务代码在 ArkVM 中执行获得虚拟 DOM 树，同时读取样式数据，通过 React Reconciler ，在构建虚拟树时会调用 NAPI 在 C++ 侧构建出对应的 Element Tree，同时也会进行样式数据的解析处理，从而构建出 CSSOM 对象，Element Tree 和 CSSOM 对象会进行匹配从而构建出带有样式的 Render Tree，在这一步也会同时创建 yoga 节点，进行布局计算，最后会再基于布局计算的结果生成 C API 的 ArkNode Tree，从而实现上屏渲染。

目前京东鸿蒙 APP 中首页、搜推、我京、核心购物流程均是使用 Taro 单线程版本进行开发，性能和稳定性位于第一梯队。

多线程架构版本​

单线程版本上线之后，我们也发现了单线程架构的不足，① 从业务代码的执行到渲染流程的处理都发生在主线程上，这导致了主线程的过载，使得应用无法及时响应用户的操作，从而引发了用户体验上的卡顿，随着业务逻辑的增加和复杂性的提升，这种卡顿现象会越发明显；② 在单线程架构下，代码都是需要内置到应用包里，这样就无法实现业务代码的动态下发更新。

所以，为了解决以上问题，进一步提升应用性能，和应对未来更多业务场景需求的可能性，我们实现了多线程架构。

相较于单线程架构，多线程架构将整个业务代码执行和渲染的过程拆分到了三个线程，每个线程各司其职，让任务的执行更加合理，不会造成主线程的堵塞，这样的架构主要带来三个好处。

1.业务逻辑不再堵塞主流程，完全剥离到了单独的线程执行，之前容易出现卡顿、甚至 APP Freeze 的页面基本不再有问题，例如商详接入之后滑动页面变得更加流畅；

2.动画执行和渲染不再卡顿，动画的执行交由 Background 线程管控，不再和 JS 线程有冲突问题，动画支持满帧渲染；

3.支持动态化的能力，在性能上可以与原生相媲美，同时还能支持动态下发，支持更新远端 JS 资源来实现 APP 内容的更新，让业务具备快速验证和免发版的能力。

目前多线程版本正在我们的业务中进行试点接入，很快就会正式上线。

Taro on Harmony 方案特性​

丰富的能力支持​

常用组件和 API 支持​

在 C-API 版本的 Taro For Harmony 中，我们不仅完整支持了 React 18+，另外支持了 View、Text、Image、Video 等近 33 个 Taro 组件，对于常用的 API，如 getSystemInfo、getStorage 等也是在 C-API 版本中得到了完整的支持，而且针对逻辑较为复杂的 API 如：createSelectorQuery 以及 createIntersectionObserver，我们将这些 API 在 C++ 侧进行了重新的实现，大幅提升了他们的执行性能。

常用样式支持​

在 C-API 版本中，我们对支持了大部分常见的 CSS 能力：

• 支持常见的 CSS 样式和布局，支持 flex、伪类和伪元素
• 支持常见的 CSS 定位，绝对定位、fixed 定位
• 支持常见的 CSS 选择器和媒体查询
• 支持常见的 CSS 单位，比如 vh、vw 以及计算属性 calc
• 支持 CSS 变量以及安全区域等预定义变量

同时，我们参考浏览器 CSSOM 的实现方式，在 C++ 实现了一套 CSSOM 逻辑，里面包含了样式解析、样式匹配、样式合成和应用整个链路的样式处理逻辑。

另外，Taro 引入了 Yoga 布局引擎来计算渲染节点的位置和大小，最大程度保证 Taro 构建出来的鸿蒙应用中渲染样式和 W3C 规范的一致性。

媲美原生 ArkTS 的高性能​

运行时逻辑下沉至 C++​

在 C-API 的版本中，我们将 ArkVM 层的 Taro 运行时内容削减到极致的薄，将 TaroElement 的大部分内容都下沉到了 C++ 侧，并在 ArkVM 层取消了他们之间父子关系的绑定，极大地提升了 TaroElement 相关逻辑的性能。

另一方面，在 C++ 侧 Taro 会指令式地调用 ArkUI 在 C++ 侧提供的 API，来高效地创建节点、设置属性、绑定事件以及绘制上屏。

提供长列表组件应对长列表场景​

Taro 还针对长列表场景针对性地提供了长列表类型组件，并对长列表类型组件进行了优化，提供了懒加载、预加载和节点复用等功能，有效地解决大数据量下的性能问题，提高应用的流畅度和用户体验。

支持 C API 混合原生的渲染模式​

Taro 的组件和 API 是以小程序作为基准来进行设计的，因此在实际的鸿蒙应用开发过程中，会出现部分所需的组件和 API 在 Taro 中不存在的情况，因为针对这种情况，在 C-API 版本中，Taro 提供了原生混合开发的能力，支持将原生页面或者原生组件混合编译到 Taro 鸿蒙项目中，支持 Taro 组件和鸿蒙原生组件在页面上的混合使用。

总结​

Taro 鸿蒙方案基于鸿蒙 CAPI 进行构建，实现了将 React DSL 直接对接到 C++ 侧来运行整体渲染管线，从而实现了与原生齐平的渲染性能，同时 Taro 鸿蒙方案是多线程架构的方案，在应用渲染性能、操作响应时延上都在业界做到极致，并且 Taro 鸿蒙方案支持动态更新，是行业首创且经过大规模 APP 应用场景验证的开发框架，综合性能、生态以及开发体验来讲，毫无疑问已经成为了开发鸿蒙应用的最佳框架选型之一。

目前，我们也仍然在不断完善着鸿蒙的适配方案，目前在渲染性能提升方面我们正在进行 React C++ 化的探索，整体进展也已经处于验证和测试阶段，同时也在进行自研布局引擎的探索，在进一步提升渲染性能的同时，为业务提供更丰富的样式写法支持；此外，在开发效率提升方面，我们也正在进行开发调试工具的探索开发，为业务提供热重载、源码定位、断点调试、元素审查等能力，提升效率和开发体验。

在近期，我们会将已经在京东鸿蒙 APP 久经考验的单线程架构版本开源出来，为开源社区贡献一份力量，为鸿蒙应用生态的丰富注入强大的动力。

问题背景​

长列表类型组件（例如 WaterFlow, List）在应用开发中被广泛使用，特别适合商品列表、订单列表、消息列表等需要无限滚动的场景。这些组件通常包含大量结构相似的子组件，它们的样式和布局相似，但数据内容各异，且数据通常来自网络。

在典型的 Taro React 应用中 ，正常的列表处理流程如下：

1. 生成或从远端服务器加载数据。
2. 框架基于最新数据生成新的虚拟 DOM 树。
3. 框架使用 diff 算法或其他机制，根据虚拟 DOM 树的变化，触发对应的更新指令。
4. 运行时捕获框架的更新请求，并实际更新视图。

然而，如果加载的数据量非常大，可能会引发严重的性能问题，导致视图在一段时间内无法响应用户操作。为了解决这个问题，我们为 Taro 长列表类型组件提供了懒加载、预加载和组件复用等功能，专门针对长列表类型组件进行了优化，有效地解决大数据量下的性能问题，提高应用的流畅度和用户体验。

Taro 虚拟列表​

目前 Taro 在其他端侧已支持虚拟列表，并在实践中证明虚拟列表可以极大程度提升列表渲染性能。出于性能考虑，Taro 通过 CAPI 对接鸿蒙 ArkUI，将更多的运行时逻辑如组件、动效、测算和布局等逻辑下沉到了 C++ 层。虚拟列表也需要在 C++层重新设计实现，在只渲染当前可视区域视图的基础上，我们还加入了组件预加载，数据预请求和组件复用等高阶功能，有效地解决大数据量下的性能问题，提高应用的流畅度和用户体验，并大幅度降低了应用内存占用。以下是 Taro 虚拟列表渲染流程：

优化方案​

NodeAdapter 介绍​

当前 ArkTS 滚动类容器使用 LazyForEach 时，框架会根据滚动容器可视区域按需创建组件，但是鸿蒙 CAPI 接口不支持 LazyForEach 功能。作为 ArkTS 侧 LazyForEach 的替代方案，开发者可以使用 NodeAdapter 对象在 C++ 侧实现类似的效果。NodeAdapter 已支持 List、Grid、Swiper 和 WaterFlow 四种主要的长列表组件。

本文将以 WaterFlow 组件为例，详细介绍如何利用 NodeAdapter 对象和 CAPI 提供的能力来实现长列表组件的懒加载、预加载和组件复用。

NodeAdapter 通过特定的事件机制时需要进行相关的处理。以下是 NodeAdapter 的典型工作流程：

通过这种方式，开发者可以更好地控制长列表组件的行为，从而显著提升其性能。

NodeAdapter 的创建和挂载如下：

• 创建 NodeAdapter 对象并挂载回调处理函数

class RenderNode : public std::enable_shared_from_this<RenderNode> {
    public:
    RenderNode(std::string str) : str_(str), node_(nullptr), child_(nullptr), reuseId_("") {}
    std::string str_;
    std::shared_ptr<ArkUIBaseNode> node_;
    std::string reuseId_;
    std::shared_ptr<ArkUIBaseNode> child_;
};

ArkUIWaterFlowAdapter() : handle_(OH_ArkUI_NodeAdapter_Create()) {
// 初始化懒加载数据。
    for (int32_t i = 0; i < 50; i++) {
        auto renderNode = std::make_shared<RenderNode>(std::to_string(i));
        renderNode->reuseId_ = "reuse";
        data_.emplace_back(renderNode);
    }
    // 设置懒加载数据。
    OH_ArkUI_NodeAdapter_SetTotalNodeCount(handle_, data_.size());
    // 设置懒加载回调事件。
    OH_ArkUI_NodeAdapter_RegisterEventReceiver(handle_, this, OnStaticAdapterEvent);
}

• 将 NodeAdapter 绑定到对应的容器组件上

// 引入懒加载模块。
void SetLazyAdapter(const std::shared_ptr<ArkUIWaterFlowAdapter> &adapter) {
    assert(handle_);
    ArkUI_AttributeItem item{nullptr, 0, nullptr, adapter->GetHandle()};
    nativeModule_->setAttribute(handle_, NODE_WATER_FLOW_NODE_ADAPTER, &item);
}

• 回调处理函数定义

void OnAdapterEvent(ArkUI_NodeAdapterEvent *event) {
    auto type = OH_ArkUI_NodeAdapterEvent_GetType(event);
    auto index = OH_ArkUI_NodeAdapterEvent_GetItemIndex(event);
    switch (type) {
    case NODE_ADAPTER_EVENT_ON_GET_NODE_ID:
        OnNewItemIdCreated(event);
        break;
    case NODE_ADAPTER_EVENT_ON_ADD_NODE_TO_ADAPTER:
        OnNewItemAttached(event);
        break;
    case NODE_ADAPTER_EVENT_ON_REMOVE_NODE_FROM_ADAPTER:
        OnItemDetached(event);
        break;
    default:
        break;
    }
}

懒加载​

懒加载特性会根据容器组件能够容纳显示的组件数量按需加载数据，创建对应的 Item 组件，并挂载在容器组件树根组件上。整体渲染流程如下图所示(备注:图片来自 HarmonyOS NEXT 官网)：

懒加载创建组件示例代码：

• 创建组件唯一 ID：

// 分配ID给需要显示的Item，用于ReloadAllItems场景的元素diff。
void OnNewItemIdCreated(ArkUI_NodeAdapterEvent *event) {
    auto index = OH_ArkUI_NodeAdapterEvent_GetItemIndex(event);
    static std::hash<std::string> hashId = std::hash<std::string>();
    auto id = hashId(std::to_string(reinterpret_cast<std::uintptr_t>(data_[index].get())));
    OH_ArkUI_NodeAdapterEvent_SetNodeId(event, id);
}

• 处理组件上屏事件：

// 需要新的Item显示在可见区域。
void OnNewItemAttached(ArkUI_NodeAdapterEvent *event) {
    uint32_t index = OH_ArkUI_NodeAdapterEvent_GetItemIndex(event);
    if (index >= data_.size()) {
        return;
    }
    auto newNode = data_[index];
    // RecycleManager(newNode);
    // 创建新的组件元素。
    auto flowItem = std::make_shared<ArkUIFlowItemNode>(0);
    auto textNode = std::make_shared<ArkUITextNode>(0);
    textNode->SetTextContent(newNode->str_);
    textNode->SetFontSize(16);
    textNode->SetPercentWidth(0.5);
    textNode->SetHeight(100);
    textNode->SetTextAlign(ARKUI_TEXT_ALIGNMENT_CENTER);
    uint32_t color = 0xFFFF0000;
    textNode->SetBackgroundColor(color);
    flowItem->AddChild(textNode);
    newNode->node_ = flowItem;
    newNode->child_ = textNode;
    if (!newNode->node_) {
        return;
    }
    items_.insert_or_assign(newNode->node_->GetHandle(), newNode);
    // 设置需要展示的组件元素。
    OH_ArkUI_NodeAdapterEvent_SetItem(event, newNode->node_->GetHandle());
}

预加载​

尽管按需加载列表项可以提升长列表的性能，但在用户快速滑动，特别是数据中包含大量图片和视频的情况下，可能会出现渲染不及时导致的白块现象，影响用户体验。

为了解决该问题，NodeAdapter 支持设置 cachedCount 属性来指定缓存数量，当设置 cachedCount 后，除了容器类组件内显示的 Item 外，还将预先创建 cachedCount 条数据作为缓存。这样可以有效避免白块现象，确保用户在滑动过程中有流畅的视觉体验。

一般而言，缓存的 cachedCount 为一屏显示数据的一半的时候，效果较好。

整体渲染流程如下图所示(备注:图片来自 HarmonyOS NEXT 官网)：

• cachedCount 的使用方法如下所示：

void setCachedCount(int32_tcount) {
    ArkUI_NumberValue value[1] = {{.i32 = count}};
    item = {value, 1};
    nativeModule_->setAttribute(handle_, NODE_WATER_FLOW_CACHED_COUNT, &item);
}

数据预请求​

尽管长列表组件支持无限滚动，但在实际业务场景中，上层业务通常会采用分页方式来加载数据。以京东 App 首页为例，一屏可以显示 6 个商品，一次网络请求加载 20 条数据。如果在滑动到底部时才发起请求加载新数据，可能会出现明显的加载停顿，尤其是在网络时延较高的情况下，这种停顿会更加突出。

为了解决该问题，我们可以调整请求新数据的时机。具体来说，当还未上屏的数据数量低于某个阈值时，就提前发起请求来加载新数据。这样可以预先准备好下一批数据，避免在滑动过程出现加载停顿。

数据预请求示例代码：

• 注册 NODE_WATER_FLOW_ON_SCROLL_INDEX 事件，获取当前容器显示的起始位置/终止索引

void RegisterOnScrollIndex() {
    nativeModule_->registerNodeEvent(handle_, NODE_WATER_FLOW_ON_SCROLL_INDEX, 0, nullptr);
}

• 请求加载新数据

auto callback = [](ArkUI_NodeEvent*event) {
    auto handle = OH_ArkUI_NodeEvent_GetNodeHandle(event);
    auto eventType = OH_ArkUI_NodeEvent_GetEventType(event);
    auto target = OH_ArkUI_NodeEvent_GetTargetId(event);
    auto componentEvent = OH_ArkUI_NodeEvent_GetNodeComponentEvent(event);
    if (eventType == NODE_WATER_FLOW_ON_SCROLL_INDEX) {
        int start = componentEvent->data[0].i32;
        int end = componentEvent->data[1].i32;
        if (end + 10 >= waterFlow->adapter_->GetDataSize()) {
            int size = waterFlow->UpdateSectionSize(20);
            for (int i = 0; i < 20; i++) {
                waterFlow->adapter_->InsertItem(size + i, std::to_string(size+i));
            }
        }
    }
};

下面是使用懒加载、预加载和数据预请求的前后对比（左边为使用后，右边为使用前）：

组件复用​

对于离开可视区域的组件，NodeAdapter 不会主动释放它们，而是通过 NODE_ADAPTER_EVENT_ON_REMOVE_NODE_FROM_ADAPTER 回调通知开发者。这样可以让开发者根据实际情况决定是释放组件对象，还是将其放入复用缓存池以便后续使用。

Taro 采用了组件复用的策略，当组件离开可视区域时，并不会立即释放其占用的资源，而是将其放入复用缓存池中。

当用户滚动到其他位置，需要渲染新的子组件时，Taro 会先检查缓存池中是否有结构相似的组件。如果找到了相似的组件，就直接从缓存池中取出该组件，并更新其属性和事件。

这种做法可以有效降低应用的内存占用，减少频繁创建和销毁组件带来的性能开销，提升应用的整体性能和用户体验。

原理如下图所示：

识别子组件相似性对于组件复用至关重要。由于上层业务开发者对 Item 的结构和子组件的相似性有着全面的了解, 为了更准确地识别可复用的子组件, Taro 框架引入了一个新的属性 reuseId，表示以当前组件为根组件的子组件树可以被复用。开发者可以根据业务场景和 Item 结构特点，灵活地标记出具有相似性的子组件。

当列表中存在多个具有相同 reuseId 的子组件树时, 框架会自动识别并复用这些子组件, 而不是重新创建和渲染它们。

组件复用是 Taro 优化性能的重要策略，其流程如下：

1. 从缓存池中获取与当前组件 reuseId 相匹配的子组件。

2. 对获取到的组件进行类型比较(diff)：

   • 如果组件类型相同，则认为可以直接复用该组件，进入下一步；
   • 如果组件类型不同，则销毁该组件及其所有子组件，并创建对应的新组件后挂载，结束复用流程。

3. 对于类型相同的组件，进一步比较保其属性：

   • 通过 diff 算法识别出属性的差异部分；
   • 将差异部分的属性更新到复用的组件上，保证组件的属性与当前组件状态一致。

4. 更新组件的事件绑定，确保事件处理函数与当前组件的事件处理逻辑相匹配。

5. 递归地对该组件的子组件重复步骤 2 到步骤 4，实现对整个子树的深度复用。

• 组件复用示例代码：

// 管理NodeAdapter生成的元素。
std::unordered_map<ArkUI_NodeHandle, std::shared_ptr<RenderNode>> items_;
// 管理回收复用组件池，key为 reuseId
std::unordered_map<std::string, std::unordered_set<std::shared_ptr<RenderNode>>> cachedItems_;

• 组件回收逻辑：

// Item从可见区域移除。
void OnItemDetached(ArkUI_NodeAdapterEvent *event) {
    auto item = OH_ArkUI_NodeAdapterEvent_GetRemovedNode(event);
    // 放置到缓存池中进行回收复用。
    auto it = items_.find(item);
    if (it != items_.end()) {
        auto renderNode = it->second;
        if (!renderNode->reuseId_.empty()) {
            cachedItems_[renderNode->reuseId_].emplace(renderNode);
        }
    }
}

• 组件上屏逻辑：

bool isInitilaizedNode(std::shared_ptr<RenderNode>& newNode) {
    if (newNode->node_) {
        auto reuseId = newNode->reuseId_;
        auto it = cachedItems_.find(reuseId);
        if (it != cachedItems_.end()) {
            auto setIt = it->second.find(newNode);
            if (setIt != it->second.end()) {
                it->second.erase(setIt);
            }
        }
        return true;
    }
    return false;
}

void initRenderNode(std::shared_ptr<RenderNode>& newNode, std::shared_ptr<RenderNode>& reuseNode) {
    newNode->node_ = reuseNode->node_;
    newNode->child_ = reuseNode->child_;
    auto newText = std::dynamic_pointer_cast<ArkUITextNode>(newNode->child_);
    // 处理子组件，属性 diff 和更新
    if (newText && newNode->str_ != reuseNode->str_) {
        newText->SetTextContent(newNode->str_);
    }
    reuseNode->node_ = nullptr;
    reuseNode->child_ = nullptr;
}

void RecycleManager(std::shared_ptr<RenderNode>& newNode) {
    if (isInitilaizedNode(newNode)) {
        return;
    }
    auto it = cachedItems_.find(newNode->reuseId_);
    if (it != cachedItems_.end() && !it->second.empty()) {
        // 组件复用
        auto reuseIt = it->second.begin();
        auto reuseNode = *reuseIt;
        initRenderNode(newNode, reuseNode);
        it->second.erase(reuseIt);
    } else {
        // 创建新的元素。
        auto flowItem = std::make_shared<ArkUIFlowItemNode>(0);
        auto textNode = std::make_shared<ArkUITextNode>(0);
        textNode->SetTextContent(newNode->str_);
        textNode->SetFontSize(16);
        textNode->SetPercentWidth(0.5);
        textNode->SetHeight(100);
        textNode->SetTextAlign(ARKUI_TEXT_ALIGNMENT_CENTER);
        uint32_t color = 0xFFFF0000;
        textNode->SetBackgroundColor(color);
        flowItem->AddChild(textNode);
        newNode->node_ = flowItem;
        newNode->child_ = textNode;
    }
}

// 需要新的Item显示在可见区域。
void OnNewItemAttached(ArkUI_NodeAdapterEvent *event) {
    uint32_t index = OH_ArkUI_NodeAdapterEvent_GetItemIndex(event);
    if (index >= data_.size()) {
        return;
    }
    auto newNode = data_[index];
    RecycleManager(newNode);
    if (!newNode->node_) {
        return;
    }
    items_.insert_or_assign(newNode->node_->GetHandle(), newNode);
    // 设置需要展示的元素。
    OH_ArkUI_NodeAdapterEvent_SetItem(event, newNode->node_->GetHandle());
}

总结​

本文重点阐述了一种针对长列表类型组件的优化方案，利用 CAPI 提供的能力，结合组件复用方案，有效地提升了页面性能。文中还附带了 CAPI 实现 demo 以供参考。目前这一方案已经在京东 App 的多个核心页面得到应用，包括首页、搜索结果页和购物车等，实践表明页面的加载和更新速度平均提升了 38%，组件复用降低京东 App 首页 54% 的内存占用。该方案在实际项目中的成功应用，为 CAPI 实现长列表组件，及长列表组件性能优化提供了有益的参考和借鉴。

下期预告​

基于 Taro 打造的京东鸿蒙 APP 已跟随鸿蒙 Next 系统公测，本系列文章将深入解析 Taro 如何实现使用 React 开发高性能鸿蒙应用的技术内幕

背景​

2024 年初，京东正式启动了鸿蒙 APP 的开发工作。由于电商 APP 大量依赖图片来展示商品信息，对图片库的性能和加载体验要求极高，因此图片库被作为核心基础能力提前纳入京东鸿蒙首期基础建设计划。本文将详细介绍京东自研鸿蒙图片库的开发过程及其技术原理。

技术实现​

前期调研​

经过前期的调研，我们发现HarmonyOS平台的网络图片加载主要依赖以下两种实现方式：

系统 - Image 组件​

仅仅提供基础的图片组件用于图片加载，但功能、图片格式支持和扩展性都较弱，无法实现更丰富的图片库能力。存在的一些问题：

• 性能一般，尤其在同时加载多个图片时较慢
• 不支持 AVIF 图片格式并且无法扩展
• 无法搭建完善的质量监控体系
• 无法控制和扩展图片下载、解码、缓存流程，无法加入更多的性能优化手段和扩展定制

第三方库 - ImageKnife​

社区参考 Android 图片库Glide的HarmonyOS版本实现，使用ArkTS开发。虽然能力比系统Image组件完善，但在性能、稳定性和扩展性都无法满足诉求。存在的一些问题：

• 性能一般
• 代码质量一般，存在一些 bug 和 Crash
• 整体架构、扩展性设计不够，无法加入更多的性能优化手段和扩展定制

由于系统Image组件和ImageKnife开源库无法满足诉求，我们决定自主研发鸿蒙图片库。此外，随着HarmonyOS系统的引入，客户端在原有的iOS和Android基础设施上新增了一个平台，增加了维护成本。现有 iOS/Android 图片库也存在双端部分能力不一致的情况。集团内部期望未来的客户端基础设施能够支持跨端复用，以提高开发效率和一致性。

因此,团队选择基于C++为核心进行图片库开发，这种实现方式有以下优势：

• 跨端复用：将更多的公共模块下沉到C++层以实现跨端复用，未来图片库可以扩展到iOS和Android平台。
• 适配 Taro：Taro Harmony框架基于鸿蒙CAPI进行开发，需要依赖CAPI的图片组件，可以避免ArkTS和C++之间频繁通信带来的性能损耗。
• 高性能：C++在运行时性能上优于ArkTS。

JDImage 能力​

架构设计​

由于图片库使用C++进行跨端开发，面临不同平台之间的兼容性挑战，部分功能需要依赖于端侧的特定实现。为了应对这些复杂性，需要提供了一定的抽象能力，使得在支持不同平台时能够灵活调整和替换模块具体实现。在设计过程中也参考了iOS/Android业界成熟的开源库，如SDWebImage、Glide和Fresco。

我们选择采用模块化和架构分层的思想来设计图片库的整体架构。模块化将图片库拆分为多个独立模块，不仅增强了系统的灵活性和可替换性，还使我们能够在不同的客户端环境和图片加载场景下进行灵活调整和扩展。架构分层将图片库划分为Core层和客户端层，Core层使用C++进行开发支持跨端复用，客户端层用于特定模块的平台差异化实现。这种设计方法有效地解决了跨端开发的复杂性问题，提高了系统的可维护性和稳定性。

核心模块介绍​

图片库主要分为图片缓存、解码器、图片源拉取、性能监控、图片组件这几个核心功能模块，模块之间不直接依赖可以被单独调用执行。

图片缓存​

• 内存缓存：用于保存已解码后的位图对象，避免每次图片加载都要进行图片解码，从而提高加载性能。我们采用LRU算法实现来高效利用内存，同时提供了最大内存缓存大小和设备内存紧张时回收一部分图片缓存的策略，以动态调整内存消耗。
• 磁盘缓存：用于保存下载后的网络图片在 APP 沙盒中，降低网络消耗并提高加载性能。提供了基础的图片读取、保存、删除、缓存大小读取等能力，同时支持多线程并行执行，实现图片磁盘缓存的高性能读写能力。

图片数据源拉取​

图片数据源拉取模块负责图片数据源读取能力。我们在HarmonyOS平台上提供了多个数据源实现，处理不同格式的图片数据源拉取任务：

• HTTP：提供HTTP链接的网络图片下载能力。底层使用Cornet进行实现，实现高性能的多请求并行网络下载能力，同时方便未来实现跨端复用。
• Base64：提供Base64格式的图片格式读取能力。

解码器​

图片解码器模块负责将编码后的图片格式解码为操作系统的图片格式用于显示。我们在HarmonyOS平台上提供了多个解码器实现处理不同格式的图片解码任务，可以支持多线程并行执行提高解码性能。

• 系统解码器：利用HarmonyOS系统提供的图片解码器可以支持PNG、JPG、GIF、WebP、SVG等常用图片的高性能硬件解码能力。
• AVIF 解码器：由于京东 APP 大量使用AVIF图片格式，通过集成libavif库支持AVIF图片的解码能力。

性能监控​

• 加载性能监控：统计图片加载过程的各阶段耗时数据、缓存命中率、图片格式、资源消耗等信息，用来搭建图片加载性能数据平台和性能优化参考指标。
• 异常监控：捕获图片加载过程中的各种错误异常，用来搭建图片加载线上异常告警和根据场景进行异常重试。

图片组件​

图片组件基于系统Image组件进行封装，通过src属性传入解码后的PixelMap进行渲染。同时提供了一些额外的加载属性用于提升加载性能，例如添加lazy属性支持图片懒加载、sourceSize属性指定图片显示尺寸、 priority属性设置加载优先级。

性能优化​

图片加载流水线​

图片加载流水线借鉴了Fresco的流水线设计。采用流水线方式可以灵活调整流水线的执行流程，可以通过搭配不同的流水线子任务以满足不同类型的图片加载任务和不同客户端的差异化诉求。同时也添加了很多优化策略提升优化图片加载流水线的执行性能。图片加载流水线主要包含以下这些能力：

• 调度执行顺序：管理图片加载的流水线子任务执行顺序，确保各个步骤按照预期的顺序进行执行。
• 调用功能模块：灵活调用不同的功能模块，如解码、缓存、网络请求等，根据具体需求动态调整，以适应不同的图片加载任务。
• 线程调度：对流水线子任务进行执行线程调度，确保非主线程任务在子线程中并行执行，主线程任务在主线程中执行。使用HarmonyOS提供的FFRT框架进行高性能线程调度。
• 重复任务聚合：识别重复的加载任务，避免非必要的重复请求，提高加载性能。
• 加载监控：统计加载过程性能数据和错误异常。同时加载数据也可以用于回溯分析异常问题。
• 取消/重试机制：实现图片加载的取消和重试逻辑。提前取消可以降低非必要的图片加载请求，重试机制可以尽可能降低线上显示异常。

面向京东图片服务器设计​

京东图片服务器提供了多种处理功能，例如图片格式转换、图片降质、图片缩放、图片圆角、灰度图等。这些功能通过在图片URL中添加特定图片处理参数实现，图片服务器会根据参数设置提前将图片处理完成并保存到CDN服务器。

我们可以通过在流水线预处理阶段，针对京东域名图片自动追加特定的图片处理参数降低网络流量传输消耗，例如根据视图实际显示大小添加缩放参数，添加降质参数，使用.avif格式图片降低网络传输大小。同时在磁盘缓存模块实现中，我们也通过实现优化策略让部分相同的图片可以进行磁盘缓存复用避免重复下载。

质量保障​

作为一个新上线的基础组件，保证业务稳定性至关重要。为了快速发现并解决问题，图片库中实现了线上监控和异常恢复机制。

线上监控​

####### 异常监控

如前文所述，图片加载流水线涉及多个子任务，加载异常可能出现在任何一个环节。为了精准定位问题，图片库为每个子任务定制了不同的异常对象，每个异常对象包含独特的错误码，并会根据严重程度将其分为异常和警告两个级别。当加载流程结束时会根据上报策略进行异常上报。

性能监控​

除了加载成功率，加载速度也是图片库的核心指标，为了能正确还原加载流程，图片库按照配置策略记录每个子任务开始和结束时间，一方面用于统计各阶段的加载耗时，另一方面还作为异常定位时的重要辅助信息。

异常恢复​

除了从监控发现问题，为了将异常影响降至最低，图片库也实现了流水线失败重试、组件异常降级及线上配置降级三种异常恢复机制。

流水线失败重试​

在图片库任务预处理阶段，会基于配置策略对图片链接进行处理，如统一图片域名，图片格式转换等等。由于图片链接拼接规则复杂，无法保证所有链接进行转化处理后仍能正常加载，因此图片库流水线中增加了重试机制，会根据错误类型使用不同的重试策略。

组件异常降级​

对于经过重试仍然失败的任务，图片库组件侧会尝试直接使用系统Image组件进行兜底渲染，以防止出现图片库特定格式兼容性的问题。
此外，因为图片库流水线加载完成不意味着图片一定能正常渲染，图片的最终渲染成功与否取决于最终图片是否能在图片组件完成渲染上屏。因此，针对流水线成功但组件渲染失败的情况，图片库也会尝试降级到系统Image组件加载原始链接。
如果降级后仍然失败，则会按照业务配置顺序加载异常兜底图。

线上配置降级​

由于线上环境复杂，可能会出现仅发生在特定用户、系统版本、APP 版本的异常，图片库也基于移动配置 SDK 支持了针对特定用户、机型、版本强制降级的能力。

加载对比​

未来规划​

我们也梳理了未来可能尝试的一些图片库优化方向：

• 网络优化：弱网优化、HTTPDNS 等策略优化图片网络下载性能。
• 性能优化：提高磁盘缓存/内存缓存复用率、使用堆内存池减少堆内存分配、优化 GIF 播放、低端机优化等。
• 适配京东图片服务器能力：利用服务器图片处理能力，如使用不同的缩放尺寸参数、清晰度、图片格式、图片域名等参数提高加载性能。
• 能力完善：提供更多图片加载参数、支持更多图片类型等能力满足不同业务的加载诉求。
• 更多平台支持：扩展到iOS、Android等更多平台。
• 提升图片效果：使用不同的插值方式、超分技术、HDR 等能力提高图片显示效果。

总结​

京东自研的鸿蒙图片库通过模块化设计和流水线调度策略，成功解决了跨端开发的复杂性问题，同时提高了系统的可维护性和稳定性。通过实现多重异常容错机制，保证了业务的稳定性。该图片库不仅满足了京东 APP 在鸿蒙系统上的高性能图片加载需求，还为未来的跨平台开发奠定了基础。

目前，图片库已通过Taro集成到京东鸿蒙 APP 中上线使用，在图片加载体验和稳定性上有不错的表现。未来，我们将继续优化图片库的性能，扩展功能，并探索在更多平台上的应用可能。同时，我们也会持续关注业界最新的图片处理技术，不断改进我们的解决方案，为用户提供更好的图片加载体验。

系列往期精选​

• 京东鸿蒙上线前瞻——使用 Taro 打造高性能原生应用
• Taro 鸿蒙技术内幕系列（一）：如何将 React 代码跑在 ArkUI 上
• Taro 鸿蒙技术内幕系列（二）：如何让 W3C 标准的 CSS 跑在鸿蒙上
• Taro 鸿蒙技术内幕系列（三） - 多语言场景下的通用事件系统设计

下期预告​

基于 Taro 打造的京东鸿蒙 APP 已跟随鸿蒙 Next 系统公测，本系列文章将深入解析 Taro 如何实现使用 React 开发高性能鸿蒙应用的技术内幕

背景​

在鸿蒙生态系统中，虽然原生应用通常基于 ArkTS 实现，但在实际研发过程中发现，使用 C++ 可以显著提升应用框架和业务的性能表现。随着鸿蒙系统的不断迭代升级，不同语言环境间的协作已成为不可或缺的开发范式，共同构建了更丰富的研发生态。

Taro 通过接入鸿蒙端的 C-API 相关能力，将组件、样式布局等运行时逻辑下沉到 C++ 层，从而极大地提升了页面的渲染性能。

在这样的背景下，构建一套在 C++、ArkTS 等不同语言环境之间高效通信的事件系统，成为了一个极具价值，对于 Taro 来说也是必修的课题。

多语言环境的事件处理机制​

在 Harmony 端的适配过程中，事件系统扮演着双重角色：不仅驱动应用、页面和各模块组件的生命周期，还因为 ArkTS 和业务代码（JS）之间存在人为设定的界限，需要事件作为桥梁，以便 JS 能够调用 ArkTS 的原生能力。

跨语言环境事件驱动架构的设计考量​

在设计跨语言环境的事件驱动架构时，需要同时考虑 ArkTS、JS 和 C++ 等多个语言环境的限制和运行时差异。如何实现事件在这些环境之间的有序传递，以驱动页面和组件的生命周期，是事件系统设计的重要考量。

通过 C++ 实现事件的底层逻辑，构建一个高效的事件管理系统，可以有效避免冗余接口的设计。同时，与鸿蒙的 C-API 支持的事件系统对接，将各类事件分发到不同语言环境，确保跨语言环境的事件分发与处理的有序性、高效性。

回顾 Taro 开始适配鸿蒙至今，事件系统也随之经历了从简单到完善的演进历程。从最初在 ArkTS 方案中的基础实现，到随着 Taro for Harmony 方案迭代发展，事件系统的设计也面临 ArkTS 带来的一些限制。

在 ArkTS 语言环境中事件架构的局限性​

基于 ArkTS 语言环境实现的事件架构，在性能方面存在较大局限性。特别是在事件冒泡过程中，性能较差的语法，和回调逻辑可能会导致性能严重劣化，甚至阻塞主线程。这不仅会影响应用的响应速度，更有甚者可能对整体用户体验产生负面影响。

为了解决这些问题，提升性能以保证用户体验成为关键目标。通过将事件处理逻辑下沉到 C++ 层，并置于后台线程执行等优化手段。能够有效提高代码执行效率，同时避免逻辑阻塞主线程导致的延迟响应，以提升应用的流畅性，提供更佳的用户体验。

构建多语言环境下的事件系统​

在构建多语言环境下的事件系统时，首要考虑各种类型的事件，比如：鸿蒙提供的组件通用事件、手势等。事件系统需要有效地管理这些不同的事件来源，并根据框架和用户的监听行为有序进行事件的分发。

在这些事件类型中，大致可以分为普通事件和节点事件两类。前者涵盖系统层面和应用、组件等生命周期的变化，通常由系统或应用状态的改变触发，主要由事件中心（eventCenter）来处理；节点事件则与 DOM Tree 紧密相关，这些事件通常需要快速响应，以确保用户界面的流畅性和交互的即时性。

事件中心（eventCenter）的实现​

作为 Taro 运行时中的基础模块，事件中心专注于处理系统事件和生命周期。它允许框架和应用开发者在后台线程注册事件队列，并异步分发事件，从而有效减轻主线程的负担。事件中心能够快速响应各种事件，同时具备健壮的错误处理机制，帮助开发者快速定位和解决事件回调中的问题，从而提升开发效率和系统稳定性。

事件监听与分发​

开发者可以在 C++ 和 ArkTS 等多种语言环境中创建事件监听器，并将相应的回调函数添加到事件队列中。这一机制允许开发者在不同的编程语言中灵活地定义和处理事件响应逻辑。

当事件触发时，会根据不同语言环境的运行时差异，将事件参数转换为对应的格式。这种参数转换确保了各语言环境能够正确理解并处理事件及包含的数据，无论是简单的数据类型还是复杂的对象结构，都能在不同语言之间无缝传递。

事件队列会根据监听器的类型，按照预定义的顺序，将事件分发到相应的语言环境中。这样一来，每个监听器都能在其所属的环境中高效地执行对应的回调函数。通过这种方式，不仅可以实现了跨语言的事件处理，优化事件的分发效率，并确保应用在响应用户交互时保持高性能和高稳定性。

需要注意的是，受限于底层限制，在 ArkTS 环境中注册的事件需要回到主线程执行，同时在鸿蒙端不支持 Symbol 类型的事件。

节点事件处理（domEvent）​

在 HTML 中，节点事件处理流程会如下图所示，事件从根节点开始向下传播至目标节点，触发后再从目标节点顺着节点树向上冒泡。在鸿蒙端实现中，Taro 基于这一事件传播流程，为开发者提供一致的事件处理机制。

事件类型​

在 Taro 框架中，节点主要处理三种类型的事件：鸿蒙事件、鸿蒙手势事件和自定义事件。这些事件都是从  TaroElement  上进行监听和触发的。根据事件的类型不同，节点会从相应的事件源设置  Receiver （事件接收器）来进行监听并处理回调逻辑。

鸿蒙事件和鸿蒙手势事件分别通过  RenderNode  注册到  Receiver，确保事件能够正确地传递和触发。而自定义事件则根据节点实现或用户自行触发，以满足各种不同类型的交互响应。

事件传播​

当  TaroElement  上的事件被触发后，事件会沿着节点树向上传播。每个节点依次接收到事件，并执行相应的回调。执行完回调后，会检查开发者是否阻止冒泡，以决定是否继续向上传播。事件从目标节点开始，逐级往上直到根节点或者冒泡被阻止。

这允许开发者在事件传播过程中，通过任意节点处理或拦截事件来调整业务逻辑实现，以更灵活的方式在特定节点上执行逻辑，或通过阻止冒泡避免对上层节点的影响。这样的设计对于前端开发者来说，更加熟悉、直观。

鸿蒙系统的底层节点事件也有自己的传播逻辑，但由于其机制与 ArkNode 节点树差异，为避免其事件干扰，需要阻止其冒泡行为并接管其传播流程，以确保事件传播与节点树正确关联。

事件回调​

由于节点事件也需要回调 JS 环境中执行，根据事件类型的不同，按照 Web 标准将相应的节点、值和方法如 target、stopPropagation、value 等等挂载到事件对象上。通过执行当前回调的序列化方法，确保事件在不同语言环境传递时，可以保证其回调对象能力一致、参数完整。

在 C++ 中，许多组件依赖于事件机制来实现功能。例如，通过鸿蒙事件更新组件属性，还有各个组件节点间的事件传递等。这些组件利用事件机制来确保数据变化能够及时反映，并且用户交互能够顺利传递到系统的各个部分。

总结与展望​

在多语言环境中，确保事件在不同语言环境传递时的一致性尤为重要，各个模块以及应用内不同页面或组件通过事件解耦驱动来提升可维护性。当前的解决方案有效提升了系统的响应速度和模块间的协作能力。

当下方案实现中仍然存在一些问题，比如早期通过事件绕过 ArkTS 与 JS 之间相互调用限制等场景，可以通过 TurboModule 来提供更加直接的调用方案。

未来，在 Taro for Harmony 场景下，各语言模块的协同将进一步增强。基于事件系统的设计，可以有效地解耦模块间逻辑，实现更灵活的组合。

拓展阅读​

• 京东鸿蒙上线前瞻——使用 Taro 打造高性能原生应用
• Taro 鸿蒙技术内幕系列（一）：如何将 React 代码跑在 ArkUI 上
• Taro 鸿蒙技术内幕系列（二）：如何让 W3C 标准的 CSS 跑在鸿蒙上

下期预告​

基于 Taro 打造的京东鸿蒙 APP 已跟随鸿蒙 Next 系统公测，本系列文章将深入解析 Taro 如何实现使用 React 开发高性能鸿蒙应用的技术内幕

背景​

HarmonyOS 采用自研的 ArkUI 框架作为原生 UI 开发方案，这套方案有完善的布局系统和样式控制，但是他的标准与 W3C 的 CSS 标准存在不一致性。这意味着，如果 Taro 直接使用 HarmonyOS 提供的样式系统，开发者在使用 Taro 开发时会遇到非常多的样式兼容性问题，写出来的代码也会失去跨平台兼容的能力，与 Taro 多端统一开发的定位不符。如何抹平 ArkUI 标准和 W3C 的 CSS 标准之间的差异成了一个重中之重的任务。

本文将介绍 Taro 处理 CSS 的全流程，剖析将不同的 CSS 样式转换为 ArkUI 样式遇到的问题和对应的解决方案。

CSS 样式和 ArkUI CAPI 样式的差异和抹平​

1、样式书写方式不一致​

以几个我们日常会使用到的属性为例，下面的分别是 CSS 的写法和 ArkUI CAPI 的写法。

对比可以看出，CSS 样式和鸿蒙样式在单位系统和数据表示方式上存在显著差异。CSS 提供多样化的尺寸和颜色单位，而 ArkUI 的 CAPI 接口采用更统一的表示方式。

ArkUI 的 CAPI 接口将所有尺寸统一为 vp 单位，颜色采用 0xAARRGGBB 格式的 uint32 类型，对于渐变和 transform 等复杂样式属性，更是需要转换为颜色停止点和角度值列表和矩阵运算，这样的接口简洁但需要调用者根据具体场景完成必要的单位转换。

一个页面通常会包含非常多的样式规则，如果所有的单位转换都放在运行时候完成，必定会造成明显的性能问题。因此，我们选择提前完成部分转换。HTML 节点的样式主要来源于 CSS 和 Style 属性。CSS 样式通常是静态的，可以在编译阶段进行转换。为此，我们基于 lightningCSS 开发了一个 Rust 插件。该插件通过遍历项目 CSS 的抽象语法树（AST），将其转换为 ArkUI 的 CAPI 接口可直接使用的数据结构。

而对于 Style 属性，其内容在运行时才能确定，因此必须在运行时进行转换。在 React 的语法中，Style 可能以字符串形式呈现，也可能是 CSS 属性名和属性值的键值对。为了有效解析 Style，我们针对各种类型的 CSS 语法写了一系列小型的 CSS 语法解析逻辑。这些逻辑能够从各种不同格式的字符串中准确匹配出属性值并进行转换。

虽然这种方法需要在运行时进行语法分析，但考虑到 Style 属性通常只包含有限的样式，加上 C++语言的高效执行特性，这种实时转换对性能的影响可以忽略不计。更为重要的是，这些运行时的 CSS 语法解析逻辑可以为后面 Taro 支持 CSS 变量提供能力支持。

2、布局存在差异​

除了书写方式的差异，ArkUI 有很多布局属性的行为在细节上也和 W3C 的布局属性存在着不小的差异，比如鸿蒙的绝对定位相对父级定位，Web 的绝对定位相对最近的已定位祖先元素定位，并且鸿蒙的定位不支持 right 和 bottom（早期）。

web 可以通过 margin 的 auto 实现居中，鸿蒙能通过 flex 实现居中。

同时， ArkUI 的 CAPI 接口缺少一些 Web 常用功能，如 calc() 计算和百分比设置支持。为消除这些差异，我们选择采用 Yoga 作为布局引擎，而非使用鸿蒙原生提供的布局。Yoga 是 Facebook 开发的开源跨平台布局引擎，实现了基于 Web 标准的 FlexBox 布局算法。使用 Yoga 可以很容易地实现对大部分 CSS 布局属性的支持，让两端的差异缩小 。

在具体实现中，我们需要在构建 Taro 节点树的同时，构建结构一致的 Yoga 节点树。

然后把原本直接设置到鸿蒙节点上的样式属性（如宽高、margin、padding、display 和 position）设置到 Yoga 节点上。经 Yoga 计算后，我们再从 Yoga 节点上读取计算后的 width、height、x 和 y 值设置到鸿蒙节点上，从而实现鸿蒙端和 web 端的布局一致性。

通过使用 Yoga 作为布局引擎，我们不仅解决了鸿蒙系统与 Web 布局之间的差异，还提高了跨平台一致性。这种方法使开发者可以使用熟悉的 Web 布局概念，同时确保在鸿蒙平台上获得预期的布局效果。

样式的工作流程​

介绍完 Taro 适配 ArkUI 的 CAPI 样式过程中遇到的问题和对应的解决策略之后，我们就可以来看看基于这些策略，鸿蒙样式的整个工作流程是怎么样的。

样式初始化​

首先，项目启动后，编译器处理后的样式文件将第一个被加载到运行时环境。样式处理逻辑会根据各个选择器（selector）生成相应的样式规则（StyleRule），即 CSS 属性的键值对集合。

根据 ClassName 匹配 StyleRule​

React 在构建每个节点的同时，会通过 Reconciler 把 React 节点的 ClassName 和 Style 设置到相应的 Taro 节点上，这个时候我们就开始进入节点的样式匹配环节。样式处理会执行以下步骤：首先，从 CSSStylesheet 这个样式集合里识别出与 className 相关的所有 StyleRule；然后，根据选择器的优先级合并这些 StyleRule；最后，将合并结果与由 Style 生成的 StyleRule 合并，从而得出最终的样式配置。

这里顺带提一下，CSS 除了可以书写样式之外，还可以书写伪元素和关键帧动画，这两者在都没办法直接设置到鸿蒙的样式里，在处理某个节点时，如果匹配到这个节点的样式里包含伪元素，就会把这个伪元素转换成 一次 insertBefore api 的调用，用这个新 insert 进去的子元素来承载伪元素的 StyleRule，举一个例子，下面的 F 节点的 CSS 样式里带有一个 ::after 的伪类，那么当 F 节点匹配到这个样式的时候，就会被插入一个子节点用来承载 ::after 对应的样式。

而对于匹配到关键帧的动画，会把动画对应的元素，动画播放的次数、播放的方向、播放的缓动函数收集起来放到另外的线程，由这个线程算出元素每一帧对应的属性值，并在元素当前帧的 StyleRule 设置完之后，设置到节点上，保证动画的优先级一定是最高的。

样式的应用​

确定了节点对应的样式表后，我们就到了把样式应用到节点上这个环节了。这个环节我们会调用节点的 SetStyle 方法，遍历 StyleRule 中的所有样式。对于布局相关的属性（如 display、position、float、flex、width、height、margin、padding），如需更新，会被设置到节点对应的 Yoga 节点上，同时为节点本身添加 layout_dirty 标记。接着，判断是否有绘制相关的属性需要更新，如果有，则设置到节点对象的临时属性上，并为节点添加 draw_dirty 标记。这些被标记的节点并不会立刻被处理，而是会被纳入下一帧的样式处理队列中，这样能避免同一帧多次设置同一个结点的相同属性，确保样式更新的高效性，同时也能保证布局属性和绘制属性设置到鸿蒙节点时的前后时序。

在标记完所有需要更新的节点后，下一帧的样式处理流程就会对这些节点进行处理。首先，系统会调用 Yoga 的 calcYGLayout 函数，让 Yoga 从根节点开始对所有的 Yoga 节点进行测算。在此过程中，布局信息发生改变的 Yoga 节点会被打上 has_new_layout 的标记，节点上的信息也会被更新。

我们用一个例子来说明 Yoga 如何判断布局变化的影响范围：假设节点 E 的宽度改变，这可能影响到依赖父元素宽度的子元素以及由子元素撑开宽度的父元素。计算后，系统可能会更新 A、B、C、E、F、H 等节点。

测算完成后，我们遍历 Yoga 节点树，找出标记为 has_new_layout 的节点，并将其 width、height、x、y 值更新到对应的鸿蒙节点上。这样，所有节点的布局信息就更新完毕了。

布局更新完成后，我们再把前一帧中添加到样式处理队列的节点拿出来。将存储在节点临时对象中的绘制属性转移到鸿蒙节点上。在这个环节里大多数绘制属性可以直接设置，少量依赖节点布局信息的属性（如百分比形式的 background-size）也可以利用新计算出的布局信息来准确确定这些属性的值。

样式的更新​

了解了初始化状态的样式工作流程后，我们再回过头来看一下样式更新部分的逻辑，在这一块逻辑里，样式的匹配和应用与前面的流程没有任何区别，所以只是简单介绍一下一个节点的样式是怎么被更新的。

Style 更新​

Style 的更新是相对比较好处理的一部分，因为 Style 的影响范围只在节点的本身。当元素的 Style 更新时，我们只需要重新生成对应的 inline_style_，然后将其与通过 className 生成的样式进行合并应用即可。这个过程相对简单直接，因为不需要考虑对其他元素的影响。通过这种方式，我们可以确保元素的样式得到准确更新，同时保持整体样式系统的一致性和效率。

ClassName 更新​

当元素的 ClassName 更新时，我们需要执行以下步骤来确保样式正确应用：

1.识别包含新 ClassName 的所有选择器规则。

2.根据 ClassName 在规则中的位置，确定需要重新进行样式匹配的元素：

• 目标元素选择器：更新当前节点
• 直接后代选择器：更新直接子节点
• 后代选择器：更新所有子孙节点

这些规则适用于 className 的增加、删除、修改和查询操作。对于 className 的修改，我们将其视为先删除旧 className 再添加新 className，并执行两次规则匹配。

举一个例子，当样式规则和元素结构如下时：

.E .G {}
.E .H {}
.I > .J {}
.I {}

为蓝色的节点添加 className I，为红色的节点添加 className E，那么需要要被更新的节点就有 F G H I J

在实际应用中，我们还需考虑性能问题。对于大型应用或复杂的元素结构，频繁的样式重计算可能会影响性能。因此，我们采取了一种优化策略：找出需要更新的节点后，不会立即进行样式重匹配，而是将这些节点标记为"脏"并放入更新队列中。然后，我们在下一帧统一完成所有样式重匹配的工作。这种方法可以有效减少重复计算，提高整体性能。

总结​

通过本文，我们详细阐述了 Taro 在处理 CSS 样式与鸿蒙系统 ArkUI 框架之间差异的全流程。我们探讨了样式书写方式的不一致性、样式匹配和应用的复杂过程，以及样式更新时的处理策略。这些功能和特性使得 Taro 能够在保持跨平台兼容性的同时，实现 CSS 样式到鸿蒙系统的有效转换。

作为开发者，我们深知这个过程中面临的挑战，但也为最终取得的成果感到自豪。通过这种方法，我们为开发者提供了一个统一且强大的多端开发解决方案，使他们能够更加高效地开发跨平台应用。

我们相信，随着技术的不断进步，未来还会出现更多的优化空间。我们将继续致力于改进 Taro 的性能和兼容性，为开发者提供更好的开发体验。同时，我们也欢迎社区的反馈和贡献，共同推动 Taro 在多端开发领域的发展。

系列往期精选​

《京东鸿蒙上线前瞻——使用 Taro 打造高性能原生应用》

Taro 鸿蒙技术内幕系列（一）：如何将 React 代码跑在 ArkUI 上文章

《Taro 鸿蒙技术内幕系列（三） - 多语言场景下的通用事件系统设计》

基于 Taro 打造的京东鸿蒙 APP 已跟随鸿蒙 Next 系统公测，本系列文章将深入解析 Taro 如何实现使用 React 开发高性能鸿蒙应用的技术内幕

背景​

随着鸿蒙操作系统的快速发展，开发者们期待将现有跨平台应用迁移到鸿蒙平台。Taro 作为一个流行的跨平台开发框架，其支持鸿蒙系统的可能性引起了广泛关注。

然而，鸿蒙系统采用全新的 ArkUI 框架作为原生 UI 开发方案，与 Taro 原本支持的平台存在显著差异。将 Taro 的 React 开发模式与 ArkUI 的声明式 UI 开发范式进行有效对接成为了一个技术难题。

本文将探讨 Taro 框架如何通过创新方案实现 React 代码在 ArkUI 上的运行。我们将解析 Taro 的运行时原理，剖析其如何将 React 组件转换为 ArkUI 可识别的结构，以及相关技术挑战和解决方案。

Taro 运行时原理介绍​

为了理解 Taro 适配 ArkUI 的核心机制，我们首先需要深入了解 Taro 的运行时原理。Taro 通过巧妙的设计，将 React 代码转换为各平台可执行的形式，其中包括对鸿蒙平台的适配。下面将详细介绍 Taro 是如何将 React 代码转换为 ArkUI 可执行的形式，以及节点转换的流程细节。

1. 从 React 到 Taro​

React 跨平台的秘诀​

在 Taro 的运行时中，首先执行的是开发者编写的 React 业务代码。这些代码定义了业务应用的结构、逻辑和状态管理。那么既然要对接 React，那肯定先得了解它的核心架构，React 是怎么运作的：

了解了 React 的基本架构后，我们可以清晰地看到，**Renderer** 作为渲染器，负责将 React 的虚拟节点操作最终映射到相应的平台上。例如，react-dom将这些操作对接到浏览器上，而react-native则将其对接到 iOS 或 Android 平台。这种设计使得 React 能够适配不同的运行环境。

正是基于这种思路，Taro 团队设计了 Taro Renderer。这个渲染器充当了 React 与 Taro 虚拟节点树之间的桥梁，使得 React 的操作可以被转换为 Taro 的中间表示。

通过实现 Taro Renderer 生成 Taro 虚拟节点树​

HostConfig 接口实现

要实现 Taro 的 Renderer，我们需要实现 React Reconciler 所需的 hostConfig 接口。这个接口定义了一系列方法，用于创建、更新和管理渲染目标平台的元素。以下是一些关键的 hostConfig 方法：

• createElement：创建 ArkUI 对应的元素。
• createTextInstance：创建文本节点。
• appendChild：将子元素添加到父元素。
• removeChild：从父元素中移除子元素。
• insertBefore：在指定位置插入元素。
• commitUpdate：更新元素属性。

通过实现这些方法，Taro Renderer 能够将 React 的操作转换为 Taro 虚拟节点树的相应操作。这个虚拟节点树是 Taro 实现跨平台的核心，它为不同平台的渲染提供了统一的中间表示。

// 部分HostConfig接口实现的代码

const hostConfig: HostConfig {
    // 创建Taro虚拟节点
  createInstance (type, props: Props, _rootContainerInstance, _hostContext, internalInstanceHandle: Fiber) {
    const element: TaroElement = TaroNativeModule.createTaroNode(type)
    precacheFiberNode(internalInstanceHandle, element)
    updateFiberProps(element, props)
    return element
  },
  // 更新属性
    commitUpdate (dom, updatePayload, _, oldProps, newProps) {
      updatePropsByPayload(dom, oldProps, updatePayload)
      updateFiberProps(dom, newProps)
    },
    // 插入节点
    insertBefore (parent: TaroElement, child: TaroElement, refChild: TaroElement) {
      parent.insertBefore(child, refChild)
    },
    // 移除节点
    removeChild (parent: TaroElement, child TaroElement) {
      parent.removeChild(child)
    },
    // ...
}

2. 从 Taro 到 ArkUI​

在将 Taro 虚拟节点树转换为 ArkUI 的过程中，我们需要进行几个关键步骤：

Taro Element 转换 ArkUI 过程

首先，我们需要在 ArkUI 层面实现一套与 Taro 组件对应的组件库。这个步骤至关重要，因为它建立了 Taro 组件和 ArkUI 组件之间的映射关系。例如，我们需要为 Taro 的 View、Text、Image 等基础组件创建对应的 ArkUI 组件。这样，当我们遍历 Taro 虚拟节点树时，就能找到每个节点在 ArkUI 中的对应实现。

在节点映射的过程中，我们注意到 Taro 虚拟节点树与实际 ArkUI 视图结构存在差异。这些差异主要体现在以下几个方面：

• 复合组件结构：某些 Taro 组件在 ArkUI 中可能需要多个组件配合实现。例如，ScrollView 组件在 ArkUI 中可能需要一个 Scroll 节点搭配一个 Stack 来实现完整功能。
• 层级位置调整：一些特殊定位的节点（如 Fixed 定位的元素）在最终渲染时的位置可能与其在虚拟节点树中的层级不一致。这需要在生成渲染树时进行特殊处理。
• 平台特定组件：某些 Taro 组件可能需要使用 ArkUI 特有的组件或布局方式来实现，这要求我们在转换过程中进行适当的调整和映射。

因此，在生成渲染树时，我们需要一个更复杂的转换过程，不仅要考虑简单的一对一映射，还要处理这些结构性的差异，确保最终生成的 ArkUI 组件树能够正确反映预期的视图结构和布局。因此，在 Taro > ArkUI 的节点对接中，我们需要维护一棵 Render Tree，用于做中间的桥梁。

1. 根据组件类型 创建 Taro Element​

在创建 Taro Element 的过程中，我们根据组件的类型来实例化相应的 Taro 元素。这一步骤是将 React 组件转换为 Taro 内部表示的关键。

// 根据组件类型创建对应的Taro节点
std::shared_ptr<TaroElement> TaroDocument::CreateElement(napi_value &node) {
        // 获取组件类型
    TAG_NAME tag_name_ = TaroDOM::TaroElement::GetTagName(node);
    // 根据组件类型，创建对应的实例
    std::shared_ptr<TaroDOM::TaroElement> item;
    switch (tag_name_) {
        case TAG_NAME::SCROLL_VIEW: {
            item = std::make_shared<TaroDOM::TaroScrollView>(node);
            break;
        }
        case TAG_NAME::IMAGE:
            item = std::make_shared<TaroDOM::TaroImage>(node);
            break;
        }
        case TAG_NAME::SPAN:
        case TAG_NAME::TEXT: {
            item = std::make_shared<TaroDOM::TaroText>(node);
            break;
        }
        case TAG_NAME::SWIPER: {
            item = std::make_shared<TaroDOM::TaroSwiper>(node);
            break;
        }
        // ...
    }
    return item;
}

2. Taro Element 创建 Taro RenderNode​

在创建完 Taro Element 之后，下一步是将其转换为 Taro RenderNode。这个过程是将 Taro 的内部表示进一步转化为更接近 ArkUI 结构的渲染节点。

// 创建 Taro RenderNode
void TaroSwiper::Build() {
    if (!is_init_) {
        // create render node
        TaroElementRef element = std::static_pointer_cast<TaroElement>(shared_from_this());
        auto render_swiper = std::make_shared<TaroSwiperNode>(element);
        render_swiper->Build();
    }
}

3. Taro RenderNode 创建 ArkUI Node​

最后一步是将 Taro RenderNode 转换为实际的 ArkUI 节点。这个过程涉及到直接与 ArkUI 的底层 API 交互，创建和配置 ArkUI 的原生节点。实现了从 Taro 的渲染节点到 ArkUI 实际可渲染节点的最终转换。

  // 创建 ArkUI Node
void TaroSwiperNode::Build() {
    NativeNodeApi *nativeNodeApi = NativeNodeApi::getInstance();
    // 创建一个Swiper的ArkUI节点
    SetArkUINodeHandle(nativeNodeApi->createNode(ARKUI_NODE_SWIPER));
}

通过这三个步骤，我们在 C++ 层面成功实现了 React 组件结构到 ArkUI 原生组件结构的映射。这一过程使 Taro 应用能够在鸿蒙系统上准确地渲染和运行，为跨平台开发提供了有力支持。

总结​

最后总结下，本文探讨了 Taro 框架如何将 React 代码成功运行在鸿蒙系统的 ArkUI 上。这个过程主要分为两个关键部分：

React > ArkUI 架构图

1. Taro 对接 React​

Taro 通过实现自定义的 Renderer 来对接 React。这个 Renderer 包含了一系列方法，如 createInstance、commitUpdate 等，用于将 React 的操作转换为 Taro 虚拟节点树的操作。这个虚拟节点树是 Taro 实现跨平台的核心，为不同平台的渲染提供了统一的中间表示。

2. Taro 对接 ArkUI​

Taro 通过自定义 Renderer 将 React 操作转换为虚拟节点树，然后通过三步转换过程将其映射到 ArkUI 结构。这个过程涉及 Taro Element、Taro RenderNode 和 ArkUI Node 这三棵树的维护，主要通过这三个流程步骤实现：

1.创建 Taro Element：这一步将 React 组件转换为 Taro 内部表示。

2.创建 Taro RenderNode：将 Taro 的内部表示进一步转化为更接近 ArkUI 层级结构的渲染节点。

3.创建 ArkUI Node：最后一步是将 Taro RenderNode 转换为实际的 ArkUI 节点，直接与 ArkUI 的底层 API 交互。

通过这种方式，Taro 成功地将 React 组件结构映射到 ArkUI 原生组件结构，使得 Taro 应用能够在鸿蒙系统上准确地渲染和运行，同时也为跨平台开发提供了有力支持。

系列往期精选​

《京东鸿蒙上线前瞻——使用 Taro 打造高性能原生应用》

2024 年 1 月，京东正式启动鸿蒙原生应用开发，基于 HarmonyOS NEXT 的全场景、原生智能、原生安全等优势特性，为消费者打造更流畅、更智能、更安全的购物体验。同年 6 月，京东鸿蒙原生应用尝鲜版上架华为应用市场，计划 9 月完成正式版的上架。

早在 2020 年，京东与华为就签署了战略合作协议，不断加大技术投入探索 HarmonyOS 的创新特性。作为华为鸿蒙生态的首批头部合作伙伴，在适配鸿蒙操作系统的过程中，京东与华为一直保持着密切的技术沟通与共创，双方共同攻坚行业适配难点，并推动多端统一开发解决方案 Taro 在业界率先实现对鸿蒙 ArkUI 的原生开发支持。

本文将阐述京东鸿蒙原生应用在开发时所采用的技术方案、技术特点、性能表现以及未来的优化计划。通过介绍选择 Taro 作为京东鸿蒙原生应用的开发框架的原因，分析 Taro 在支持 Web 范式开发、快速迁移存量项目、渲染性能优化、高阶功能支持以及混合开发模式等方面的优势。

技术方案​

京东在开发鸿蒙原生应用的过程中，需要考虑如何在有限的时间内高效完成项目，同时兼顾应用的性能与用户体验。为了达成这一目标，选择合适的技术方案至关重要。

在技术选型方面，开发一个鸿蒙原生应用，一般会有两种选择：

• 使用原生 ArkTS 进行鸿蒙开发
• 使用跨端框架进行鸿蒙开发

使用原生 ArkTS 进行鸿蒙开发，面临着开发周期冗长、维护多端多套应用代码成本高昂的挑战。在交付时间紧、任务重的情况下，京东果断选择跨端框架来开发鸿蒙原生应用，以期在有限的时间内高效完成项目。

作为在业界具备代表性的开源跨端框架之一，Taro 是由京东凹凸实验室团队开发的一款开放式跨端跨框架解决方案，它支持开发者使用一套代码，实现在 H5、小程序以及鸿蒙等多个平台上的运行。

通过 Taro 提供的编译能力，开发者可以将整个 Taro 项目轻松地转换为一个独立的鸿蒙应用，无需额外的开发工作。

另外，Taro 也支持将项目里的部分页面以模块化的形式打包进原生的鸿蒙应用中，京东鸿蒙原生应用便是使用这种模式进行开发的。

京东鸿蒙原生应用的基础基建能力如路由、定位、权限等能力由京东零售 mpass 团队来提供，而原生页面的渲染以及与基建能力的桥接则由 Taro 来负责，业务方只需要将写好的 Taro 项目通过执行相应的命令，就可以将项目以模块的形式一键打包到鸿蒙应用中，最终在应用内渲染出对应的原生页面，整个过程简单高效。

技术特点​

Taro 作为一款开放式跨端跨框架解决方案，在支持开发者一套代码多端运行的同时，也为开发鸿蒙原生应用提供了诸多便利。在权衡多方因素后，我们最终选择了 Taro 作为开发鸿蒙原生应用的技术方案，总的来说，使用 Taro 来开发鸿蒙原生应用会有下面几点优势：

支持开发者使用 Web 范式来开发鸿蒙原生应用​

与鸿蒙原生开发相比，使用 Taro 进行开发的最大优点在于 Taro 支持开发者使用前端 Web 范式来开发鸿蒙原生应用，基于这一特点，我们对大部分 CSS 能力进行了适配：

• 支持常见的 CSS 样式和布局，支持 flex、伪类和伪元素
• 支持常见的 CSS 定位，绝对定位、fixed 定位
• 支持常见的 CSS 选择器和媒体查询
• 支持常见的 CSS 单位，比如 vh、vw 以及计算属性 calc
• 支持 CSS 变量以及安全区域等预定义变量

在编译流程上，我们采用了 Rust 编写的 LightningCSS，极大地提升了 CSS 文件的编译和解析速度。

（图片来自 LightningCSS 官网）

在运行时上，我们参考了 WebKit 浏览器内核的处理流程，对于 CSS 规则的匹配和标脏进行了架构上的升级，大幅提升了 CSS 应用和更新的性能。

支持存量 Taro 项目的快速迁移​

将现有业务适配到一个全新的端侧平台，无疑需要投入大量的人力物力。而 Taro 框架的主要优势，正是能够有效解决这种跨端场景下的项目迁移难题。通过 Taro，我们可以以极低的成本，在保证高度还原和高性能的前提下，快速地将现有的 Taro 项目迁移到鸿蒙系统上。

渲染性能比肩原生开发​

在 Taro 转换鸿蒙原生页面的技术实现上，我们摒弃了之前使用 ArkTS 原生组件递归渲染节点树的方案，将更多的运行时逻辑如组件、动效、测算和布局等逻辑下沉到了 C++ 层，极大地提升了页面的渲染性能。

另外，我们对于 Taro 项目中 CSS 样式的处理架构进行了一次整体的重构和升级，并引入布局引擎 Yoga，将页面的测量和布局放在 Taro 侧进行实现，基于这些优化，实现一套高效的渲染任务管线，使得 Taro 开发的鸿蒙页面在性能上足以和鸿蒙 ArkTS 原生页面比肩。

支持虚拟列表和节点复用等高阶功能​

长列表渲染是应用开发普遍会遇到的场景，在商品列表、订单列表、消息列表等需要无限滚动的组件和页面中广泛存在，这些场景如果不进行特殊的处理，只是单纯对数据进行渲染和更新，在数据量非常大的情况下，可能会引发严重的性能问题，导致视图在一段时间内无法响应用户操作。

在这个背景下，Taro 在鸿蒙端提供了长列表类型组件（WaterFlow & List），并对长列表类型组件进行了优化，提供了懒加载、预加载和节点复用等功能，有效地解决大数据量下的性能问题，提高应用的流畅度和用户体验。

（图片来自 HarmonyOS 官网）

支持原生混合开发等多种开发模式​

Taro 的组件和 API 是以小程序作为基准来进行设计的，因此在实际的鸿蒙应用开发过程中，会出现所需的组件和 API 在 Taro 中不存在的情况，因为针对这种情况，Taro 提供了原生混合开发的能力，支持将原生页面或者原生组件混合编译到 Taro 鸿蒙项目中，支持 Taro 组件和鸿蒙原生组件在页面上的混合使用。

性能表现​

京东鸿蒙原生应用性能数据​

经过对 Taro 的屡次优化和打磨，使得京东鸿蒙原生应用取得了优秀的性能表现，最终首页的渲染耗时 1062ms，相比于之前的 ArkTS 版本，性能提升了 23.9%；商详的渲染耗时 560 ms，相比于之前的 ArkTS 版本，性能提升 74.2%。

值得注意的是商详页性能提升显著，经过分析发现商详楼层众多，CSS 样式也复杂多样，因此在 ArkTS 版本中，在 CSS 的解析和属性应用阶段占用了过多的时间，在 CAPI 版本进行了 CSSOM 模块的架构升级后，带来了明显的性能提升。

基于 Taro 开发的页面，在华为性能工厂的专业测试下，大部分都以优异的成绩通过了性能验收，充分证明了 Taro 在鸿蒙端的高性能表现。

总结和未来展望​

Taro 目前已经成为一个全业务域的跨端开发解决方案，实现 Web 类（如小程序、Hybrid）和原生类（iOS、Android、鸿蒙）的一体化开发，在高性能的鸿蒙适配方案的加持下，业务能快速拓展到新兴的鸿蒙系统中去，可以极大满足业务集约化开发的需求。

未来计划​

后续，Taro 还会持续在性能上进行优化，以更好地适配鸿蒙系统：

• 将开发者的 JS 业务代码和应用框架层的 JS 代码与主线程的 UI 渲染逻辑分离，另起一条 JavaScript 线程，执行这些 JS 代码，避免上层业务逻辑堵塞主线程运行，防止页面出现卡顿、丢帧的现象。

• 实现视图节点拍平，将不影响布局的视图节点进行整合，减少实际绘制上屏的页面组件节点数量，提升页面的渲染性能。

（图片来自 React Native 官网）

• 实现原生性能级别的动态更新能力，支持开发者在不重新编译和发布应用的情况下，动态更新应用中的页面和功能。

总结​

京东鸿蒙原生应用是 Taro 打响在鸿蒙端侧适配的第一枪，证明了 Taro 方案适配鸿蒙原生应用的可行性。这标志着 Taro 在多端统一开发上的新突破，意味着 Taro 将为更多的企业和开发者提供优秀的跨端解决方案，使开发者能够以更高的效率开发出适配鸿蒙系统的高性能应用。

京东鸿蒙原生应用体验视频​

HarmonyOS NEXT Developer Preview 版本发布在即，越来越多的厂商加快产品鸿蒙化进程。如何把已有产品快速迁移至鸿蒙原生是大部分厂商亟待解决的问题之一。在此背景下， Taro harmony-hybrid 平台插件提供基于 Web 开发鸿蒙原生应用的迁移方案。该插件继承 H5 平台，并注入部分鸿蒙原生能力接口，扩展了 Web 应用操作设备的能力，助力厂商的产品快速鸿蒙化。

二、harmony-hybrid 平台​

1. 简介​

Taro harmony-hybrid 平台插件和鸿蒙三方模块 @hybrid/web-container 是上述方案的两大组成部分。该方案创建的鸿蒙应用的打包部署形态如下图所示：

编译 Taro 工程生成 harmony-hybrid 平台的 Web 资源，由 Web 服务器加载运行；鸿蒙应用使用 TaroWebContainer 组件加载网站资源，借助该组件提供的 Taro API 实现来达到业务访问原生与使用硬件的能力。

2. 基于 harmony-hybrid 开发鸿蒙应用​

编译 Taro 工程生成 harmony-hybrid 应用资源​

通过 Taro CLI 工具基于 默认模板 创建 Taro 工程，使用如下编译命令生成 harmony-hybrid 平台的 Web 资源：

# yarn
$ yarn build:harmony-hybrid

# npm script
$ npm run build:harmony-hybrid

# pnpm script
$ pnpm build:harmony-hybrid

生成的 Web 资源使用 Web 服务器加载运行或者内置于鸿蒙应用的 resources/rawfile 目录下。

创建鸿蒙应用​

@hybrid/web-container 三方模块提供自定义鸿蒙组件 TaroWebContainer，为运行其中的 harmony-hybrid 应用提供运行时访问系统设备的能力。

在鸿蒙应用中使用 TaroWebContainer 组件的示例代码如下：

• entry/oh-package.json5 配置

"dependencies": {
  "@hybrid/web-container": "1.0.0"
}

• 页面中使用 TaroWebContainer 组件：

import { TaroWebContainer, HostPageState, TaroWebController } from '@hybrid/web-container';

@Entry
@Component
struct HarmonyHybridSample {
  @State pageState: HostPageState = HostPageState.PageInit;
  @State taroWebController: TaroWebController = new TaroWebController();

  build() {
    Column() {
      TaroWebContainer({
        webUrl: 'https://域名/index.html',
        webUrlPrefix: 'https://域名/',
        taroWebController: this.taroWebController,
        pageState: this.pageState,
      })
      .width('100%')
      .height('100%')
    }
  }
}

具体的使用方式可以参考 @hybrid/web-container 的 README.md 文档。

环境要求​

• Taro: 3.6.24 以上版本
• 鸿蒙集成开发环境: DevEco Studio NEXT Developer Preview1 及以上版本

三、转换补充说明​

对于具备小程序版本的产品，可以使用 @tarojs/cli-convertor 命令行工具转化成 Taro 项目，再编译成 harmony-hybrid 来加快适配流程。

最后​

后续我们会继续完善对 harmony-hybrid 平台的适配工作，并根据最新鸿蒙系统能力来补齐和完善 harmony-hybrid 平台能力，同时也希望广大的开发者和参与到 Taro 开源生态共建的同学们，能够一起参与harmony-hybrid 平台的构建和完善，助力鸿蒙生态和 Taro 开源生态的发展。

相关阅读​

• 《华为开发者工具 DevEco Studio》

• 《鸿蒙开发文档》

跨端是前端研发过程中经久不衰的话题，为应对与不同场景的跨端需求也会有很多不一样的跨端解决方案诞生。为支持各端的研发诉求，我们为跨端解决方案提供了多编译内核，并以此逐步拓展各编译内核的特性，为开发者的研发体验提速提供更多可能性，这也就是所谓多编译内核生态。

多编译内核生态​

不论是在各种前端工程化或是跨端解决方案中，Webpack 的出现频率高是毋庸置疑的，同样在 Taro 中也是如此，基于 Webpack 实现的编译内核，就能够为包括各类小程序在内的终端项目提供很好的研发体验，达成一整套开端解决方案来实现所谓「一套代码，多端运行」的能力特性。

但实际上在跨端方案不断迭代的过程中，在个别端生态中可能遇到各种问题和瓶颈也逐渐凸显，比如说我们基于 React Native 实现的 App 端就是如此。

基于 Webpack 实现输出 RN 项目的能力，并借助于 Metro 完成 RN App 的打包和调试等等工作，会是十分便捷的方案，但在实际项目中却依旧会遇到诸如框架层面不能与 Metro 直接交互等等很多问题，维护起来也有诸多不便。

这也就是为什么我们需要在框架内提供 Metro 编译内核，来统一 RN 端的打包工具，为 React Native 生态提供更好的兼容性。

相较于 Webpack，使用 Vite 编译项目在 Web 端会有很多优势，在社区内一直以来也有很高的呼声，不在少数的开发者希望能够在跨端解决方案中支持使用 Vite 编译项目。那么如果能够基于 Vite 实现与 Webpack 编译内核基本一致的能力，来完成多终端项目的编译工作，实际体验又会如何呢？

正是由于许多诸如此类的因素存在，也让我们不断思考解决的方案，最终在面向多终端的研发场景中，继跨端、跨框架之后，有了新的目标——即支持多编译内核的研发生态。

面向多终端研发​

在面向多终端研发的场景中，通过借助 Webpack、Vite、Metro 这类编译工具，可以实现包括 Web、App、小程序、鸿蒙等多终端的研发场景，开发者也能根据项目按需选择，以期获得更佳的研发体验。

尽管我们主动选择在编译环节使用多编译内核，但这样的架构却并不只有优势，同时还要不少问题亟待解决。

譬如需要通过提供一致的生命周期支持，抹平各个插件对支持不同编译内核时的差异；框架配置也不会由于编译内核切换，导致额外的学习成本……编译内核的切换能够在研发和生态等各层面都能平滑无感，这也是我们正努力去实现的。

二、极速构建​

多编译内核或许是一个很好的架构方案，能够支撑各研发场景的特性实现，并给开发者更多选择的自由，但作为跨端解决方案，却不能局限于此。在面向多终端的研发场景中，多编译内核的研发生态下，想要为开发者提供极致的，极速研发体验又该怎样去做呢？

以各个编译内核及其生态为出发点，在框架内为不同研发场景提供极速构建的能力，结合框架架构内的插件系统，最终能够基于多编译内核方案得到全新的架构。

Webpack 编译内核​

在这些编译工具中，相信大家对于 Wepback 都不陌生，将开发者的代码输入 Wepback 内核编译就能够得到 Web 或小程序等等终端应用。

在 Webpack 编译内核中，我们通过 combination 为多端编译提供项目配置处理，不同模块的加载规则等通用能力；小程序端还有插件处理小程序模块和原生模块加载等特性；web 端也需要插件根据打包模式来处理应用和页面入口等等。结合框架的插件机制，开发者也能介入编译流程中，为项目提供自定义拓展，满足个性化的需求。

想要在 Webpack 内核中达成更好的构建体验，除了自定义插件还有更多方案可以选择，比如 Webpack5 的持久化缓存就是其中之一，考虑到编译安全相比于速度更为重要，该特性会默认关闭。当然在绝大多数情况下，持久化缓存都能够以较稳定的方式帮助开发者提升研发体验，如果当项目研发过程中受困于编译速度时这会是个不错的选择。

借助于 ESBuild 等不同工具，我们提供了各可配置模块供开发者选择，依照需求选择更适合项目的工具，依赖预编译也是为此设计的重要特性之一，通过提前编译依赖可以在实际项目中极大提升我们的研发效率，在社区内也广受好评。

依赖预编译，也就是 PreBundle 特性通过 ESBuild 扫描项目依赖并提前编译，借助于 Webpack 的模块联邦能力分别构建 Host 和 Remote 应用，就能实现这一有意思的特性，帮助开发者提升多终端研发的编译体验。

原理其实不复杂，但对应不同端实际执行的操作会有一定不同，在小程序端包括了以下几个步骤。

首先需要扫描项目内的依赖，通过 ESBuild 能够很好的识别项目内使用到的 JS 模块，但是也有不少细节需要注意并处理的，比如识别 Vue 中 setup 语法，避免误判导致遗漏需要预编译的模块；同时其它终端所需的依赖也需避免误判被编译，导入终端不支持的依赖等等。

得到项目所需的依赖后，再次通过 ESBuild 将其打包就能够得到项目所需的 Bundle，但在这里我们还需要需解析对应依赖的入口模式，同时借助于自定义的 SWC 插件优化代码编译能力，将基于 CJS 模式输出的依赖转换成 ESM 后的编译结果进行兼容。

想要在 ESBuild 输出结果中保留原始路径，将会使最终结果难以预测，所以我们需要将其扁平化处理，仅通过虚拟模块保留原始路径。最后对编译内容进行缓存，避免多次编译造成性能损耗。

紧接着，我们需要借助 Webpack 通过 MF 插件打包出 Remote 应用，在这个过程中同时需要传入编译所需的各种插件，比如说 ProviderPlugin 用于提供小程序依赖的运行时环境，并缓存编译结果。Host 应用必要的配置将会同时生成，并将 Host 应用及其资产注入到小程序目录，供最终的项目运行使用。

与小程序端相比，Web 端有很多步骤非常相似，比如前置的依赖扫描与打包等等，尽管具体配置会存在一定差异，比如 Web 端用于 API Shaking 的自定义 Babel 插件就需要通过 SWC 插件重新实现避免基于 Taro 的组件库在 PreBundle 特性中无法得到支持。同时由于小程序和 Web 端本身的差异，后续的步骤中也会有较大差异，比如需要为 Remote 应用配置代理。

虽然 Web 端编译 Remote 应用与小程序一样，都需要通过 ContainerPlugin 创建额外的容器入口，但却并不需要借助 ProviderPlugin 注入 runtime 等等依赖，同时也无需将远程依赖修改为同步模式等等操作。

在配置 Host 应用插件时，需要通过 ContainerReferencePlugin 将 Remote 提供的所有依赖修改为远程模块，并通过特定的引用添加作为外部资源的容器，允许它们加载远程模块，同时为公共的运行时注入必须的 Webpack 工具函数。最后在使用前，我们还需要为 Remote 应用设置代理，供 Host 应用加载应用这些依赖。

实际上，当我们在 Host 应用中直接使用未经加载的 Remote 依赖时，会导致应用报错。在业内一些类似的方案中，往往会需要通过 Babel 修改引用依赖相关的代码逻辑，但实际上如果在应用入口嵌套一层动态加载，Webpack 就会预加载这些 Remote 依赖避免相关问题出现，这也是在官方 MF 示例中推荐的方法。而在该特性方案中，为支持包括外出使用、多页应用构建等特性，我们选择基于 virtual-module 实现这一操作，最大程度借助于 Webpack 自有的能力与生态。

在通过 NutUI 的示例项目测试编译预编译时，可以发现通过 PreBundle 特性能够得到不错的优化，在社区开发者的体验当中，我们也收到了类似的反馈，小程序编译速度约为使用前的 20%，Web 应用也将耗时降低至原方案的约 30%。

这样的性能提升结果让人十分满意，但在跨端环境下使用模块联邦能力，特别是在小程序环境中使用真的如此容易？受限于小程序本身，借助于网络请求来实现该特性会极大程度的降低小程序的使用体验，牺牲用户体验不应该是一个成熟框架应该做的。

模块联邦特性实际是基于 ModuleFederationPlugin 封装提供给开发者使用，如果我们基于它内置的两个插件实现逻辑调整能否优化这一实现呢？

在这两个内置插件中，ContainerPlugin 在构建小程序端使用的 Remote 应用时，需要在插件内为小程序创建额外的容器入口，并提供模块自动注册相关的逻辑，通过劫持 ContainerEntryDependency 将依赖异步逻辑改为同步；与此同时还需要收集使用到的 Webpack 工具函数，并删除冗余的入口、runtime 等 chunk。

而在 ContainerReferencePlugin 中，需要将预编译依赖设置为远程模块，并注入收集到的 Webpack 工具函数，修改 remote 模块中的 id 映射对象，并插入自动注册模块相关的逻辑，在 app.js 中通过 require 依赖所有预编译生成的 chunk 和 remoteEntry；同时需要删除冗余的文件，比如已经无用的远程模加载模块，减少不必要的代码输出。

通过基于提供 ContainerPlugin、ContainerReferencePlugin 的魔改插件 TaroModuleFederationPlugin 供框架使用，就能在小程序中不损失用户体验的同时使用这一特性。开发者也可以自行配置使用，不过如果你的项目正在使用跨端框架，直接使用 PreBundle 特性会是个更好的选择。

当然不论是 TaroModuleFederationPlugin 还是 PreBundle 特性，都可以在第三方的项目中配置使用，以 PreBundle 为例，通过 Chain 传入 Webpack 配置，并执行实例上的 run 方法，我们就能得到最终所需的 Webpack 项目配置文件，并启动项目。

目前也有不少外部项目都通过接入该特性，来获得更佳的研发体验。

Vite 编译内核​

实现 Vite 编译内核，可以说是在追赶潮流，也是当下社区开发者们的呼声，但更多也是希望能够通过支持 Vite 编译提供更多元的研发场景，让开发者可以根据实际需求，自由选择项目在对应场景下所需的编译内核。

相较于传统的编译模式，启动项目时需优先扫描整个项目依赖和代码，才能在应用完成构建后提供服务；Vite 通过使用 ESBuild 构建依赖，并在浏览器请求源码时，将对应模块转换为原生 ESM 按需提供源码，研发速度要快很多。

通过 Vite 我们可以给 Web 端提供更好的研发体验，当然还需要兼容各种小程序的特性，比如说路由、TabBar 等等，还有各类 API 和跨端组件库，也需要兼容性配置。

同样，在 Webpack 编译内核中已经支持的各种能力和特性也不能抛下，包括 React、Preact 等前端 UI 框架的支持，多路由模式等等，也需要在 Vite 编译内核中得到支持。

相比于在 Web 端能够得到不小的提升，在适配小程序场景中的实际收益相对就要低上不少，由于缺少持久化缓存，在编译大型项目时的实际体验与 Webpack 相比并无明显改善，但是通过配置跳过更新的页面也能够给需要的项目提供不错的研发体验。

同样由于小程序自身的限制，Vite 并不能以开发模式来完成小程序的编译，我们在生产模式下提供应用和各页面入口的编译，写入到对应的小程序目录中，并以虚拟模块的形式更新页面，配合适配小程序端的 Vite 插件就可以完成小程序端编译工作。

总结来说，在 Vite 编译核心内，我们通过为小程序和 Web 端提供 config、entry、style 插件来适配各端的能力，当然小程序还需要 page 插件来为页面提供额外的处理。结合框架自身的插件机制，我们就能让 Vite 在适配跨端解决方案的同时，与其它编译内核形成一个互补选项，供开发者使用。

在整个编译系统中，除了我们提供的 Vite 编译内核，CLI 还有配置工具也需要为此同步做出调整，结合内核提供的代码和样式编译能力，就能为绝大多数的编译场景提供支持。同时一些工作我们也在社区内逐步去推进完成，比如小程序的分包能力，还有 Web 端的多路由应用模式等等，都会在之后的版本里一一补齐。

当然在使用 Vite 内核还是可能遇到一些问题，我们在后续也会尝试去针对性优化，比如打包输出成 CJS 模式，在配置 splitChunk 后可能会导致循环依赖，在小程序中报错；另一个就是刚刚有提到的编译缓存，在小程序中二次编译速度可能不及基于其它打包工具的编译内核。

Metro 编译内核​

从 Webpack 输出 RN 项目，到改用 Metro 是一个很自然的选择，借助于 Metro 我们也能将适配 React Native 的很多操作，从编译时转向到运行时，为开发者提供更好的研发体验。

从 CLI 读取项目配置，到 Metro 内核完成编译，并启动调试服务，Metro 都能比 Webpack 更好的兼容 React Native 已有的生态环境。在框架层面需要做的，仅是为开发者提供合并定义 Metro 配置的能力，并让 Metro 可以理解我们在适配其它端时对 Webpack 的操作，并在一定程度上复刻。

基于 @tarojs/rn-transformer 处理 RN 的入口文件，在编译时注入页面的包装方法等，并将入口的全局样式注入到页面中；同时对运行时进行一定程度的修改，比如基 React Navigation 对路由进行封装，提供动态创建导航的方法，并且封装导航相应的 API 内容；在 runtime 中对应用和页面配置进行处理等等。

相比于过往方案，Metro 能够提升编译速度，提供更好的 SourceMap 支持，提升研发效率和体验；同时规避由于 Webpack 提供的多 entry 模式导致的问题，并降低包体大小等等；也与 React Native 默认配置保持一致，支持更灵活的合并方式。

在 App 端，我们通过 Metro 在 Transformer 和 Runtime 两个层面对项目进行修改，让方案可以在支持多端的同时，更加顺滑的支持使用 RN 完成 App 端的研发工作。

那如果希望在框架之外，使用这些开发好的 RN 能力，也有比较简单的方法快速接入，通过 @tarojs/rn-supporter 就能提供编译、运行时配置，和资源样式解析方案的支持。

具体使用如下图代码所示，需要注意的是，在该外部使用的方案中，路由相关的逻辑需要自行处理。

总结来说，在我们的编译系统方案中，通过 CLI 和插件系统结合多个编译内核来为开发者提供跨端解决方案。

在编译内核之外，插件系统也能够很好的帮助框架为开发者根据编译平台，提供解决方案。

通过 CLI 完成编译工作时，我们也可以通过加载不同平台插件的方式，来完成编译时拓展和运行时能力的注入，提供最终的编译结果。

在插件系统中，我们从 CLI、编译过程和编译平台三个方向提供能力的拓展，结合各个生命周期，比如：onBuildStart、onCompilerMake、modifyWebpackChain 等等，各个编译内核都能为不同端编译提供更加个性化的定制服务。借助于此，我们可以提供 React、Vue、Flutter 等等不同 DSL 的插件；也能为小程序、鸿蒙等多端提供端平台插件，辅助完成编译。

在这样的架构下，开发者也能根据我们提供的生命周期，横向或纵向拓展编译能力，为各个终端拓展编译能力支持，比如说飞书、钉钉、企微等等小程序还有鸿蒙端平台插件，都是 Taro 技术委员会或者社区开发者通过这样的方式提供的。

同时在其它方面，为提升构建体验也有不少小优化，比如 SWC 虽然与 Babel 实际上还存在差异，但在很多特殊的应用场景下已经足够使用，比如在依赖预编译中提供代码编译，以及应用与页面配置读取等等，都有不少提升。

ESBuild 也是如此，除了 PreBundle 特性中的使用，我们还在压缩代码和样式中提供了相关的配置，不过相比于 terser 和 csso，还存在压缩效果等问题，加之对其稳定性的考量，我们并没有将其配置为默认选项，可以由开发者自行选择。

三、总结与展望​

跨端解决方案结合多编译内核生态，我们能够在开放式的跨端跨框架解决方案中，为开发者提供更高的自由度和研发体验。

通过 React、Vue、Svelte 等 DSL 插件，结合 Web 端渲染规范，小程序的标准 API 和组件库等等，我们能够为不同终端提供可靠的跨端能力，同时在 Webpack、Vite、Metro 等多个编译内核的帮助下，我们能够提供更加高效的研发体验，为日常的开发工作提供更多的便利。

对于框架本身来说，在未来我们也会提供更多的前端 UI 框架或编译工具的支持，比如 Solid 等等。

性能方面，也希望为小程序提供更好的热重载、预渲染等能力，提升多端研发体验，提供适用于更多场景的多端性能优化方案。

同时根据场景提示性能优化方案，以及性能指标测评工具，为项目优化提供指引。

对于 Flutter 编译内核的支持也在日程中，在社区内持续推进；通过 Web Assembly 对小程序的运行时进行优化等等，也都在 Taro 未来的路线规划当中，敬请期待。

同时，我们还预期提供框架的测试方案，通过 TestRenderer 为跨端方案的测试提供更好的体验。

最后关于 Taro 开源工作，目前已经由 Taro 技术委员会主导，在 Taro 生态超过 700 位贡献者中，有 50 余位行业内各个公司的同学长期参与 Taro TOC 的会议分享，所有贡献者们都为推进 Taro 跨端解决方案不断迭代作出了诸多努力和贡献，正因如此才能够让我们在多编译内核生态下，获得更加极致的研发体验。

正如技术委员会成员 @xueshuai 在投稿 v3.6 版本代号时说道，“「Reach」代表着不屈和希望，给开发者带来更好的用户体验，是全体开发者的坚守“，希望社区的积极氛围可以引导 Taro 的生态更加美好。

日前 Taro v3.6 正式版本已经发布，下文将围绕 3.6 版本内的跨端、平台能力支持等多个方面展开，快速了解在 v3.6 中各个重要特性。

一、跨端能力支持​

支持各类跨端能力，抹平多端研发之间的体验差异，是 Taro 一直以来尝试去实现的，基于 Taro 3 适配多端前端 UI 框架的逻辑，通过在小程序端模拟实现框架所需的 BOM / DOM API 就能达成对于各类跨端能力的适配。

1. 支持路由库​

在 Web BOM 中，History & Location 对象是重要组成部分，它们是实现前端路由的关键。Taro 为支持前端路由库的使用，在运行时中引入了 histroy location 对象的实现，同时尽可能与 Web 端规范对齐。通过在 window 对象上访问到 history 和 location 对象，并支持监听 hashchange 和 popstate 事件，为跨端使用路由库提供基础。

// 统称: 页面路由状态
window.history
window.location

// 支持监听事件
window.addEventListener('hashchange', () => {})
window.addEventListener('popstate', () => {})

小程序天然支持多页面(pages 数组配置)，因此 Taro 并非以整个应用为一个路由系统，而是顺应小程序规范以页面维度进行路由管理。每当切换页面时，会将当前页面的页面路由状态缓存。跳转至新页面后会重新创建页面路由状态，并挂载在 window 对象上。当返回上一级页面时，会将上一级页面的页面路由状态重新挂载到 window 对象中。

至此，可以在小程序中使用成熟的前端路由库了，包括 react-router 和 vue-router。在路由库中，诸如 <Link> 组件内部会动态生成 <a> 标签，因此需要引入 @tarojs/plugin-html 插件以支持在 Taro 中使用 html 标签开发组件。

{
  "plugins": ["@tarojs/plugin-html"]
}

在 Taro 编译过程中，当 DOM 序列化数据的 nn 字段为 HTML 标签时，标签会映射为对应的小程序组件名称。由于无法提前预知动态标签，因此需要应用显式告知可能会使用到的动态标签。例如在应用中塞入一个无样式的标签名即可：

<View>
  <a></a>
</View>

更多细节可以查看 官方文档，也可以查看官方提供的 DEMO 获知更多用法。

2. 支持网络请求库​

与适配各路由库类似，通过对运行时补充就能支持绝大多数的网络请求库，所有请求库在底层都是通过使用 XMLHttpRequest 或 Fetch 提供能力支持的，而请求库大多都兼容 XMLHttpRequest 对象，也即是在提供 XMLHttpRequest 对象实现的基础上，就能支持绝大多数的第三方库。

支持这些成熟的网络请求库（例如 axios 等）就能为开发者在跨端研发场景下，提供更好的研发体验。通过引入 @tarojs/plugin-http 插件，为小程序环境提供网络请求库所需的运行时环境支持。

{
  "plugins": ["@tarojs/plugin-http"]
}

注意：当前 @tarojs/runtime 在小程序环境中缺少Blob、FormData、File对象，这在网络请求库的文件上传特性中是必须的，故暂不支持。

在支持网络请求库的同时，考虑到部分用户，特别是 web 转小程序的项目中依赖 cookie 实现鉴权，@tarojs/plugin-http 插件模拟实现了 document.cookie api 以及通过 http 响应头 Set-Cookie 来设置客户端 cookie 值 ，行为和 web 中保持一致。 此功能默认设置为关闭，需要的可通过 enableCookie 配置开启。

在 @tarojs/plugin-http 插件中，以 axios 作为基准库完成测试，如果在使用其他请求库时遇到适配问题，可在社区或通过 issues 反馈相关信息。

二、平台能力支持​

拓展更多端平台，适配支持各端能力与特性，是跨端解决方案不断发展的重要组成部分之一。

1. 支持鸿蒙端平台插件​

在 Taro 与 OpenHarmony 建立官方合作关系，并受邀成立 CrossPlatformUI Sig（跨平台前端框架兴趣小组）后，让 Taro 支持支配鸿蒙就一直在议程上，鸿蒙的方舟开发框架提供类 Web 范式编程，支持使用 JS 开发 UI 层，其语法与小程序相接近，可以沿用 Taro 现有的架构适配鸿蒙。

持续关注 Taro 的开发者可能还记得，在 v3.5-canary 版本时，我们曾推出支持 Taro 应用适配到鸿蒙平台的插件，但最终没有合入 v3.5 版本主干并顺势推出该能力。

在 @tarojs/plugin-platform-harmony 端平台插件经过一段时间的打磨，相关能力与特性也在社区推进下持续优化，框架编译的项目在鸿蒙开发板上得到进一步验证，同时在 Taro v3.5 新增的 @tarojs/webpack5-runner 编译内核也能够为鸿蒙项目编译提供支持，终于我们在 v3.6 中再次为社区开发者提供了适配鸿蒙的端平台插件。

// config/index.js

config = {
  // 配置使用插件
  plugins: ['@tarojs/plugin-platform-harmony'],
  // harmony 相关配置
  harmony: {
    // 【必填】鸿蒙应用的绝对路径
    projectPath: path.resolve(process.cwd(), '../MyApplication'),
    // 【可选】HAP 的名称，默认为 'entry'
    hapName: 'entry',
    // 【可选】JS FA 的名称，默认为 'default'
    jsFAName: 'default'
  }
}

具体使用方法可查看官方文档，需要注意鸿蒙插件不在 Taro 项目内维护，所以并不会每次发布同版本号版本，直接使用 minor 与 Taro 版本号相同的版本即可。

特别感谢以下同学为鸿蒙适配作出的贡献：

@AdvancedCat、@jiaozitang、@huozhongyi123、@troy-sxj、@JSZabc、@crazyonebyone、@evernoteHW、@soulhat、@xueshuai、@LuMeiling

2. React Native 能力​

为了让整体开发体验跟 RN 更加一致，减少开发者的理解成本。我们对 @tarojs/rn-runner 的代码进行了重构。将 Taro RN 需要的所有编译逻辑，都封装到了 metro 配置中，与 RN 项目集成会更加灵活。

新版本在项目根目录下会创建入口文件 index.js 和配置文件 metro.config.js。如项目本身有这两个文件，则不会生成，需要参考模板进行添加或合并。另外 Taro RN 的相关配置，集中在 resolver 和 transformer 中，可根据相关源码自行覆盖调整。

React Native 0.70 版本已于 2022-9-5 正式发布，在 0.70 版本中 Hermes 已成为默认的 JS 引擎，

v3.6 版本将与 RN 默认配置保持一致，如不需要可自行关闭。Hermes 也带来了 RN 性能的较大提升，特别是启动场景，详细内容参考官方文章。

Taro 将与 RN 社区保持同步，将默认的 RN 版本设置为 0.70。相关依赖也已同步至最新版本，仍然可使用 yarn upgradePeerdeps 进行更新。@react-native-community/clipboard 及 @react-native-community/cameraroll 已被弃用，旧版本升级后需要删除。

注意：升级后将不再支持 iOS 12，详细内容请参考 discussions。同时 Taro Playground 作为 RN 端的调试工具及跨端 Demo 同步更新至 v3.6。

3. Web 端能力​

通过在社区中收集的相关问题反馈，Taro Web 各类特性也一直在不断推进，让开发者在多端研发的体验能够尽可能达成一致。面对各类自定义 Web 端能力的需求，虽然有很多方案可以提供组件、API 等能力的补充，但类似小程序端平台插件这样的能力在 Web 端中并没有得到支持。

在 3.6 版本中，我们将 Web 端各类定制化的能力从 runner 中转移到 @tarojs/plugin-platform-h5 插件中提供，譬如通过配置 useHtmlComponents 模式替换使用的组件库；注册 Web Components 组件库，配置各前端 UI 框架组件适配器；移除不必要的 API 等等特性。

class H5 extends TaroPlatformWeb {
  // ...
}

export default (ctx) => {
  ctx.registerPlatform({
    name: 'h5',
    useConfigName: 'h5',
    async fn({ config }) {
      const program = new H5(ctx, config)
      await program.start()
    },
  })
}

和小程序端一样，借助于插件或 TaroPlatformWeb 基类，开发者可以很容易横向或纵向拓展 Web 端的各项能力，详情可参考文档。

Web 端也一直在补充各类开发者常用的组件与 API 抹平与小程序端的差异。在 v3.6 版本中新增生命周期、WXML 相关的 API 支持若干，例如：createIntersectionObserver 、createMediaQueryObserver 等，同时新增 movable-area、movable-view 等组件支持。

在社区开发者交流时，我们也发现了部分研发场景下需要监听各 API、组件不支持事件，相比于支持 canIUse 方法在跨端转换场景中能够更有效定位问题，所以通过支持 __taroNotSupport 事件满足相关需求，可以参考以下示例使用。

interface IOption {
  name: string // 不支持的组件或 API 名称
  type: 'method' | 'component' // 'method': API; 'component': 组件
  category: 'permanently' | 'temporarily' | 'weixin_corp' // 'weixin_corp': 仅在微信公众号 JS-SDK 环境下支持
  args?: any[] // API 传入参数
  instance?: unknown // 组件实例
}
Taro.eventCenter.on('__taroNotSupport', (option: IOption) => {
  console.warn('调用不支持的 API 或组件', option)
})

三、跨框架组件库​

借助于 stencil，Taro 3 得以通过 Web Components 实现一套跨框架组件库，通过适配器将 Taro 的组件库提供给各个前端 UI 框架使用，开发者也可以基于这些封装上层组件，提供更多有趣的能力。

1. Web 端适配器​

出于降低开发者维护门槛，与 stencil 组件库打包流程更好兼容等多方面考虑，在 3.6 版本中我们在升级 stencil 依赖版本的同时，通过官方提供的  ds-output-target 工具替换了原有的自定义适配器。

该版本适配器更好的抹平各个框架组件使用差异，补齐过往版本迭代过程中部分特性兼容性的缺失问题，为开发者提供更好的体验。在 3.6 中依旧保留过往版本各框架适配器，可以参考以下示例通过配置别名替换组件库适配器（不建议使用，后续不会维护旧版适配器，可能无法得到新的组件或特性支持）。

// config/index.js

const config = {
  h5: {
    webpackChain(chain) {
      chain.resolve.alias.set(
        // 当前版本适配层地址 @tarojs/components/dist/[framework]
        '@tarojs/components/dist/react',
        // 旧版本适配层地址 @tarojs/components/dist/[framework]/component-lib
        '@tarojs/components/dist/react/component-lib'
      )
    },
  },
}

2. 虚拟列表​

作为从 Taro 3 开始支持的上层组件，虚拟列表应当是很多开发者都熟悉的特性，在过往版本中也有过数次升级，支持包括 unlimitedSize、relative 定位模式等特性，在 v3.6 版本中我们再次对虚拟列表做出了调整，将其从 @tarojs/components 包中抽离到 @tarojs/components-advanced 中维护（4.x 版本之前开发者依旧可以通过 @tarojs/components/virtual-list 引用虚拟列表组件），也欢迎大家一同参与上层组件库的维护与共建，沉淀更多跨端可用的能力。

在新版本中，虚拟列表支持在选择 preact、vue3 框架构建的项目中使用，同时在使用各个前端 UI 框架的项目中都支持使用选择 absolute****、****relative ********不同定位方式，unlimitedSize 模式与传入 itemSize 函数等特性也得到支持。

以 Vue 为例，我们需要在入口文件声明使用：

// app.js 入口文件
import Vue from 'vue'
import registerVirtualList from '@tarojs/components-advanced/dist/components/virtual-list'
// Note: 使用以下路径导出插件可以在 vue 中获得更好的类型支持
// import registerVirtualList from '@tarojs/components-advanced/dist/components/virtual-list/vue'

Vue.use(registerVirtualList)

一个最简单的长列表组件会像这样，virtual-list  的 5 个属性都是必填项：

<! –– row.vue 单项组件 ––>
<template>
  <view :id="id" :class="index % 2 ? 'ListItemOdd' : 'ListItemEven'"> Row {{ index }} : {{ data[index] }} </view>
</template>

<script>
  export default {
    props: ['id', 'index', 'data'],
  }
</script>

<! –– page.vue 页面组件 ––>
<template>
  <virtual-list
    wclass="List"
    :height="500"
    :item-data="list"
    :item-count="list.length"
    :item-size="100"
    :item="Row"
    width="100%"
  >
    <! –– Vue 中支持列表首尾使用的插槽，对应 React 中的 renderTop、renderBottom 参数 ––>
      <template v-slot:top>
        <view>top</view>
      </template>
      <template v-slot:bottom>
        <view>bottom</view>
      </template>
  </virtual-list>
</template>

<script>
  import { markRaw } from 'vue'
  import Row from './row.vue'

  function buildData(offset = 0) {
    return Array(100)
      .fill(0)
      .map((_, i) => i + offset)
  }

  export default {
    data() {
      return {
        Row: markRaw(Row),
        list: buildData(0),
      }
    },
  }
</script>

需要注意的是，为抹平多框架参数差异便于维护，旧版本中部分命名会统一修改，比如在 React 版本中通过 children 传入的子节点组件改为 item；Vue 中的 wclass、wstyle 这类写法也不再支持。

在新版本中，根据需求和研发场景合理设置 itemSize、overscanCount、placeholderCount 等参数优化长列表，可以获得比旧版本更加顺滑的体验，更多详情可以参考官方文档。

四、研发生态​

1. 小程序持续集成 CI​

去年 Taro 提供小程序持续集成插件 @tarojs/plugin-mini-ci ，帮助开发者提供更好的研发体验，经过一年的项目沉淀和反馈，在本次版本重构了去年的所有代码，并提供了更优秀体验和灵活的配置。

• 本次新增特性支持独立的 open、preview、upload 命令，操作自定义目录适用于将 taro 作为项目一部分（混合开发）的开发场景；
• 同步更新各个小程序端的 CI API 变更（阿里系、抖音小程序变化最大）
• 新增钉钉小程序 CI 集成；
• 新增京东小程序 CI 集成;
• 统一所有平台 CI 构建后的输出数据，并将数据传递给新增的onPreviewComplete、onUploadComplete两个钩子用户可以编写新的插件，基于这个钩子实现 飞书、钉钉 的 CI 推送功能等等。

以下为当前各平台支持的功能情况表：

ps： 该插件在 taro3.6.0 版本以下亦可支持单独使用，插件版本号无需保持与其他包同步。

更多详情可以参考官方文档，同时要特别感谢 @bigMeow 为 CI 自动化脚本做出的贡献～

2. PostCSS 版本升级​

在 Taro 项目持续迭代的过程中，部分依赖稳定没有实时跟进各个社区内的特性与优化，并升级相关依赖，PostCSS 就是其中之一。如果开发者想要通过新版本的特性来优化构建流程与最终产物，相对会很困难且可能会存在一定问题阻塞。

为此在 3.6 canary 通过梳理项目内相关插件与依赖，对 PostcCSS 版本进行梳理并升级，升级后版本为 v8.4.18。本次升级主要包含以下内容：

1. 对 Taro 内部的 PostCSS 插件使用 PostCSS 8 版本 API 进行改写，降低代码量同时减少插件对 CSS 扫描次数进而提高构建速度；
2. 使用 peerDependencies 管理 postCSS 依赖，降低用户的 node_modules 体积和复杂度；
3. 对 Taro 全量模板的 PostCSS 版本同步进行更新，方便开发者对新特性的使用。

特别感谢 @xueshuai 为相关工作做出的贡献，希望开发者可以因此获得更好的研发体验。

3. 类型与文档自动同步​

快速同步各平台支持的类型，一直以来都是十分头疼的问题之一，想要实时跟进各个平台以提升用户体验十分困难，更多时候我们都通过开发者提交的 PR 或 issue 对这些平台的类型更新维护。如果能够根据各个小程序平台官方提供的文档自动化生成类型，这对于框架维护和开发者来说会是一个很棒的体验。

通过在 Taro 社区中的积极探讨和论证，我们引入了自动同步各小程序平台组件类型的脚本机制，并通过与 GitHub CI 让机器人为 Taro 仓库提交类型更新 PR。组件类型的自动化同时让 Taro 的文档在类型更新时，同步这些平台组件的变更，为开发者提供更好的文档索引能力。同时我们也在文档提供了 canIUse 页面，供开发者快速检索组件、特性在各个平台支持的程度。

希望后续也能够通过和各平台合作的方式优化该能力，为开发者提供更好的体验。在这里特别感谢 @rebinv8 为组件类型自动化脚本做出的贡献～

4. Taro Playground 同步升级​

作为 RN 端的调试工具及跨端 Demo，Taro Playground 同步更新 v3.6 更新。此次更新无法保证向下兼容，使用旧版本 Taro 的开发者，如需调试 Android，可在 releases 中下载旧包进行调试。在 App Store 中，我们只上架最新版本，需要旧版本的开发者请不要开启应用自动更新。如不慎升级，需自行打包编译，或联系我们加入测试组。

五、升级指南​

1. 创建 v3.6 版本项目：​

# 安装 v3.6.0 的 CLI 工具
npm i -g @tarojs/cli@latest
# 创建项目
taro init taro_project

# 也可以跳过安装 CLI 工具使用 npx 创建项目
npx @tarojs/cli@latest init taro_project

2. 已有项目升级到最新版本：​

1. 将 package.json 文件中 Taro 相关依赖修改为 3.6.0 版本；
2. Taro v3.6 将 web 端插件化，需要新增依赖 @tarojs/plugin-platform-h5，同时 @tarojs/router、@tarojs/taro-h5 不再需要额外声明依赖，可自行移除；
3. 重新安装依赖，如果安装失败或打开项目失败，可以删除 node_modules、yarn.lock、package-lock.json 后重新安装依赖重新尝试。

最后​

自 Taro 引入技术委员会等机制后，与社区互动愈加频繁，Taro 也得益于诸多贡献者的帮助有能力去实现更多有意思的特性，给开发者带来更好的用户体验，这也是 Taro v3.6 在代号「Reach」中的期待。感谢各位参与到 Taro 开源生态共建的同学们，所有的努力都让 Taro 的生态更加美好，为建立更加完善、更加可持续的 Taro 开源生态，贡献力量！

一、支持路由库​

Taro 3 适配前端 UI 框架的方式更接近于前端的本质，通过在小程序端模拟实现框架所需的 BOM/DOM API 来达成，对于适配各个路由库也是同样的思路。

1. 运行时引入 History & Location 对象​

在 Web BOM 中，History & Location 对象是重要组成部分，它们是实现前端路由的关键。Taro 为了支持前端路由库的使用，在运行时中引入了 histroy location 对象的实现，且尽可能与 Web 端规范对齐，你可以在 window 对象上访问到 history 和 location 对象。同时，也支持监听 hashchange 和 popstate 事件，这为使用路由库提供技术基础。

// 统称: 页面路由状态
window.history
window.location

// 支持监听事件
window.addEventListener('hashchange', () => {})
window.addEventListener('popstate', () => {})

小程序天然支持多页面(pages 数组配置)，因此 Taro 并非以整个应用为一个路由系统，而是顺应小程序规范以页面维度进行路由管理。每当切换页面时，会将当前页面的页面路由状态缓存。跳转至新页面后会重新创建页面路由状态，并挂载在 window 对象上。当返回上一级页面时，会将上一级页面的页面路由状态重新挂载到 window 对象中。

2. 使用路由库​

至此，可以在小程序中使用成熟的前端路由库了，包括 react-router 和 vue-router。在路由库中，诸如 <Link> 组件内部会动态生成 <a> 标签，因此需要引入 [@tarojs/plugin-html](https://docs.taro.zone/docs/use-h5) 插件以支持在 Taro 中使用 html 标签开发组件。

{
  "plugins": ["@tarojs/plugin-html"]
}

在 Taro 编译过程中，当 DOM 序列化数据的 nn 字段为 HTML 标签时，标签会映射为对应的小程序组件名称。由于无法提前预知动态标签，因此需要应用显式告知可能会使用到的动态标签。例如在应用中塞入一个无样式的标签名即可：

<View>
  <a></a>
</View>

更多细节可以查看 官方文档，也可以查看官方提供的 DEMO 获知更多用法。

二、跨框架组件库​

借助于 stencil，Taro 3 得以通过 Web Components 实现一套跨框架组件库，不过由于其 2.14+ 版本会使用一些 webpack4 不兼容的语法特性，在 3.6-canary 之前的组件库将 stencil 版本限制在 2.13+ 版本内，在 3.6-canary 版本中也针对该问题进行了修复，同时借助 stencil 的新特性优化诸多组件库在 props 与事件的遗留问题。

1. Web 端框架适配器​

Web Components 虽然可以在各个前端 UI 框架中使用，但是依旧会有很多兼容性问题，这些可以通过 Custom Elements Everywhere  的一系列测试用例有所了解。所以在 Taro 3 发布之初，Web 端跨框架组件库还通过提供不同前端 UI 框架的自定义适配器，让不同框架使用 taro 提供的跨框架组件。

尽管这套适配层方案能够很好的兼容 react 框架，但对于组件库的维护者来说会额外的心智负担，比如新增组件时需要同步更新适配器；这个问题在 vue 中则更为明显，不仅 props 需要额外的配置，表单类组件也需要对事件进行标注等。这些问题不仅提升了新同学介入组件库维护的门槛，也使得维护者不能专注于组件库的能力优化。

解决问题的方法当然也很简单，那就是通过脚本在组件库编译时针对不同 UI 框架自动化导出对应组件，社区内也有足够多方案可供选择。在这里我们使用官方提供的  ds-output-target 工具并在一定程度上调整输出结果，并同步过往适配器中 Taro 做出的体验优化。

在 3.6 版本中，新的适配层不仅对齐各个框架组件使用体验，同时也补齐过往适配器在迭代过程中部分特性兼容性的缺失问题。如果依旧希望使用 3.6 以前版本适配器，也可以参考以下示例，通过配置别名替换组件库。

// config/index.js

const config = {
  h5: {
    webpackChain(chain) {
      chain.resolve.alias.set(
        // 当前版本适配层地址 @tarojs/components/dist/[framework]
        '@tarojs/components/dist/react',
        // 旧版本适配层地址 @tarojs/components/dist/[framework]/component-lib
        '@tarojs/components/dist/react/component-lib'
      )
    },
  },
}

2. 类型自动生成​

如何快速同步各小程序平台当前支持的类型，对于 Taro 来说一直是个很让人头疼的问题，实时跟进各个平台的每一次更新很难做到，更多时候我们都通过开发者提交的 PR 或 issue 对这些平台的类型更新。如果能够根据各个小程序平台官方提供的文档自动化生成组件类型，这对于开发者来说会是一个很棒的体验。

通过在 Taro 社区中的积极探讨和论证，我们引入了自动同步各小程序平台组件类型的脚本，并通过与 GitHub CI 让机器人为 Taro 仓库提交类型更新 PR。组件类型的自动化同时让 Taro 的文档在类型更新时，同步这些平台组件的变更，为开发者提供更好的文档索引能力。

在这里特别感谢 @rebinv8 为组件类型自动化脚本做出的贡献～

三、支持适配鸿蒙​

在 Taro 与 OpenHarmony 建立官方合作关系，并受邀成立 CrossPlatformUI Sig（跨平台前端框架兴趣小组）后，让 Taro 支持适配鸿蒙就一直在议程上，鸿蒙的方舟开发框架提供类 Web 范式编程，支持使用 JS 开发 UI 层，其语法与小程序相接近，可以沿用 Taro 现有的架构适配鸿蒙。

持续关注 Taro 的开发者可能还记得，在 v3.5-canary 版本时，我们曾推出支持 Taro 应用适配到鸿蒙平台的插件，但最终没有合入 v3.5 版本主干并顺势推出该能力。在 @tarojs/plugin-platform-harmony 端平台插件经过一段时间的打磨，相关能力与特性也在社区推进下持续优化，框架编译的项目在鸿蒙开发板上得到进一步验证，同时在 Taro v3.5 新增的 @tarojs/webpack5-runner 编译内核在 canary 版本中也能够为鸿蒙项目编译提供支持，终于我们在 v3.6-canary 中再次为社区开发者提供了适配鸿蒙的端平台插件。

使用方法​

1. 在项目中安装鸿蒙端平台插件

   pnpm add -D @tarojs/plugin-platform-harmony@canary
   

   需要注意鸿蒙插件不在 Taro 项目内维护，所以并不会每次发布同版本号版本，直接使用 minor 与 Taro 版本号相同的版本即可。

2. 在 config/index.js 中增加编译配置

   // config/index.js
   
   config = {
     // 配置使用插件
     plugins: ['@tarojs/plugin-platform-harmony'],
     mini: {
       // 如果使用开发者工具的预览器（previewer）进行预览的话，需要使用 development 版本的 react-reconciler。
       // 因为 previewer 对长串的压缩文本解析有问题。（真机/远程真机没有此问题）
       debugReact: true,
       // 如果需要真机断点调试，需要关闭 sourcemap 的生成
       enableSourceMap: false,
     },
     // harmony 相关配置
     harmony: {
       // 【必填】鸿蒙应用的绝对路径
       projectPath: path.resolve(process.cwd(), '../MyApplication'),
       // 【可选】HAP 的名称，默认为 'entry'
       hapName: 'entry',
       // 【可选】JS FA 的名称，默认为 'default'
       jsFAName: 'default',
     },
   }
   

3. 准备鸿蒙运行环境

   开发鸿蒙软件需要用到 HUAWEI DevEco Studio，它提供了模板创建、开发、编译、调试、发布等服务。

   鸿蒙运行环境主要包括以下内容

   （1） 注册开发者账号

   （2）下载 DevEco Studio 安装包

   （3）启动 DevEco Studio，根据工具引导下载 HarmonyOS SDK

   （4）新建 MyApplication JS 项目

   （5）使用预览器或真机查看应用效果

   参考资料：《初窥鸿蒙》、《华为开发者工具》、《鸿蒙开发文档》

4. 项目运行

   Taro 编译鸿蒙项目命令

   $ taro build —-type harmony —-watch
   

   

   testHarmony 为您通过 DevEco Studio 创建的 JS 项目。

特别感谢以下同学为鸿蒙适配作出的贡献：

@AdvancedCat、@jiaozitang、@huozhongyi123、@troy-sxj、@JSZabc、@crazyonebyone、@evernoteHW、@soulhat、@xueshuai、@LuMeiling

四、RN​

1. React Native 0.70 版本支持​

React Native 0.70 版本已于 2022-9-5 正式发布。在 0.70 版本中 Hermes 已成为默认的 JS 引擎，我们将与 RN 默认配置保持一致，如不需要可自行关闭。Hermes 也带来了 RN 性能的较大提升，特别是启动场景，详细内容参考官方文章。 Taro 将与 RN 社区保持同步，将默认的 RN 版本设置为 0.70。相关依赖也已同步至最新版本，仍然可使用 yarn upgradePeerdeps 进行更新。@react-native-community/clipboard 及 @react-native-community/cameraroll 已被弃用，更新后可删除。

注意：升级后将不再支持 iOS 12，详细内容请参考 discussions。

2. @tarojs/rn-runner 代码重构​

之前的版本中，为了让 Taro 代码能够运行在 RN 平台上，我们对 Metro 的编译过程做了较多的定制，并且封装了入口文件以及 metro 的相关配置。这样做导致了多个问题：

1. 打包只能通过 yarn build:rn 等方式进行，而无法使用 react-native bundle 进行，存在学习成本。
2. RN 的编译流程中，需要过滤掉 RN 原有的 bundle 打包过程，替换成 Taro 的打包。这一步在开发者环境搭建过程中，常常出现问题。
3. 无法对入口文件进行处理，比如加入一些全局逻辑。

为了让整体开发体验跟 RN 更加一致，减少开发者的理解成本。我们对 @tarojs/rn-runner 的代码进行了重构。将 Taro RN 需要的所有编译逻辑，都封装到了 metro 配置中。新版本在项目根目录下会创建入口文件 index.js 和配置文件 metro.config.js。如项目本身有这两个文件，则不会生成，需要参考模板进行添加或合并。另外 Taro RN 的相关配置，集中在 resolver 和 transformer 中，如需覆盖，建议先看一下相关源码。

这样做之后，Taro RN 的打包过程就与 RN 本身无太多区别，与 RN 项目集成会更加灵活。react-native 命令行的使用，请参考官方文档， yarn build:rn 等命令仍然保留。使用 react-native 命令行无法自动打印二维码，请输入 q 进行打印。ip 更换等场景，也可以输入 q 重新打印二维码。

3. 调试工具 Taro Playground 升级至 Taro 3.6 版本及 React Native 0.70​

Taro Playground 作为 Taro RN 端的调试工具及跨端 Demo，进行了同步更新。此次更新无法保证向下兼容，使用旧版本 Taro 的开发者，如需调试 Android，可在 releases 中下载旧包进行调试。在 App Store 中，我们只上架最新版本，需要旧版本的开发者请不要开启应用自动更新。如不慎升级，需自行打包编译，或联系我们加入测试组。

五、研发生态​

1. 小程序持续集成 CI​

去年 Taro 提供小程序持续集成插件 @tarojs/plugin-mini-ci ，帮助开发者提供更好的研发体验，经过一年的项目沉淀和反馈，在本次版本更新中提供了更优秀的体验。

本次新增特性支持独立的 open、preview、upload 命令，操作自定义目录适用于将 taro 作为项目一部分（混合开发）的开发场景；同时再次同步各个小程序端的 CI 版本变更，并支持应用到钉钉小程序上；统一所有平台 CI 构建后的输出数据，并将数据传递给新增的onPreviewComplete、onUploadComplete两个钩子用户可以编写新的插件，基于这个钩子实现 飞书、钉钉 的 CI 推送功能等等。

更多详情可以参考官方文档，同时要特别感谢 @bigMeow 为组件类型自动化脚本做出的贡献～

2. PostCSS 版本升级​

在 Taro 项目持续迭代的过程中，部分依赖稳定没有实时跟进各个社区内的特性与优化，并升级相关依赖，PostCSS 就是其中之一。如果开发者想要通过新版本的特性来优化构建流程与最终产物，相对会很困难且可能会存在一定问题阻塞。

为此在 3.6 canary 通过梳理项目内相关插件与依赖，对 PostcCSS 版本进行梳理并升级，升级后版本为 v8.4.18。本次升级主要包含以下内容：

1. 对 Taro 内部的 PostCSS 插件使用 PostCSS 8 版本 API 进行改写，降低代码量同时减少插件对 CSS 扫描次数进而提高构建速度；
2. 使用 peerDependencies 管理 postCSS 依赖，降低用户的 node_modules 体积和复杂度；
3. 对 Taro 全量模板的 PostCSS 版本同步进行更新，方便开发者对新特性的使用。

特别感谢 @xueshuai 为相关工作做出的贡献，希望开发者可以因此获得更好的研发体验。

六、升级指南​

1. 创建 canary 版本项目：​

# 安装 **v3.6.0-canary 的 CLI 工具**
npm i -g @tarojs/cli@**canary
# 创建 canary 版本项目
taro init taro_canary_project

# 也可以跳过安装 CLI 工具使用 npx 创建 canary 版本项目
npx** @tarojs/cli@**canary init taro_canary_project**

2. 已有项目升级到 canary 版本：​

1. 将 package.json 文件中 Taro 相关依赖的版本修改为 3.6.0@canary
2. 重新安装依赖，如果安装失败或打开项目失败，可以删除 node_modules、yarn.lock、package-lock.json 后重新安装依赖重新尝试。

最后​

Taro v3.6 代号「Reach」，致远星代表着不屈和希望，希望该版本能够给开发者带来更好的用户体验，感谢各位参与到 Taro 开源生态共建的同学们，所有的努力都让 Taro 的生态更加美好，为建立更加完善、更加可持续的 Taro 开源生态，贡献力量！

日前 Taro v3.5 已正式发布，下文将介绍关于 3.5 的主要特性与重要修复，以及后续的版本规划。

一、编译提速​

Taro v3.5 基于 Webpack5 构建了新的编译系统，利用持久化缓存、依赖预编译、SWC 等方法与工具，大幅降低了编译所需耗时。开发者可以自由选择切换使用 Webpack5 进行编译，也可以继续保持使用 Webpack4，另外在 v3.6 中 Taro 还将支持使用 Vite 进行编译。

依赖预编译可以预先把项目的第三方依赖打包为一个模块联邦 remote 应用，再次编译时 Webpack 无需再对这些依赖进行编译，从而提升编译速度。关于 Webpack5 编译系统的实现细节，请浏览 《Taro v3.5 beta 编译提速》

v3.5 Beta 发布后，我们补全了 H5 端的依赖预编译功能，并且把依赖预编译作为一个通用能力提取了出来。可供 Taro 以外的使用 Webpack5 的 H5 项目使用，通过 @tarojs/webpack5-prebundle 进行编译提速，具体使用方法可参考相关文档。

提速效果​

以 NutUI 组件示例库 为例，小程序、H5 端的编译速度测试结果如下：

小程序：

H5：

使用方法

简单修改 Taro 的编译配置即可切换使用 Webpack4 或 Webpack5 进行编译：

/** config/index.js */
const config = {
  // 自定义编译工具，可选 'Webpack4' 或 'Webpack5'
  compiler: 'webpack4' || 'webpack5',
}

二、RN​

1. React Native 0.68 版本支持​

React Native 0.68 版本已于 2022-3-30 正式发布。0.68 是首个可选接入 New Architecture 的版本，新架构有望为 RN 带来性能和体验上的飞跃。Taro 默认选择的 RN 版本，正式切换到了 0.68，开发者通过 taro init 选择 react-native 模板即可。

另外 0.69 版本的适配，也在进展中。

2. RN 相关依赖库由 unimodules 升级至 expo​

Expo 是 React Native 生态中的重要角色，提供了非常多优秀的模块，在 Taro 中有较为广泛的使用，如 expo-av、expo-camera 等，将来我们还会持续接入新的模块。Expo 的模块系统，由 unimodules 变更为 expo 已有一段时日，其架构变更原因可参考文章： What’s new in Expo modules infrastructure。

Taro v3.5 及以后将使用新的模块系统，后续壳工程不再包含 unimodules 版本。旧版本升级可参考此 PR，升级过程较为繁琐，建议重新 init 一个仓库，再将业务改动同步。升级为 expo 后，不再支持 iOS 11，详细内容请参考 discussions。

3. 支持把 Taro 组件编译为 React Native 组件​

如果您想在现存的 React Native 项目中(非 Taro RN )，复用您的 Taro 组件，那么这个新功能或许适合您。

您可以使用以下命令编译组件，编译后的组件产物可以直接在 React Native 项目中使用。 详细内容请参考 discussions。

taro build native-components --type rn

4. 编译打包方案优化​

Android 的打包过程，从调用 gradlew 改为使用  fastlane，将打包过程配置化，尽可能地减少对 RN 初始化后原生代码的入侵。相关配置位于  android/fastlane，目前仅做了基础配置，开发者可进一步自定义。

刚接触 Taro 开发 APP 的开发者，经常在开发环境的配置上，消耗大量时间。再次建议大家先学习利用 GitHub Action 进行打包编译，相关代码位于 .github 目录中。

5. 调试工具 Taro Playground 升级至 Taro 3.5 版本及 React Native 0.68​

Taro Playground 作为 Taro RN 端的调试工具及跨端 Demo，进行了同步更新。此次更新无法保证向下兼容，使用旧版本 Taro 的开发者，如需调试 Android，可在 releases 中下载旧包进行调试。在 App Store 中，我们只上架最新版本，需要旧版本的开发者请不要开启应用自动更新。如不慎升级，需自行打包编译，或联系我们加入测试组。

6. 壳工程代码整理​

对于 0.68 版本的壳工程，我们进行了代码的重新整理。将初始化 RN、安装 expo、兼容 Taro、安装依赖、添加 Github Action，每一个步骤一一列出，方便开发者在定制壳工程时进行参考。

三、pnpm​

众所周知，pnpm 在当下被誉为“最先进的包管理工具”，它是由 npm/yarn 衍生而来，解决了 npm/yarn 内部潜在的 bug，极大的优化了性能，扩展了使用场景。在社区内很高的呼声下，Taro 也在提供了这一热门的包管理工具选项。

在 Taro v3.5 版本以后，在脚手架内置包管理工具不再自动识别本地环境内安装的包管理工具，而是需要开发者自行选择需要的包管理工具，供开发者更方便使用和操作。

? 请选择包管理工具 (Use arrow keys)
❯ yarn
  pnpm
  npm
  cnpm

如果是在较旧的 Taro 项目中，想使用 pnpm 管理工具，由于幽灵依赖的存在，开发者需要在项目中手动安装并升级依赖来修复该问题，具体操作可参考文中升级指南第 5 项。

四、其它特性​

除了以上新特性外，v3.5 还包括很多重要的更新：

1. 适配 React 18​

从 Taro v3.5 开始，Taro 将默认使用 React 18 版本。你可以在 Taro 使用 React18 中激动人心的新特性了。从新建项目开始探索吧：

# @tarojs/cli 升级到 v3.5
$ taro init myProject
# 选择「react」框架

需要注意的是，受小程序环境限制，诸如新 Suspense 特性将不能在小程序中使用，详情请浏览文档。

2. H5 支持服务端渲染​

通过 tarojs-plugin-platform-nextjs 插件配置，我们可以将 Taro 和 nextjs 社区生态打通，让 Taro H5 支持 Pre-rendering（预渲染）、SSR（服务端渲染）和 ISR（增量静态生成）各种特性，提升页面首屏渲染速度 🚀，也利于 SEO 优化 🔍。

npm install tarojs-plugin-platform-nextjs next

在 Taro 项目的  config/index.js 中添加插件。

const config = {
  plugins: ['tarojs-plugin-platform-nextjs'],
}

启动项目。

npx taro build --type nextjs --watch

插件来自社区大佬 @SyMind 贡献，详细用法可以参考插件文档。

3. H5 支持多页应用模式​

H5 端的多页应用模式是社区呼声最高的若干特性之一，在新版本中将得到支持，详细用法及注意事项请参考文档。

配置开启多页应用模式：

/** config/index.js */
const config = {
  h5: {
    router: {
      mode: 'multi',
    },
  },
}

4. 补全对小程序生命周期方法的支持​

过去 Taro 对于小程序常用的生命周期方法支持得不够完整，新版本中将补全对应的方法与钩子。

新增 App 生命周期：

• onError（React & Vue3）

新增钩子：

• useLaunch（React）
• useError（React）
• usePageNotFound（React）
• useLoad（React & Vue3）
• useUnload（React & Vue3）
• useSaveExitState（React & Vue3）

5. 小程序内部实现优化​

对小程序的内部实现进行优化，减少约 50k 包体积，同时降低内存占用，减少 setData 发送的数据量。

五、升级指南​

1. 升级 Taro CLI​

升级全局的 Taro CLI：

npm i -g @tarojs/cli

或升级本地的 Taro CLI 工具：

npm i @tarojs/cli

2. 更新项目依赖​

如果依赖安装失败或安装成功却运行报错，可以尝试删除 node_modules、yarn.lock、package-lock.json、pnpm-lock.yaml 后重新安装依赖。

2.1 更新项目内的 Taro 相关依赖​

把 package.json 中 Taro 相关依赖的版本修改为 3.5.0 后重新安装依赖。

2.2 使用 React 的项目​

• 【Breaking】使用 React 的项目需要额外安装 @pmmmwh/react-refresh-webpack-plugin 和 react-refresh：

npm i @pmmmwh/react-refresh-webpack-plugin react-refresh --save-dev

2.3 使用 Preact 的项目​

• 【Breaking】使用 Preact 的项目需要额外安装 @prefresh/webpack 和 @prefresh/babel-plugin：

npm i @prefresh/webpack @prefresh/babel-plugin --save-dev

2.4 使用 Vue2 的项目​

• 【Breaking】使用 Vue2 的项目需要额外安装 @vue/babel-preset-jsx：

npm i @vue/babel-preset-jsx --save-dev

2.5 使用 Vue3 的项目​

• 【Breaking】使用 Vue3 的项目需要额外安装 @vue/babel-plugin-jsx：

npm i @vue/babel-plugin-jsx --save-dev

3. 使用 Webpack5​

开发者需要先卸载 @tarojs/mini-runner 和 @tarojs/webpack-runner：

npm uninstall @tarojs/mini-runner @tarojs/webpack-runner

然后安装 @tarojs/webpack5-runner：

npm install @tarojs/webpack5-runner

最后修改 Taro 编译配置即可：

/** config/index.js */
const config = {
  compiler: 'webpack5',
}

4. 使用 React 18​

需要更新 react、react-dom、@types/react 的版本：

npm i react react-dom

npm i @types/react --save-dev

5. 使用 pnpm​

因为 pnpm 不允许幽灵依赖的存在，因此开发者需要在项目中手动安装下列依赖：

dependencies 补充依赖：

"@tarojs/helper": "3.5.0",
"@tarojs/plugin-platform-weapp": "3.5.0",
"@tarojs/plugin-platform-alipay": "3.5.0",
"@tarojs/plugin-platform-tt": "3.5.0",
"@tarojs/plugin-platform-swan": "3.5.0",
"@tarojs/plugin-platform-jd": "3.5.0",
"@tarojs/plugin-platform-qq": "3.5.0",
"@tarojs/router": "3.5.0",
"@tarojs/shared": "3.5.0",
"@tarojs/taro-h5": "3.5.0",

devDependencies 补充依赖：

安装项目对应的 Webpack 版本，如 Webpack5：

"webpack": "^5.73.0"

六、最后​

下半年 Taro 团队的核心将围绕以下各方向展开：

• 支持使用 Vite 进行编译（预计 Q3 推出 alpha 版本）
• 小程序方面将持续对性能进行优化、支持更多的 React/Vue 特性（如 Portal）和生态库（如 React/Vue Router）。
• H5 方面将输出适配 Vue3 的 SSR 方案。
• RN 方面将深入探索高阶功能，如地图、动画、2D 及 3D 图形方案，并推出跨端可视化库，提升 Taro 跨端能力。
• 此外还会探索对于 Flutter 的适配。

最后的最后，衷心感谢参与社区共建与交流的各位同学！上半年我们制定了开发者贡献制度，建立起规范的项目分工与有效的荣誉激励机制。未来 Taro 将积极探寻更中立与开放的开源治理机制，欢迎各位开发者参与到 Taro 社区的建设中~

同时，Taro v3.5 还带来了兼容 React 18、H5 MPA 等新特性，欢迎各位同学升级试用~

一、编译提速​

为了改善编译性能，Taro 主要做了以下事情：

• 支持 Webpack5
• 基于模块联邦的依赖预编译
• 支持使用 esbuild 压缩 JS，使用 esbuild 或 @parcel/css 压缩 CSS
• 使用 @swc/register 代替 @babel/register

接下来将简单聊聊 Webpack5 与依赖预编译，关于编译提速的完整实现细节请参阅 RFC 文档。

1. Webpack5​

Webpack5 发布已有两年时间，功能足够稳定，同时其持久化缓存、模块联邦、更优的 Tree Shaking 等特性都为项目的编译流程提供了更好的解决方案。

其中的持久化缓存功能是最重要的特性之一，能极大提升再次编译时的速度。但同时也引入了如何使缓存失效的问题。

Taro 遵循 Webpack “编译安全比编译速度重要” 的理念，默认不开启持久化缓存。当开发者设计好缓存策略后，强烈建议开启持久化缓存。详细配置请参考 mini.cache。

2. 依赖预编译​

Webpack5 另一个重要的特性要数模块联邦（Module Federation）。受 UmiJS mfsu 特性的启发，可以预先把项目的 node_modules 依赖打包为一个模块联邦 remote 应用，再次编译时 Webpack 则无需再对依赖进行编译，从而提升编译速度。

依赖预编译可以分为三步：

1. 收集依赖
2. 打包依赖
3. 打包 Module Federation Remote 应用

Taro 参考 Vite 使用了 esbuild 收集用户使用到的第三方依赖，并分别进行打包。打包后的模块会作为 Webpack 的 entry，最终打包为模块联邦 Remote 应用，供主应用（Host）消费。实现细节请参考 RFC 文档。

Taro 会在小程序环境的 dev 模式下默认开启依赖预编译功能。首次编译时，因为使用了 esbuild 打包第三方依赖，所以会比普通编译稍快。二次编译时，Taro 能直接复用 Remote App，Webpack 只需编译业务代码，因此根据不同项目会有不同的编译提速效果。

依赖预编译的流程图：

3. 提速效果​

以 NutUI 组件示例库为例，分别测试 dev 与 prod 环境下编译微信小程序的编译提速效果：

可以看出：

1. 在 dev 环境下因为 Taro 默认开启了依赖预编译，因此 Webpack5 首次编译速度比 Webpack4 稍快。而 prod 环境没有默认开启依赖预编译，因此两者速度相当（而且 Webpack5 需要写入缓存，可能会比 Webpack4 稍慢）。
2. 无论是 dev 还是 prod 环境，在完全命中缓存的最优情况下，Webpack5 的编译速度都能得到极大提升。即使是修改源码导致了部分缓存失效时，编译速度仍然比首次编译快得多。

4. 使用​

旧项目升级后需要安装 Webpack5 的相关依赖才能正常编译，详情请参考下文的【升级指南】部分。

简单修改 Taro 的编译配置即可开启 Webpack5、持久化缓存、依赖预编译等功能：

/** config/index.js */
const config = {
  // 自定义编译工具，可选 'Webpack4' 或 'Webpack5'
  compiler: {
    type: 'webpack5',
    // 依赖预编译配置
    prebundle: {
      enable: true,
    },
  },
  // 持久化缓存配置
  cache: {
    enable: true,
  },
}

二、兼容 React18​

React 官方正式发布了 react v18 版本，带来了 Automatic Batching、Transitions 和 Concurrent 等诸多新特性，提升了 React 性能。Taro 也在第一时间完成了对 React18 的兼容。

React 目前存在两种工作模式：legacy 和 concurrent 。在 concurrent 模式下，会使用 New Client API 来渲染组件。

不要忘记将项目的 react 版本升级到 v18 哦

详细内容请参考 React 18

三、支持服务端渲染（SSR）​

1. 动机​

与 SPA（单页应用程序，Single-Page Application）相比，服务器端渲染（SSR）能带来带来更快的首屏渲染速度和更好的 SEO，因此 SSR 功能是大家期望 Taro 支持的特性之一。

2. 实现原理​

Taro 在 3.1 版本提出了开放式架构的思想，让开发者可以通过编写插件来让 Taro 支持一个新的平台。

通过 Taro 插件，将 React 生态中知名的 Next.js 框架作为 Taro 的一个新的目标平台，以此让 Taro 能够支持服务端渲染（SSR）。

目前这个插件项目的地址位于：SyMind/tarojs-plugin-platform-nextjs

⚠️  插件目前处于早期建设中，不建议用于生产环境！

3. 安装与使用​

安装插件和 Next.js 框架。

# 使用 npm 安装插件与 next.js
npm install tarojs-plugin-platform-nextjs next

# 使用 pnpm 安装插件与 next.js
pnpm install tarojs-plugin-platform-nextjs next

在 Taro 项目的编译配置中添加本插件。

const config = {
  plugins: [
    'tarojs-plugin-platform-nextjs'
  ]
}

开始尝试它吧！

npx taro build --type nextjs --watch

四、支持多页应用（MPA）​

很多同学通过阅读 Taro 的源码发现，Taro 曾在 1.x 支持过多页面应用，通过配置 multi 模式就可以开启该特性，但是由于并没有很好支持，也没有相应的业务场景测试，最终并没有在文档中呈现。

在 2.x 发布时，由于各种原因我们回滚了该特性，尽管开发者们依旧可以通过插件或者在项目内自定义 webpack 配置实现类似的需求，不过这依旧会在一些细节上难以处理得尽善尽美。比如需要额外配置文件拆分规则避免冗余的代码，对于 MPA 也并不需要taro-router提供对于路由相关的事件方法的支持……

MPA 是不少社区开发者所追求的重要特性之一，为此我们改写了 taro-loader 和 taro-router 以适应该模式的个性化需求，应用该模式也只需要如下配置：

module.exports = {
  // ...
  h5: {
    // ...
    router: {
      mode: 'multi',
    },
  },
}

需要注意的是，有很多小程序事件和方法都是基于 SPA 模式设计使用的，在 MPA 模式并不适用，所以会存在一些问题，比如由于多页面导致 TabBar 会重复加载，App 级的生命周期会重复触发，不支持路由动画，生产环也需要额外配置路由映射等等，开启该模式前需要认真考量适用场景。

五、RN 相关依赖库由 unimodules 升级至 expo​

Expo 是 React Native 生态中的重要角色，提供了非常多优秀的模块，在 Taro 中有较为广泛的使用，如 expo-av、expo-camera 等，将来我们还会持续接入新的模块。Expo 的模块系统，由 unimodules 变更为 expo 已有一段时日，其架构变更原因可参考文章： What’s new in Expo modules infrastructure。

Taro v3.5 及以后将使用新的模块系统，可以通过 taro init 选择 react-native 模板体验。如果你使用的是 Taro 壳工程，可切换到 0.67.0-expo 分支体验。

新老版本的 Taro 及壳工程之间混用的话，将存在不兼容情况，主要原因是存在多个版本原生依赖导致，可通过 resolution 进行版本锁定解决，相应版本参考此处。

后续壳的工程将不再包含 unimodules 版本。旧版本升级可参考此PR。

注意：升级为 expo 将不再支持 iOS 11，详细内容请参考 discussions。

六、升级指南​

1. 安装 v3.5.0-beta 的 CLI 工具：

npm i -g @tarojs/cli@beta

2. 更新项目依赖

如果安装失败或打开项目失败，可以删除 node_modules、yarn.lock、package-lock.json 后重新安装依赖再尝试。

2.1 把 package.json 文件中 Taro 相关依赖的版本修改为 3.5.0@beta

2.2 Breakings

• Vue2 项目需要添加 devDenpendencies："@vue/babel-preset-jsx": "^1.2.4”

• Vue3 项目需要添加 devDenpendencies："@vue/babel-plugin-jsx": "^1.0.6"

• React 项目需要添加 devDenpendencies：

  "@pmmmwh/react-refresh-webpack-plugin": "0.5.4",
  "react-refresh": "0.11.0"
  

• Preact 项目需要添加 devDenpendencies：

  ```jsx
  "@prefresh/webpack": "^3.2.3",
  "@prefresh/babel-plugin": "^0.4.1"
  ```
  

  2.3 重新安装依赖