JSAPI、NAPI、Biz、ImpASCF Demo 如何真正调用系统能力和 C 能力前面讲了 H5 怎么进 ArkTS也讲了 ArkTS 怎么回调 H5。但是还有一个关键问题ArkTS 收到请求之后怎么真正调用 OpenHarmony 系统能力甚至 C Native 能力在 MyASCF 里我做了两类能力clipboard.writeText / clipboard.readText native.addByNapi / native.getNativeVersion前者验证 JSAPI / 系统能力。后者验证 NAPI / C Native 能力。一、为什么要有 Biz / Imp如果只做 Demo可以把所有逻辑写在 handler 里。比如clipboard.writeText handler ↓ 直接调用 pasteboard但是这不适合框架。框架要考虑扩展。所以我把能力拆成两层Biz ↓ ImpBiz负责业务语义clipboard.writeText 是写入剪贴板。 native.addByNapi 是通过 NAPI 调 C 求和。Imp负责具体实现ClipboardImp 调 pasteboard。 NativeImp 调 C native module。这样拆以后调用链路变成Register ↓ Biz ↓ Imp ↓ 系统 API / NAPI二、clipboard.writeText调用 OpenHarmony 系统剪贴板H5 发起请求window.ascf.send(clipboard.writeText,{text:hello ASCF})完整链路是H5 ↓ JavaScriptProxy ↓ BridgeController ↓ BridgeDispatcher ↓ HandlerRegister ↓ ClipboardBiz.writeText ↓ ClipboardImp.writeText ↓ OpenHarmony pasteboard API ↓ BridgeResponse ↓ runJavaScript ↓ H5 Promise resolve这里最关键的是ClipboardImp ↓ OpenHarmony pasteboard API这说明 H5 最终确实通过 ArkTS 调到了系统能力。但是 H5 没有直接调系统 API。它只是发了一个 actionclipboard.writeText真正接触系统能力的是ClipboardImp。三、JSAPI 是什么在这篇文章里可以把 JSAPI 先理解成ArkTS / JS 调用 OpenHarmony 系统能力的接口。比如剪贴板、设备信息、文件、位置、网络等能力。以 pasteboard 为例它属于系统剪贴板能力。所以这条线可以写成ArkTS ↓ JSAPI ↓ OpenHarmony 系统能力在 MyASCF 里就是ClipboardImp ↓ pasteboard注意它不是 H5 的浏览器 Clipboard API。它是 OpenHarmony / HarmonyOS 提供的系统能力。四、native.addByNapi调用 C 求和另一个能力是native.addByNapiH5 发起window.ascf.send(native.addByNapi,{a:7,b:5})完整链路是H5 ↓ JavaScriptProxy ↓ BridgeController ↓ BridgeDispatcher ↓ HandlerRegister ↓ NativeBiz.addByNapi ↓ NativeImp.addByNapi ↓ NAPI ↓ C add(a, b) ↓ 返回 12 ↓ BridgeResponse ↓ runJavaScript ↓ H5 Promise resolve这个能力的重点不是加法。重点是验证ArkTS 可以通过 NAPI 调 C Native 模块。五、NAPI 是什么NAPI也叫 Node-API可以先理解成ArkTS / JS 和 C/C 之间的桥。它不是 H5 直接调 C 的桥。这句话很重要H5 不能直接调用 NAPI。正确链路是H5 ↓ JavaScriptProxy ↓ ArkTS ↓ NAPI ↓ C所以在 MyASCF 里真正调用 NAPI 的是NativeImp不是 H5。六、JSAPI 和 NAPI 的区别这两个词很容易混。可以这样记JSAPI ArkTS / JS 调 OpenHarmony 系统能力。 NAPI ArkTS / JS 调 C Native 能力。对应 Democlipboard.writeText ↓ ClipboardImp ↓ JSAPI / pasteboard ↓ OpenHarmony 系统剪贴板 native.addByNapi ↓ NativeImp ↓ NAPI ↓ C add(a, b)一句话JSAPI 面向系统能力 NAPI 面向 C/C 扩展能力。七、为什么不让 H5 直接调用 NAPI因为 H5 运行在 WebView 页面环境里。它能执行页面 JS但不能直接 import HarmonyOS native.so模块。如果让 H5 直接接触 C也会带来安全和边界问题。所以更合理的链路是H5 只发请求 ArkTS 做校验和分发 Biz 解释语义 Imp 调用真实能力这就是框架的价值。H5 不需要知道底层到底是 pasteboard还是 C还是别的系统 API。它只需要知道action clipboard.writeText action native.addByNapi八、错误处理也应该在框架层统一比如 H5 发了错误参数window.ascf.send(native.addByNapi,{a:7,b:5})NativeBiz应该做参数校验。如果参数不合法返回{requestId:req_001,code:400,message:native.addByNapi requires number params.a and params.b,data:{}}如果 action 没注册Dispatcher 返回{requestId:req_001,code:404,message:UNKNOWN_ACTION: unknown.action,data:{action:unknown.action}}如果系统能力调用失败返回{requestId:req_001,code:500,message:Handler execute failed,data:{action:clipboard.readText}}这样 H5 只需要处理统一的 response。九、这套分层带来的好处拆成 Biz / Imp 之后有几个好处。第一H5 不依赖底层实现。H5 只知道 action不关心 pasteboard 或 C。第二Controller 不关心具体能力。Controller 只解析协议不写业务。第三Register 只维护映射。action → handler第四Biz 负责参数和业务语义。native.addByNapi 必须有 number 类型的 a 和 b。第五Imp 负责真实能力调用。ClipboardImp 调 pasteboard。 NativeImp 调 NAPI。这样项目会更像框架而不是功能堆砌。十、总结这一篇主要讲两条能力链路clipboard.writeText ↓ JSAPI / pasteboard ↓ OpenHarmony 系统能力和native.addByNapi ↓ NAPI ↓ C Native 模块它们共同说明一件事H5 不直接调用系统能力也不直接调用 C。 H5 只通过 JavaScriptProxy 把请求交给 ArkTS。 ArkTS 通过 Controller / Dispatcher / Register / Biz / Imp 把请求送到真正的能力实现层。 最后再通过 runJavaScript 把结果回调给 H5。这就是 MyASCF 目前最核心的学习价值。参考资料ArkWeb 前端页面调用应用侧函数JavaScriptProxy / registerJavaScriptProxyhttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/web-in-page-app-function-invokingArkWeb 应用侧调用前端页面函数runJavaScript / runJavaScriptExthttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/web-in-app-frontend-page-function-invokingWebviewController API 参考https://developer.huawei.com/consumer/en/doc/harmonyos-references/arkts-apis-webview-webviewcontrollerpasteboard 剪贴板 APIhttps://developer.huawei.com/consumer/cn/doc/harmonyos-references/js-apis-pasteboardNode-API / NAPIhttps://developer.huawei.com/consumer/en/doc/harmonyos-references-V14/napi-V14IPC / RPC 开发指导https://developer.huawei.com/consumer/en/doc/harmonyos-guides/ipc-rpc-development-guidelineJSVM API 参考https://developer.huawei.com/consumer/cn/doc/harmonyos-references-V5/_j_s_v_m-V5
JSAPI、NAPI、Biz、Imp：ASCF Demo 如何真正调用系统能力和 C++ 能力
JSAPI、NAPI、Biz、ImpASCF Demo 如何真正调用系统能力和 C 能力前面讲了 H5 怎么进 ArkTS也讲了 ArkTS 怎么回调 H5。但是还有一个关键问题ArkTS 收到请求之后怎么真正调用 OpenHarmony 系统能力甚至 C Native 能力在 MyASCF 里我做了两类能力clipboard.writeText / clipboard.readText native.addByNapi / native.getNativeVersion前者验证 JSAPI / 系统能力。后者验证 NAPI / C Native 能力。一、为什么要有 Biz / Imp如果只做 Demo可以把所有逻辑写在 handler 里。比如clipboard.writeText handler ↓ 直接调用 pasteboard但是这不适合框架。框架要考虑扩展。所以我把能力拆成两层Biz ↓ ImpBiz负责业务语义clipboard.writeText 是写入剪贴板。 native.addByNapi 是通过 NAPI 调 C 求和。Imp负责具体实现ClipboardImp 调 pasteboard。 NativeImp 调 C native module。这样拆以后调用链路变成Register ↓ Biz ↓ Imp ↓ 系统 API / NAPI二、clipboard.writeText调用 OpenHarmony 系统剪贴板H5 发起请求window.ascf.send(clipboard.writeText,{text:hello ASCF})完整链路是H5 ↓ JavaScriptProxy ↓ BridgeController ↓ BridgeDispatcher ↓ HandlerRegister ↓ ClipboardBiz.writeText ↓ ClipboardImp.writeText ↓ OpenHarmony pasteboard API ↓ BridgeResponse ↓ runJavaScript ↓ H5 Promise resolve这里最关键的是ClipboardImp ↓ OpenHarmony pasteboard API这说明 H5 最终确实通过 ArkTS 调到了系统能力。但是 H5 没有直接调系统 API。它只是发了一个 actionclipboard.writeText真正接触系统能力的是ClipboardImp。三、JSAPI 是什么在这篇文章里可以把 JSAPI 先理解成ArkTS / JS 调用 OpenHarmony 系统能力的接口。比如剪贴板、设备信息、文件、位置、网络等能力。以 pasteboard 为例它属于系统剪贴板能力。所以这条线可以写成ArkTS ↓ JSAPI ↓ OpenHarmony 系统能力在 MyASCF 里就是ClipboardImp ↓ pasteboard注意它不是 H5 的浏览器 Clipboard API。它是 OpenHarmony / HarmonyOS 提供的系统能力。四、native.addByNapi调用 C 求和另一个能力是native.addByNapiH5 发起window.ascf.send(native.addByNapi,{a:7,b:5})完整链路是H5 ↓ JavaScriptProxy ↓ BridgeController ↓ BridgeDispatcher ↓ HandlerRegister ↓ NativeBiz.addByNapi ↓ NativeImp.addByNapi ↓ NAPI ↓ C add(a, b) ↓ 返回 12 ↓ BridgeResponse ↓ runJavaScript ↓ H5 Promise resolve这个能力的重点不是加法。重点是验证ArkTS 可以通过 NAPI 调 C Native 模块。五、NAPI 是什么NAPI也叫 Node-API可以先理解成ArkTS / JS 和 C/C 之间的桥。它不是 H5 直接调 C 的桥。这句话很重要H5 不能直接调用 NAPI。正确链路是H5 ↓ JavaScriptProxy ↓ ArkTS ↓ NAPI ↓ C所以在 MyASCF 里真正调用 NAPI 的是NativeImp不是 H5。六、JSAPI 和 NAPI 的区别这两个词很容易混。可以这样记JSAPI ArkTS / JS 调 OpenHarmony 系统能力。 NAPI ArkTS / JS 调 C Native 能力。对应 Democlipboard.writeText ↓ ClipboardImp ↓ JSAPI / pasteboard ↓ OpenHarmony 系统剪贴板 native.addByNapi ↓ NativeImp ↓ NAPI ↓ C add(a, b)一句话JSAPI 面向系统能力 NAPI 面向 C/C 扩展能力。七、为什么不让 H5 直接调用 NAPI因为 H5 运行在 WebView 页面环境里。它能执行页面 JS但不能直接 import HarmonyOS native.so模块。如果让 H5 直接接触 C也会带来安全和边界问题。所以更合理的链路是H5 只发请求 ArkTS 做校验和分发 Biz 解释语义 Imp 调用真实能力这就是框架的价值。H5 不需要知道底层到底是 pasteboard还是 C还是别的系统 API。它只需要知道action clipboard.writeText action native.addByNapi八、错误处理也应该在框架层统一比如 H5 发了错误参数window.ascf.send(native.addByNapi,{a:7,b:5})NativeBiz应该做参数校验。如果参数不合法返回{requestId:req_001,code:400,message:native.addByNapi requires number params.a and params.b,data:{}}如果 action 没注册Dispatcher 返回{requestId:req_001,code:404,message:UNKNOWN_ACTION: unknown.action,data:{action:unknown.action}}如果系统能力调用失败返回{requestId:req_001,code:500,message:Handler execute failed,data:{action:clipboard.readText}}这样 H5 只需要处理统一的 response。九、这套分层带来的好处拆成 Biz / Imp 之后有几个好处。第一H5 不依赖底层实现。H5 只知道 action不关心 pasteboard 或 C。第二Controller 不关心具体能力。Controller 只解析协议不写业务。第三Register 只维护映射。action → handler第四Biz 负责参数和业务语义。native.addByNapi 必须有 number 类型的 a 和 b。第五Imp 负责真实能力调用。ClipboardImp 调 pasteboard。 NativeImp 调 NAPI。这样项目会更像框架而不是功能堆砌。十、总结这一篇主要讲两条能力链路clipboard.writeText ↓ JSAPI / pasteboard ↓ OpenHarmony 系统能力和native.addByNapi ↓ NAPI ↓ C Native 模块它们共同说明一件事H5 不直接调用系统能力也不直接调用 C。 H5 只通过 JavaScriptProxy 把请求交给 ArkTS。 ArkTS 通过 Controller / Dispatcher / Register / Biz / Imp 把请求送到真正的能力实现层。 最后再通过 runJavaScript 把结果回调给 H5。这就是 MyASCF 目前最核心的学习价值。参考资料ArkWeb 前端页面调用应用侧函数JavaScriptProxy / registerJavaScriptProxyhttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/web-in-page-app-function-invokingArkWeb 应用侧调用前端页面函数runJavaScript / runJavaScriptExthttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/web-in-app-frontend-page-function-invokingWebviewController API 参考https://developer.huawei.com/consumer/en/doc/harmonyos-references/arkts-apis-webview-webviewcontrollerpasteboard 剪贴板 APIhttps://developer.huawei.com/consumer/cn/doc/harmonyos-references/js-apis-pasteboardNode-API / NAPIhttps://developer.huawei.com/consumer/en/doc/harmonyos-references-V14/napi-V14IPC / RPC 开发指导https://developer.huawei.com/consumer/en/doc/harmonyos-guides/ipc-rpc-development-guidelineJSVM API 参考https://developer.huawei.com/consumer/cn/doc/harmonyos-references-V5/_j_s_v_m-V5
