鸿蒙端H5容器化建设——JSB通信机制建设

1. 背景

2023年鸿蒙开发者大会上，华为宣布为了应对国外技术封锁的潜在风险，2024年的HarmonyOS NEXT版本中将不再兼容Android，并推出鸿蒙系统以及其自研的开发框架，形成开发生态闭环。同时，在更高维度上华为希望将鸿蒙系统拓展应用到手机、智能穿戴、车机、家居等一系列物联网设备上，形成万物互联的品牌生态闭环。

基于以上背景，鸿蒙端上APP的适配问题是开发者不得不面对的问题，适配也将从原生和跨端两个方面进行。鸿蒙原生ArkTs包含的内容可以对标Android原生，既多又杂，可以参考官方文档；跨端则涉及H5、RN、Flutter的鸿蒙化适配。由于目前产品的跨端重心在H5，因此本文将主要介绍鸿蒙端H5容器化的适配工作，同时简述鸿蒙系统框架以及开发模式。

2. 鸿蒙系统架构

HarmonyOS整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。可以看出，已经了抛离AOSP和JVM，去除了对Android依赖。

内核层

采用多内核设计，提供进程/线程管理、内存管理、文件系统、网络管理和外设管理等基础内核能力。驱动子系统HDF提供统一外设访问能力和驱动开发管理框架。

系统服务层

包括适用于各类设备的基础能力以及面向特定设备的专有能力，每个子系统内部支持按功能粒度裁剪。

框架层

为应用开发提供Java/C/C++/JS等多语言的用户程序框架，以及各种软硬件服务对外开放的多语言框架API。

应用层

支持基于框架层实现业务功能开发，支持跨设备调度与分发，为用户提供一致、高效的应用体验。

3. 鸿蒙开发模式

开发工具DevEco-Studio

开发工具下载地址：HUAWEI DevEco Studio和SDK下载和升级 | HarmonyOS开发者，和Android Studio的功能和设计大体一致，工程结构也有诸多相似之处。但是仅处于起步阶段，各种问题还需要完善和解决，诸如模拟器H5页面无法交互、以及各种调试问题等。

开发语言与UI框架

ArkTs是华为基于TypeScript的自研开发语言。ArkUI 是一套声明式开发框架，它具备简洁自然的 UI 信息语法、丰富的 UI 组件、多维状态管理，以及实时多维度预览等能力，只需使用一套ArkTS API，就能在多个HarmonyOS设备上提供生动而流畅的用户界面体验，帮助开发者提升应用开发效率。

编译模式

ArkCompiler利用ArkTS的静态类型信息，进行类型推导并生成对象描述和内联缓存，加速运行时对字节码的解释执行；AOT（Ahead-of-Time）Compiler利用静态类型信息直接将字节码编译生成优化机器码，让应用启动即可运行高性能代码，提升应用启动和运行性能。

APP包结构

APP由一个或多个HAP（Harmony Ability Package）包以及描述APP属性的pack.info文件组成。HAP是Abiltiy类型的模块编译后的产物，而Library类型的模块编译后的产物为HAR（静态共享包）或者HSP（动态共享包），两者都是为了实现代码和资源的共享。HAR中的代码和资源跟随使用方编译，多个使用方会存在多份拷贝，而HSP中的代码和资源可以独立编译，运行时在同一进程中仅有一份，从而避免包膨胀问题。

4. 适配工作

原生业务

目前项目中，Native原始业务与H5跨端业务并存，基于Native的业务在新的鸿蒙系统上将无法运行，为了兼顾用户体验问题，只能使用ArkTS进行重写。这将是一个繁杂且漫长的适配工程，需要明确App核心功能，在初期版本上优先适配核心业务能力。

H5业务

鸿蒙提供了H5页面运行所需的Web容器，H5页面是可以百分百复用的。但是H5侧依赖Native能力的各种API需要额外做定制和适配，从而实现真正的H5容器化SDK，这将是优先级极高的适配工作。其中，H5与Native之间的通信机制建设则是重中之重的适配内容。

5. H5容器化建设——JSB通信机制建设

ArkTS侧与H5的通信机制是首先要解决的问题，有了JSB的桥，才有后续Native能力支撑的可能。JSB通信总体可以分为四个步骤来进行：

5.1 JSBridge初始化

