背景
Hybrid 应用夹在 Web 应用和系统应用之间,优势很直接:界面和业务可以沿用 Web 的开发方式,关键交互又能拿到接近原生的体验。它的核心还是那套老路子——Native 通过 JSBridge 暴露统一 API,界面用 Html/CSS,逻辑用 JS,最后在 WebView 里渲染。
这类方案迁到 ArkWeb 时,通常会先碰到几个问题:架构怎么拆、JSBridge 怎么设计、哪些 JS 侧 API 要鸿蒙化、哪些组件适合直接改成 ArkTS 实现。下面只聊前半段,也就是 Hybrid 鸿蒙化、双端通信和 API 鸿蒙化。组件鸿蒙化、视频适配、跨域和 Web 组件拦截能力,留到后面再展开。
Hybrid 应用鸿蒙化方案
整体架构
Hybrid 鸿蒙化方案可以拆成三个部分:Ark 进程、Webview 进程和 JSBridge。
Ark 进程
- 由 ArkTS 运行时承载,负责调用系统 API
- 应用从 Ark 进程启动,完成 EntryAbility 初始化并创建 HarmonyOS 页面
- 可以动态或静态创建 WebView 运行时环境,加载 html/css/js 资源
Webview 进程
- 默认只提供标准 W3C API,对 ArkTS 侧资源的访问是有限的
- 主要渲染能力来自 Web 组件
- 可以通过组件属性控制是否开启同层渲染、是否允许执行 JavaScript
JSBridge
- 负责 Ark 进程和 Webview 进程之间的双向通信
- Webview 侧通过这条通道访问扩展 API
方案设计
鸿蒙化这件事,实际落点通常就三块:
- 双端通信的 JSBridge
- 面向 JS 侧平台能力的 HarmonyOS 版本 API
- 基于同层渲染的原生组件替代方案
这三块不是平行关系。先把通信打通,再看哪些 API 必须补,最后再决定哪些组件值得迁成 ArkTS。顺序反过来,后面基本都会返工。
业务实现中的关键点
实现时通常围绕这三件事展开:
- 双端通信:JS 侧和 ArkTS 侧的通道,是鸿蒙化的起点
- API 鸿蒙化:把 JS 侧依赖的平台能力换成 HarmonyOS 实现
- 组件鸿蒙化:对性能要求高、交互复杂的 Web 组件,用同层渲染或原生组件替代
双端通信(JSBridge)
JSBridge 是 Webview 进程和 ArkUI 主进程之间的桥,做的是双向通信。HarmonyOS 提供了 Web 组件以及 @ohos.web.webview 这一套 ArkWeb API,常见做法是通过 WebMessagePort 和 javaScriptProxy 实现 JSBridge。
WebMessagePort
WebMessagePort 本质上是比较底层的消息通道,只支持 string 和 ArrayBuffer 这类消息类型。
问题也很明显:业务消息怎么封、怎么拆、怎么定协议,都得自己来。能做,但上手不算轻松,后期维护也更依赖约定。
JavaScriptProxy 代理
javaScriptProxy 的思路更直接:把 ArkUI 主进程里的对象注入到 Webview 中,比如命名成 native,然后在 window 上生成一个代理对象。Web 侧直接调用这个对象的方法,最终会落到 ArkUI 主进程对应的实现上。
Web({ src: .., : . })
.()
.(.)
.()
.({ : ., : ., : . })
.( {
(event?..() === ) {
.().().({ : $r(), : . });
}
(event?..() === ) {
.().().({ : $r(), : . });
}
})
.( {
(event?. === .) {
. = ;
(.);
. = -;
}
})
.({ : ., : , : [], : . });

