华为的鸿蒙系统自发布以来，便广受关注。它支持 JavaScript 编写应用的特性，对于前端开发者来说意义非凡。跨端解决方案Rax的团队也于8月份开始与HarmonyOS JS UI框架团队合作，旨在支持使用Rax编写HarmonyOS应用。经过几个月的实践之后，他们决定将内部细节的技术实现带到第十六届 D2 的舞台上与大家分享，让我们人手都能开发一款属于自己的 HarmonyOS 应用。

附：第十六届D2前端技术论坛分享回放

关于跨端解决方案 Rax

1、为什么会有跨端

在PC场景中，业务面对的是浏览器，针对性能的操作很有限，同时容器也是固定的。但是，在无线场景中之所以会出现各种端容器有以下三个原因：

• 设备&网络差异大带来的性能问题：典型场景比如淘特这种面向下沉用户，会更关注性能问题；
  
• App容器层给了可能性：在无线端可以在容器层做更多定制能力；
  
• 大厂商的超级App生态：尤其在微信结合小程序成功打造自身生态后，更多大流量App也都纷纷基于小程序建设，因此小程序就成为一个必须选择的端。
  

在以上三方面的背景下，就引发了无线跨端的复杂问题。

2、跨端背景下需要什么样的技术方案？

跨端背景下的技术方案有2个思路：

• 一码多端：开发一套代码可以运行在多个端；
  
• 各写一套：每个端开发一套代码，常见的手机应用就是使用这种方案；
  

下图中通过研发成本、适配成本、功能一致、招聘成本这四个维度对两种方案进行对比。

a. 研发成本：一码多端只需要开发一套代码显然成本会低； 

b. 适配成本：由于不同端的适配非常复杂，一码多端的成本就会随之升高；

c. 功能一致：即业务逻辑的一致性，一码多端由于只有一套代码易于保障功能一致性，各写一套则比较难保障，比如常见的一个功能在Android可以使用但iOS不能；

d. 招聘成本：一码多端只专注一种代码，相对人员的学习成本也较低。

基于以上对比，大前端或大体量的业务模式基本会选择一码多端的方式。一些有特别需求的场景比如交易场景，由于对稳定性的要求比较高，就会选择各写一套的模式。

3、社区中一码多端的方案 

Rax、Remax、uni-app、Taro等。

4、Rax是一个怎样的跨端方案？ 

Rax使用React语法编写Web应用，并且提供上层配套工程框架体系。在跨端能力方面，Rax支持Web、各厂商小程序、Weex等不同端。目前Rax服务手淘内 80% 以上的业务，Rax核心服务于阿里整体无线业务体系。

当 Rax 遇到鸿蒙系统

1、关于鸿蒙系统

鸿蒙系统是华为自研开发的国产操作系统，整体装机量突破1.5亿。目前鸿蒙系统采用兼容安卓的模式，但在未来，鸿蒙有机会跟安卓、iOS三足鼎立。鸿蒙系统支持使用JavaScript开发系统应用，这是安卓或iOS都很难触达的。

鸿蒙系统的架构分层

2、鸿蒙系统与跨端的结合

如下表所示，鸿蒙系统上端提供两种应用开发的解决方案：Java和JavaScript。Java开发在未来主要是支持JavaScript的开发。JavaScript提供两种模式：类Web范式和声明式，前者更多会面向大前端生态，而后者更多会面向客户端的开发。鸿蒙系统将JavaScript作为应用开发的一等公民，因此，Rax X鸿蒙具备理论可能性。

3、业务的诉求

a. 单独开发一个鸿蒙应用 由于目前鸿蒙系统提供安卓兼容模式，对于业务来说，单独开发一套针对鸿蒙的应用系统成本过高，不具备普适性；

b. 开发一个有流量入口的服务卡片 服务卡片是鸿蒙系统主推的能力，鸿蒙会分发公域流量给业务使用，有效解决业务层面流量不足的问题，十分符合业务需求。因此，开发一个有流量入口的服务卡片成为阿里以及很多公司的业务场景。

鸿蒙服务卡片示例

4、技术方案

业务在技术层面的问题，首先是上面提到的单独开发一套应用的成本太高，另外，新技术太多已经学不动了，而使用Rax去开发鸿蒙应用的优势包括：

• 使用类React语法开发，不需要学习新的语法；
  
• 一套代码多个端，降低开发成本；
  
• 开发链路上可以更好的结合Web生态；
  

技术原理：Rax 如何对接鸿蒙应用

Rax对接鸿蒙方案分三部分内容：渲染能力、工程构建和研发链路。

1、多端渲染

a. VDOM的跨端能力 

