ArkUI-X跨平台技术落地-华为运动健康(二)

原生和ArkUI界面参数传递

在原生页面拉起对应的跨平台的页面时，会将代表拉起哪个页面的参数通过intent的形式传递给跨平台的Entry模块，这里主要用到的是intent的putExtra()方法进行设置，Entry模块收到该参数之后，解析参数从而决定拉起的页面，一个简单的示意图如下所示：

ArkUI-X与原生之间的bridge桥接通信

ArkUI-X SDK 提供了一种bridge通信方案，用于跨平台层和宿主Native之间进行相互通信，使得跨平台层可以调用原生的能力。运动健康应用使用bridge的简单示意图如图所示：

在运动健康内部，有5个bridge，用于跨平台层与native之间进行通信：

1.数据平台的bridge -- 负责跨平台业务层 和 数据平台之间交互的接口定义；

2.设备类的bridge -- 负责上层业务层 和 设备能力之间的交互（目前由于ArkUI-X SDK的蓝牙能力并非跨平台的，所以使用接口抽象不同平台的设备的交互）；

3.页面跳转的bridge -- 负责从ArkUI的页面跳转到 H5的页面（在鸿蒙NEXT系统当中，运动健康跳转的是NEXT系统的H5页面，而在Android和iOS当中，运动健康跳转的是原生的H5页面）；

4.日志类的bridge -- 负责将日志打印到对应的原生应用的日志文件当中；

5.用户账户信息的bridge --负责向上层业务层提供获取原生App账户信息的能力。

这些bridge的创建时机均为跨平台Entry模块初始化之时。为了使上层调用bridge方法的时候，像调用ts原生方法一样方便，在应用工程内部，我们在ArkUI-X SDK的基础上对bridge的调用进行了一层封装，方法的核心代码如下所示：

/**
  * 执行Native接口
  * @param moduleName native模块名
  * @param funcName native函数名
  * @param params 参数列表
  */
public execNativeAsync(moduleName: string, funName: string, ...params: any): Promise<any> {
    return this.wrapFunc(moduleName, funcName, ...params);
}

private wrapFunc(moduleName: string, funcName: string, ...params: any): Promise<void> {
    return new Promise((resolve, reject) => {
        const id = mgr.add({
            success: (data) => {
                resolve(this.parseResult(data));
            },
            fail: (errCode, errMsg) => {
                reject({ errCode, errMsg });
            }
        });
        // 指定bridge类型和方法名即可进行调用对应的bridge方法
        console.log(`${TAG} call method: ${moduleName}/${funcName}`);
        if (params.length) {
            this.getModule(moduleName).callMethod(funcName, id, ...params);
        } else {
            this.getModule(moduleName).callMethod(funcName, id);
        }
    });
}

在本方法中，对调用层屏蔽了变量id，变量id由mgr来进行管理，调用方在调用bridge方法的时候，只需要指定bridge的类型和对应的bridge方法名，即可像调用原生ts方法一样调用bridge方法。

平台差异化处理—动态编译脚本

由于不同操作系统之间的数据平台差异等客观原因，需要做到一套业务代码在鸿蒙NEXT系统、Android 和 iOS上面同步运行，在尽可能不修改业务代码的前提下屏蔽三端数据平台的差异，结合运动健康NEXT系统当前的代码现状，运动健康使用了编译前动态修改import的技术方案：根据接口的形式抽象数据平台的功能，利用编译前动态import的方式来根据宿主形态来确定调用的具体方法。具体方案如下：

1.在鸿蒙Next系统上，我们的业务代码依赖了鸿蒙Next系统的原生能力，我们将该原生能力包称为A包；与此同时，我们开发跨平台场景包，为了描述方便，我们将这个包命名为B包，B包的接口形式与数据结构跟A包保持一致，但是B包的内部实现与A包的实现不同（B包主要是跨平台包，内部实现为跨平台桥接）。

2.将上层业务对A包的依赖导入收编到一个文件内（对A包的数据结构和接口进行import 和 export，通过该形式实现依赖中转），我们在这里将文件命名为import-sdk.ts，举个简单的示例：

import { xxx } from ‘a-sdk’ // A包是鸿蒙Next系统原生能力包

修改为：

import { xxx } from ‘import-sdk’// import-sdk.ts 是包名统一收编包

其中，import-sdk.ts文件的简单示例如下所示：

import {
  HealthModel, // A包的数据结构
  healthInterface // A包的接口方法
} from 'a-sdk'; // A包

export {
  HealthModel,
  healthInterface
};

与此同时，创建B包的收编导入文件，其内容与import-sdk.ts有差异，差异为引入包的路径，代码如下所示：

import {
  HealthModel, // B包的数据结构
  healthInterface // B包的接口方法
} from 'b-sdk'; // B包

export {
  HealthModel,
  healthInterface
};

3.在编译前，按照编译目标替换收编导入文件，例如编译跨平台版本时，将import-sdk.ts替换为B包的收编导入文件。如果是编译鸿蒙Next系统的hap包，则不需要替换。由于之前对A包和B包的依赖统一收编到import-sdk.ts，所以只需要替换一个文件，即可以实现全局依赖替换。

性能指标

目前ArkUI-X跨平台页面整体静态指标为： • 滑动帧率为：60fps（达到满帧） • 包体积增加：二进制包增加19MB • 内存数据：内存与原生持平（或略高），具体表格数据如下所示：

整体实现效果

总结

通过引入ArkUI-X技术，使得华为运动健康应用三端平台复用健康模块代码，从而在三端交互一致的前提下提升开发效率以及代码复用率（目前代码复用率为74.3%，提升研发效率30%），并且用户体验追平原生native页面的体验效果。后续规划，运动健康应用内部更多高频使用的页面和模块（如单次运动模块、运动记录页面等）也会逐渐迁移到ArkUI-X跨平台框架上。