IPC、JSVM、UIThread、libuv:ASCF 架构图里最容易混的几个词
IPC、JSVM、UIThread、libuvASCF 架构图里最容易混的几个词前面两篇讲的是应用层链路H5 ↓ JavaScriptProxy ↓ ArkTS ↓ Biz / Imp ↓ runJavaScript ↓ H5这条线跑通之后再看架构图里的这些词Main Process RenderProcess Service Thread Main Thread UI Thread JSVM IPC libuv run in就会发现它们不是和Controller / Biz / Imp同一层的东西。它们更多是在解释这条调用链背后的运行时环境是什么样的一、先纠正一个误解渲染进程也会执行 JS很容易误解成H5 页面不执行 JS等逻辑层 JSVM 执行。这是错的。H5 页面里的 JavaScript 当然会执行。比如button.onclickfunction(){}window.ascf.send()window.__ascfResolve()Promise.resolve()document.body.innerHTML...这些都属于页面侧 JavaScript。它们运行在RenderProcess ↓ UI Thread ↓ H5 / JavaScript所以渲染进程不是只画页面它也会执行页面 JS。二、那 JSVM 又是什么JSVM 可以先简单理解成逻辑层 JavaScript 的执行引擎。在小程序式架构里常见会把运行环境拆成两层UI 层 负责页面渲染、用户点击、DOM 更新。 逻辑层 负责业务逻辑、状态管理、生命周期、能力调度。H5 页面里的 JS 属于 UI 层。Service Thread 里的 JSVM 更偏逻辑层。所以应该区分两套 JS 环境H5 JavaScript 页面侧 JS负责点击、DOM、Promise、页面更新。 Service JSVM 逻辑侧 JS负责业务逻辑、框架运行时、能力调度。JSVM 不是JavaScriptProxy。JSVM 也不是runJavaScript。它是执行 JS 的引擎环境。三、Main Process 和 RenderProcess架构图里通常会分成两个进程Main Process RenderProcess可以先这样理解RenderProcess WebView 渲染进程负责 H5 页面、页面 JavaScript、UIThread、DOM 更新。 Main Process 应用/逻辑主进程负责 ArkTS、ArkWeb 控制、Controller、Dispatcher、Biz、Imp、系统能力调用。更直观一点用户点按钮 ↓ RenderProcess / UIThread / H5 JS 先执行 需要调用系统能力 ↓ 通过桥发给 Main Process Main Process 处理完成 ↓ 通过 runJavaScript 回到 RenderProcess H5 页面更新所以不是一个进程把所有事情都做了。四、IPC进程之间通信IPC 是Inter-Process Communication 进程间通信它解决的问题是两个进程之间怎么传消息如果 H5 在 RenderProcessArkTS 能力调度在 Main Process那么它们不能像普通函数调用一样共享变量。所以底层需要 IPC。在业务代码里你一般不会直接写 IPC。你写的是JavaScriptProxy runJavaScript底层跨进程消息传递由 ArkWeb / 系统框架处理。所以可以这样记JavaScriptProxy / runJavaScript 开发者能看到的桥。 IPC 桥底下跨进程传消息的机制。IPC 不是 Controller也不是 Biz也不是 JavaScriptProxy 本身。它是更底层的通信机制。五、逻辑上双线程通信是不是 IPC不完全是。“逻辑上双线程通信”是架构描述。它强调UI 层和逻辑层分开执行 它们不在同一个普通函数调用栈里 它们通过消息协作。IPC 是具体机制之一。如果 UI 层和逻辑层跨进程那么底层会涉及 IPC。但是不能简单说逻辑上双线程通信 IPC更准确是逻辑上双线程通信 UI 层和逻辑层分离执行。 IPC 当这种分离跨越进程边界时用来传消息的底层机制。六、Service Thread 和 Main Thread在 Main Process 内部图里可能还有两个线程Service Thread Main Thread可以先这样理解Service Thread 逻辑层执行线程里面可能有 JSVM负责业务逻辑和框架运行时。 Main Thread 应用主线程里面有 ArkWeb、API 调用入口、UI/生命周期相关任务。这两个线程之间也需要通信。图里如果写libuv它表达的是Service Thread ↔ Main Thread 的线程通信 / 事件调度机制。不要把它和 IPC 混在一起。线程间通信Service Thread ↔ Main Thread 进程间通信Main Process ↔ RenderProcess这是两个层级。七、libuv 是什么位置在这张架构图里libuv 不是你业务代码里直接调用的 API。它更像运行时内部的事件循环 / 线程通信基础设施。你可以先把它记成Main Process 内部Service Thread 和 Main Thread 之间协作的一种运行时机制。在 MyASCF 这种应用层 Demo 里我们不会手写 libuv。我们能做的是在文档里解释它的位置Service Thread ↔ libuv Main Thread真正写代码时我们关注的是JavaScriptProxy Controller / Dispatcher / Register Biz / Imp runJavaScript八、run in 是什么意思图里有时会写run in Main Process run in RenderProcess这里的run in不是 API。它只是英文运行在……例如Service run in Main Process意思是Service 运行在主进程里。H5 run in RenderProcess意思是H5 运行在渲染进程里。不要把run in当成函数名。九、把这些概念放回一次调用里现在再看一次 H5 调用RenderProcess / UIThread ↓ H5 页面 JS 执行 button.onclick ↓ window.ascfBridge.send(rawReq) ↓ JavaScriptProxy 底层可能跨进程IPC Main Process ↓ ArkTS / Controller / Dispatcher / Biz / Imp ↓ 系统 API / NAPI / C 返回时可能跨进程IPC runJavaScript ↓ RenderProcess / UIThread ↓ window.__ascfResolve(response) ↓ Promise resolve ↓ DOM 更新这样就清楚了H5 JS 在 RenderProcess 执行。 ArkTS 能力调度在 Main Process 执行。 两边通过桥通信。 底层跨进程时需要 IPC。 逻辑层可能有 JSVM。 Main Process 内部线程协作可能涉及 libuv。十、MyASCF 覆盖了什么没有覆盖什么MyASCF 已经覆盖H5 页面 H5 JavaScript JavaScriptProxy BridgeController BridgeDispatcher HandlerRegister Biz Imp JSAPI / pasteboard NAPI / C runJavaScript Promise resolve / rejectMyASCF 没有手写覆盖真实 IPC 真实 RenderProcess 管理 JSVM 初始化 libuv 线程通信 ArkWeb 内部调度这不是问题。因为 MyASCF 的定位是应用层 ASCF 调用链路复现 Demo不是ASCF 运行时内核复现十一、总结这篇只记住几个对应关系RenderProcess / UIThread 执行 H5 页面和页面 JavaScript。 Main Process 执行 ArkTS 侧桥接、分发、能力调用。 JSVM 逻辑层 JavaScript 执行引擎不等于 JavaScriptProxy。 IPC Main Process 和 RenderProcess 之间的底层通信机制。 libuv Main Process 内部 Service Thread 和 Main Thread 之间的线程通信 / 事件调度机制。 JavaScriptProxy H5 → ArkTS。 runJavaScript ArkTS → H5。理解这些之后再看 ASCF 双线程 / 双进程通信图就不会把所有箭头都理解成一个东西。参考资料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