VDOM的核心特点是标准的数据结构，可以跟具体的端解耦，进而更好的支持跨端渲染；另外，抽象一层标准数据结构能更有机会做到数据驱动UI的编程范式。

b. Rax Driver适配器 

在Rax中利用VDOM进行多端渲染的核心是Rax Driver适配器模式。在与端耦合的逻辑中，都会抽象一个Driver，因此会有面向浏览器的driver-dom、面向WEEX的driver-weex，以及小程序中的driver等。

下图中是driver interface的定义，声明与端绑定的方法，然后结合端的能力实现api。

c. Rax Driver生态 

在Rax Driver生态中有面向WebView的driver-web，面向Node.js的driver-server，面向小程序的driver-miniapp。右图是一个简单的driver-server的demo，可以看到在server端明确的driver和端解耦。

d. 对接方案 

鸿蒙官方提供的类Web开发范式是拆分了三个文件（见下图）：index.hml，index.css和index.js，写法与小程序/Vue非常类似。

在这个背景下形成Rax对接鸿蒙系统的三个基本思路：

• 语法编译
  

• • 逻辑：输入Rax语法，借助Babel工具进行语法编译，最终生成小程序 语法；
    
  • 缺点：实现成本高，语法约束多；
    

• 类小程序运行时
  

• • 逻辑：用上层Rax框架对接set data进行模板渲染；
    
  • 优点：实现周期短；
    
  • 缺点：运行时复杂度高，性能劣化；
    

• 对接鸿蒙底层渲染指令
  

• • 逻辑：Rax直接对接下层鸿蒙渲染指令创建节点；
    
  • 优点：运行时轻量、高性能；
    
  • 缺点：实现周期较长，需要对鸿蒙底层进行改造；
    

e. driver-harmony 

下面左图为技术方案设计，最下面两层渲染引擎和JS Framework是鸿蒙提供的核心能力；上面三层是代码层，包含：driver-harmony、Rax Core和业务代码。其中核心部分是driver-harmony对接JS Framework的渲染指令，鸿蒙在JS Framework中提供跟浏览器标准类似的API，在driver中调用API完成节点渲染。右图是一个简单的demo，由于API与浏览器API存在差异，需要一些磨平操作。

在实现driver后就可以实现demo链路的跑通，如下图，左边是鸿蒙页面的一个组件，在这个组件中需要在生命周期onReady里面调用rax render再传入对应的driver-harmony，就可以实现在真机调试上渲染出Rax节点。

2、工程构建

a. 工程配置 

在Rax面向多端的设计中有一个targets，支持web、miniapp等不同的端，当鸿蒙进来后targets只需要加一个harmony，然后再加入一个工程插件来处理鸿蒙应用构建的体系和webpack配置的体系。下图是配置多页面静态结构。

b. 多webpack任务

跨端方案的核心工程问题是构建多个端的代码，多端的构建可能存在差异，webpack的配置也会有所不同，因此在Rax工程体系中引用了多webpack任务的设计。它的执行逻辑是，先加载用户配置读取targets，注册webpack任务后改写webpack配置，最终通过webpack编译生成不同端的产物。

c. Plugin-rax-harmony 

在上述基础上，就可以轻松的创建plugin-rax-harmony工程插件。通过这个工程插件可以： 

• 注册独立的webpack任务为harmony产物的构建；
  
• 定制webpack配置；
  
• 生成鸿蒙产物；
  

3、研发链路

a. 方案设计 

鸿蒙官方提供了DevEco Studio IDE支持应用的全链路开发调试与打包。

IDE自身已经形成一个闭环，Rax的工程链路如何对接成为核心的问题。

• 短期方案 在短期方案中会保留鸿蒙IDE本身提供的能力（下图蓝色框流程），同时重新创建一个Rax项目，生成webpack.dev.server，将Rax产物打包放入鸿蒙src中，src继续IDE链路即可。
  

• 长期方案 支持在DevEco Studio从 Rax 应用创建 -> 开发 -> 调试 -> 发布的全链路研发能力。目前这个方案还在和鸿蒙的团队在讨论之中。
  

（研发链路演示见视频）

附：Rax与鸿蒙的合作Roadmap

2021年8月：Rax团队和鸿蒙团队第一次会议交流；

2021年10月：结合鸿蒙提供的渲染指令跑通demo； 

2021年12月：完成渲染链路的完整对接；与鸿蒙IDE团队沟通全链路方案；

2022年2月：IDE全链路流程开发完成；Rax 相关组件&API适配完成； 

2022年3月：结合Harmony 3.0正式发布。 

Rax对接鸿蒙的技术方案选择了相对性能优越、运行轻量的长期方案，预计在2022年3月结合鸿蒙Harmony3.0一起正式发布。