鸿蒙 Web 容器五·完结闭环回传、容器治理兼谈 AtomicServiceEnhancedWeb这是「ArkWeb / JSBridge」系列的第 5 篇对应 demo 提交 5ArkTS通过runJavaScript回调H5容器治理。前四步H5 嵌进来了 → 协议定好了 → H5 能调到 ArkTS → ArkTS 能按 action 分发到能力。只差最后一步——把结果送回 H5闭环就成了。再顺手把 Web 容器的基本治理补齐。一、回传ArkTS 怎么「回拨」给 H5H5 调 ArkTS 用的是javaScriptProxy注入window.ascfBridge。反方向 ArkTS 调 H5用的是另一把钥匙——controller.runJavaScript在 H5 的上下文里执行一段 JS。约定 H5 暴露一个全局函数window.__ascfOnResponseArkTS 处理完就去调它把响应当参数传进去privatesendBack(respJson:string):void{constargJSON.stringify(respJson);// JSON 串再 stringify → 合法的 JS 字符串字面量this.controller.runJavaScript(if(window.__ascfOnResponse){window.__ascfOnResponse(arg);});}H5 这头接住、解析、显示window.__ascfOnResponsefunction(jsonStr){varrespJSON.parse(jsonStr);showResult(resp);// 把结果画到「最近结果」区};注意那个JSON.stringify(respJson)respJson 本身已经是 JSON 字符串要把它作为实参塞进一段 JS 代码必须再stringify一次变成带引号、转义好的 JS 字符串字面量否则字符串里的引号会把代码拼坏也是一种注入风险。二、一个隐蔽的坑别在「接电话」时反向「打电话」H5 调ascfBridge.send是JS → ArkTS这通调用还在栈上、JS 引擎正等着send返回。如果我在send里直接runJavaScriptArkTS → JS就是趁 JS 引擎被占着的时候反向闯进去——可能重入、卡住。解法很简单把回传推到下一拍执行让send先返回、JS 引擎先空出来setTimeout((){if(openToast)this.onToast(msg);// 真实 Toast 副作用this.sendBack(respJson);// 回传 H5},0);这类「同步回调里别反向重入」的坑在桥/事件系统里很常见记一笔。三、闭环长这样四段日志对上号点一次「获取设备信息」完整链路是① H5 发出H5 日志→ascfBridge.send② ArkTS 收到ArkTS 面板→WebBridgeChannel.send记请求③ 分发 返回ArkTS 面板的↩→BridgeDispatcher按 action 取设备信息、包成BridgeResponse④ H5 收到结果H5 日志 「最近结果」→runJavaScript回拨__ascfOnResponseopenToast还会多一个真实鸿蒙 Toast弹出来——那是 ArkTS 用页面的UIContext.getPromptAction().showToast干的H5 碰不到系统 Toast必须由原生这头代劳。这就是「前端要能力、底座给能力」最直白的样子。四、容器治理壳子得「管」起来光能跑通还不够一个生产级 Web 容器还得管这些标准 Web 都给了回调我们逐个接上加载生命周期onPageBegin / onProgressChange / onTitleReceive / onPageEnd进度条、标题、状态。资源错误 / HTTP 错误onErrorReceive只认主文档滤掉 favicon 噪音、onHttpErrorReceive拿getResponseCode。白名单拦截onLoadIntercept里看 URL——非 http(s)本地资源一律放行http(s) 只放行白名单其余拦截。点那个「尝试打开外部链接」按钮会被挡下并在顶部亮出 已拦截…。这是 Web 容器最基本的安全闸离线包/域名管控都从这儿起步。五、那 AtomicServiceEnhancedWeb 到底增强了什么整个系列我用的是标准Web因为要自己掌控双向桥javaScriptProxy/runJavaScript。那工程里那个AtomicServiceEnhancedWeb强在哪翻它的类型定义差别很清楚标准WebAtomicServiceEnhancedWeb双向桥原语有javaScriptProxy/runJavaScript没有controller 只有 loadUrl/refresh/前进后退…容器治理回调有但要自己一个个接同款回调开箱即用progress/title/error/httpError/loadIntercept…与元服务集成自己处理内置darkMode/forceDarkAccess/safeArea/navPathStack和元服务的暗色/沉浸式/导航栈集成H5→ArkTS自定义javaScriptProxy走onMessage H5postMessage通道一句话选型要「在元服务里塞一个治理完善、和系统集成好的 Web 壳」——用AtomicServiceEnhancedWeb省心要「自己定义一套双向 JSBridge 协议、掌控每一帧通信」——用标准WebjavaScriptProxy/runJavaScript灵活。我们这个 demo 的重点是「把桥的机制吃透」所以选了后者。系列总结五步回看把一个 H5 接进鸿蒙、并能和原生双向通信本质是五件事① 用Web把 H5 嵌进来② 先定死BridgeRequest/Response协议id配对、action当能力名③javaScriptProxy让 H5 调到 ArkTS④ 分发器按action找底座能力、统一包响应⑤runJavaScript把结果回拨 H5再补上加载/错误/白名单这些容器治理。这正是「小程序/元服务」那套「前端只认 API、底座按 action 给能力」的最小可运行复刻。