鸿蒙 Web 容器四ArkTS 拿到请求后怎么「按 action 找能力」这是「ArkWeb / JSBridge」系列的第 4 篇对应 demo 提交 4新增BridgeDispatcher按action分发到模拟底座能力。上一步ArkTS 已经能收到 H5 发来的BridgeRequest了但只是「记了一笔」。这一步让它真去干活根据action找到对应能力、执行、把结果包成统一的BridgeResponse。一、类比分发器就是「政务大厅前台」你去政务大厅办事不会直接冲进某个科室而是先到前台说「我要办身份证」。前台按业务名在名册里一查把你指到对应窗口窗口办完给你一张统一格式的回执。桥的这一层就是这个前台叫BridgeDispatcherH5 报一个业务名actiongetDeviceInfo/getCurrentTime/openToast分发器按 action 找到对应能力实现办完把结果统一包成BridgeResponse成功/失败一个格式。dispatch(req:BridgeRequest):BridgeResponse{try{if(req.actionBridgeAction.GET_DEVICE_INFO)returnok(req.id,biz.getDeviceInfo());if(req.actionBridgeAction.GET_CURRENT_TIME)returnok(req.id,biz.getCurrentTime());if(req.actionBridgeAction.OPEN_TOAST)returnok(req.id,biz.openToast(msg));returnfail(req.id,404,未知 action: req.action);// 名册里没有}catch(e){returnfail(req.id,500,能力执行出错);// 窗口办砸了}}这正是小程序的运行机制H5 写wx.getSystemInfo()小程序宿主收到后按这个 API 名去找它的底座实现。我们这里把「宿主按 API 名分发」这件事用BridgeDispatcher亲手复刻了一遍。二、能力实现分两层和 demo 其他切片一样具体能力没有都堆在分发器里而是照 demo 一贯的分层拆成 Biz / ImpNativeAbilityImp实现层真去调系统能力。getDeviceInfo读deviceInfo.brand / productModel / osFullNamegetCurrentTime读Date。它扮演的就是「ASCF 里 C/NDK 底座」的角色——前端只认 action底座具体怎么实现读系统、调 NDK归这层。NativeAbilityBiz业务层编排 Imp。现在多是透传但它是预留「参数校验 / 数据加工 / 多能力组合」的地方。// Imp真正读底座能力readDeviceInfo():Recordstring,string{return{brand:deviceInfo.brand,model:deviceInfo.productModel,osVersion:deviceInfo.osFullName};}openToast是「效果」类能力真弹出需要页面的UIContext这层拿不到所以本步先回执一个 mock下一步在页面层接真实 Toast。三、为什么「统一返回结构」这么重要不管成功、未知 action、还是执行炸了回的都是同一个形状BridgeResponse { id, code, message, data }成功 →code: 0data没这个能力 →code: 404执行异常 →code: 500try/catch兜住绝不让一个能力的崩溃把整座桥带塌。H5 那头就能用一套逻辑处理所有结果看code判断成败不用为每个 action 写不同的解析。桥的健壮性一半靠这个「不管怎样都给一张格式统一的回执」。四、现在能看到什么WebBridgeChannel.send在记完请求后多了一步dispatcher.dispatch(req)并把响应也记进账本。所以页面底部那条日志状态会从「待处理」翻成「完成」下面多出一行↩开头的响应 JSON——点「获取设备信息」你会看到真实的设备品牌/型号被 ArkTS 取出来、包成BridgeResponse记了下来。只差最后一步把它送回 H5。一句话总结分发器像政务大厅前台H5 报业务名action它按名册找到对应能力NativeAbilityImp扮演底座、Biz做编排办完统一包成BridgeResponse——成功、未知、异常都是同一个形状try/catch保证一个能力崩了不连累整座桥。这就是小程序「按 API 名分发到底座」的核心。下一步把这张回执真正回传给 H5闭环就成了。
