背景
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?. === .) {
. = ;
(.);
. = -;
}
})
.({ : ., : , : [], : . });