在初始化阶段，需要通过webviewControll.runJavaScript()将JSBridge初始化脚本注入H5执行。脚本代码如下所示。其中callID用来标识H5回调；JSBridgeCallback方法用来执行H5侧回调；window.ohosCallNative对象给H5侧提供调用函数。

export const code = `
  const JSBridgeMap = {};
  let callID = 0;
  
  // 执行H5回调函数
  function JSBridgeCallback (id, params) {
    JSBridgeMap[id](params);
    JSBridgeMap[id] = null;
    delete JSBridgeMap[id];
  }
  // 在window中声明callNative方法供H5调用
  window.ohosCallNative = {
    callNative(method, params, callback) {
      const id = callID++;
      const paramsObj = {
          callID: id,
          data: params || null
      }
      JSBridgeMap[id] = callback || (() => {});
      JSBridgeHandle.call(method, JSON.stringify(paramsObj));
    }
  }
`;

5.2 JS代理注入

通过Web组件的javaScriptProxy属性，将JSBridgeHandle对象注册到H5侧的window上，作为H5调用原生的通道。

// JsBridge.ets
export default class JsBridge {
  controller: WebView.WebviewController;
  constructor(controller: WebView.WebviewController) {
    this.controller = controller;
  }
  /**
   * 注入JavaScript对象到window对象中  
   */
  get javaScriptProxy(): JavaScriptItem {
    return {
      object: {
        call: this.call
      },
      name: "JSBridgeHandle",
      methodList: ['call'],
      controller: this.controller
    } as JavaScriptItem;
  }
  
   initJsBridge(): void {
    this.controller.runJavaScript(code);
  }
}
// PageDemo.ets
@Entry
@Component
struct PageDemo {
  webController: WebView.WebviewController = new WebView.WebviewController();
  private jsBridge: JSBridge = new JSBridge(this.webController);
  build() {
    Column() {
      Web({
        src: $rawfile('MainPage.html'),
        controller: this.webController
      })
        .javaScriptAccess(true)
        .javaScriptProxy(this.jsBridge.javaScriptProxy)
        .onPageBegin(() => {
          this.jsBridge.initJsBridge();
        })
        ...
    }
    ...
  }
}
/**
 * javaScriptProxy object type.
 */
export interface callType {
  call: (func: string, params: string) => void
}
export interface JavaScriptItem {
  object: callType,
  name: string,
  methodList: Array,
  controller: WebviewController
}

5.3 H5侧入口与回调

H5侧调用ohosCallNative对象中的callNative方法，传递func、params以及callback回调。在callNative中保存callback回调，并调用JSBridgeHandle的call方法。call方法作为H5调用原生侧接口的统一入口，在该方法中根据H5调用的方法名，匹配到对应的接口后调用，调用结束后通过this.callback()方法，将调用结果回传到H5。

// JsBridge.ets
export default class JsBridge {
  /**
   * 将ArkTS侧数据传递给call方法
   */
  call = (func: string, params: string): void => {
    const paramsObject: ParamsItem = JSON.parse(params);
    let result: Promise = new Promise((resolve) => resolve(''));
    switch (func) {
      case 'funName':
        result = "result from ArkTS";
        break;
      default:
        break;
    }
    result.then((data: string) => {
      this.callback(paramsObject?.callID, data);
    })
  }
  /**
   * 将ArkTS侧数据传递到H5
   */
  callback = (id: number, data: string): void => {
    this.controller.runJavaScript(`JSBridgeCallback("${id}", ${JSON.stringify(data)})`);
  }
}
/**
 * Function params object.
 */
export interface ParamsItem {
  callID: number
}

5.4 H5侧主动发起调用ArkTS

实现了上述桥接逻辑后，在H5侧只需要调用ohosCallNative方法，将函数名以及回调函数传递到ArkTS。

  window.ohosCallNative.callNative('funName', {}, (data) => {
    ...
  });

6. 总结

本文概述了鸿蒙系统的架构以及开发模式，并且指出鸿蒙的适配工作任重而道远。其中，Native侧的迁移适配需要大量的时间和成本；而H5作为天然的跨端生态，尤其是在业务中本来就有很重的业务承载，那么H5容器化是首先要去适配的。ArkTS与H5的JSB通信机制则是本文的重点描述内容，剩下的H5容器所需的Native能力，则需要一点一点去补齐。