浅谈鸿蒙 JavaScript GUI 技术栈

作者：doodlewind
链接：https://juejin.im/post/6872154561574862855

众所周知，刚刚开源的「鸿蒙 2.0」以 javascript 作为 iot 应用开发的框架语言。这标志着继 spacex 上天之后，javascript 再一次蹭到了新闻联播级的热点。这么好的机会，只拿来阴阳怪气实在太可惜了。作为科普，这篇文章不会拿着放大镜找出代码中的槽点来吹毛求疵，而是希望通俗地讲清楚它所支持的 gui 到底是怎么一回事。只要对计算机基础有个大概的了解，应该就不会对本文有阅读上的障碍。

我们已经知道在「鸿蒙 2.0」上，开发者只需编写形如 vue 组件式的 javascript 业务逻辑，即可将其渲染为智能手表等嵌入式硬件上的 ui 界面。这个过程中需要涉及哪些核心的模块呢？这些模块中又有哪些属于自研，哪些使用了现成的开源项目呢？这里将其分为自上而下的三个抽象层来介绍：

• js 框架层，可理解为一个大幅简化的 vue 式 javascript 框架
• js 引擎与运行时层，可理解为一个大幅简化的 webkit 式运行时
• 图形渲染层，可理解为一个大幅简化的 skia 式图形绘制库

这三个抽象层，整体构成了一套面向嵌入式硬件的 gui 技术栈。不同于许多高呼「不明觉厉 / 深不可测」的舆论，个人认为至少对于 gui 部分，国内凡是接触过目前主流 hybrid 式跨端方案或 js 运行时研发的一线开发者，都很容易从源码出发来理解它。下面逐层对其做一些解读和分析。

js 框架层

从最顶层的视角出发，要想用「鸿蒙 2.0」渲染出一段动态的文本，你只需要编写如下的 hml（类 xml）格式代码：

<!-- hello.hml -->
<text onclick="boil">{{hello}}</text>

然后在同级目录编写这样的 javascript：

// hello.js
export default {
 data: {
 hello: 'ppt'
 },
 boil() {
 this.hello = '核武器';
 }
}

这样只要点击文本，就会调用 boil 方法，让 ppt 变成 核武器。

这背后发生了什么呢？熟悉 vue 2.0 的同学应该会立刻联想到下面这几件事：

• 需要对 xml 的预处理机制，将其转换为 js 中的嵌套函数结构。这样只需在运行时做一次简单 eval ，即可用 js 生成符合 xml 结构的 ui。
• 需要事件机制，使得触发 onclick 事件时能执行相应回调。
• 需要数据劫持机制，使得对 this.hello 赋值时能执行相应回调。
• 需要能在回调中更新 ui 对象控件。

这几件事分别是怎么实现的呢？简单说来是这样的：

• xml 预处理依赖现成的 npm 开源包，从而把 xml 中的 onclick 属性转换为 js 对象的属性字段。
• 事件的注册和触发都直接由 c++ 实现。如上一步所获得的 js 对象 onclick 属性会在 c++ 中被检查和注册，相当于全部组件均为原生。
• 数据劫持机制用 js 实现，是个基于 object.defineproperty 的（几百行量级的）viewmodel。
• ui 控件的更新，会在 viewmodel 自动执行的 js 回调中，调用 c++ 的原生方法实现。这部分完全隐式完成，并未开放 document.createelement 式的标准化 api。

由于大量常见 js 框架中的能力都直接做进了 c++，所以整套 gui 技术栈里用纯 javascript 所实现的东西（主要见 ace_lite_jsfwk 仓库下的 core/index.js、observer.js 和 subject.js），相当于有且只有这么一个功能：

一个可以 watch 的 viewmodel。

至于纯 js 框架部分的实现复杂度和质量，客观地说如果是个人业余作品，可以当作校招面试中不错的加分项。

js 引擎与运行时层

理解了 js 框架层之后，我们既可以认为「鸿蒙 2.0」选择把高度简化后的 vue 深度定制进了 c++ 里，也可以认为它紧密围绕着高度简化（且私有）的 dom 实现了配套的前端框架。因此要想继续探索这套 gui 的原理，我们就必须进入其 c++ 部分，了解其 js 引擎与运行时层的实现。

js 引擎和运行时之间，有什么区别与联系呢？js 引擎一般只需符合 ecma-262 规范，其中没有对任何带「副作用」的平台 api 的定义。从 settimeout 到 document.getelementbyid 到 console.log 再到 fs.readfile，这些能执行实际 io 操作的功能，都需要由「将引擎 api 和平台 api 胶合到一起」的运行时提供。运行时本身的原理并不复杂，譬如在个人的文章《从 js 引擎到 js 运行时》中，你就可以看到如何借助现成的quickjs 引擎，自己搭建一个运行时。

那么在「鸿蒙 2.0」中，js 运行时是如何搭建出来的呢？有这么几条重点：

• js 引擎选择了 jerryscript，这是一款由三星开发的嵌入式 js 引擎。
• 每种形如 <text> 和 <div> 的 xml 标签组件，都对应一个绑定到 jerryscript 上的 c++ component 类，如 textcomponent 和 divcomponent 等。
• 除 ui 原生对象外，还有一系列在 js 中以 @system 为前缀的 built-in 模块，它们提供了 js 中可用的 router / audio / file 等平台能力（参见 ohos_module_config.h）。

这里特别值得一提的是 router。它和 vue-router 等常见 web 平台路由的实现原理有很大区别，是专门在运行时内深度定制的（参见 router_module.cpp、js_router.cpp 和 js_page_state_machine.cpp）。简单说来这个「路由」是这样实现的：

• 在 js 中调用切换页面的 router.replace 原生方法，走进 c++。
• c++ 中根据新页面 uri 路径（如 pages/detail）加载新页面 js，新建页面状态机实例，将其切换至 init 状态。
• 在新状态机的 init 过程中，调用 js 引擎去 eval 新页面的 js 代码，获得新页面的 viewmodel。
• 将路由参数附加到 viewmodel 上，销毁旧状态机及其上的 js 对象。

所以我们可以发现，这里所谓的「切换路由」，其实更接近 web 浏览器的「刷新页面」。那么我们可以认为这个 js 运行时的能力，已经可以对标 webkit 级的浏览器内核了吗？

当然还差得很远。与 webkit 相比，它并未支持对 html 和 css 的解析（二者都会在开发阶段被解析转换成同等执行效果的 js），也没有浏览器中持续动态加载、解析与执行资源的挑战（小程序不外乎是几个本地的静态 js 文件）。至于排版布局和渲染方面自然也有很大差距，这点会在最后一节提及。

另外，相信很多同学都会对 jerryscript 引擎感到好奇。本部分最后分享一些个人对此所掌握的消息。

jerryscript 引擎是一款专为嵌入式硬件实现的 js 解释器，只支持到 es5.1 标准。在 quickjs benchmark 中，可以查看到它们的性能对比结果：

可以看到论性能，jerryscript 在无 jit 的引擎中大幅弱于 quickjs 和 hermes。如果和开启了 jit 的 v8 相比，甚至会慢出两个数量级。因此这是非常特定于低端设备的引擎，如果需要支持 react 和 vue 这类中大型前端项目中标配的基础库（甚至其相应全家桶），仍然可能需要使用更强大的引擎。

对于 jerryscript 的使用，有同场景重度应用经验的当属 rt-thread 创始人 ，他们和某国内一线厂商合作研发的智能手表就用 jerryscript 实现了 ui，目前产品马上就要上市了。他们团队对 jerryscript 的一些使用反馈也吻合上述评价，概括说来是这样的：

• jerryscript 在体积和内存占用上，相比 quickjs 有更好的表现。
• jerryscript 的稳定性弱于 quickjs，有一些难以绕过的问题。
• jerryscript 面对稍大（1m 以上）的 js 代码库，就有些力不从心了。

那么师出名门的 quickjs 和 facebook 的 hermes，是否就是无 jit 式 js 引擎的下一代标杆了吗？倒也未必如此。这方面可以参考个人的知乎回答：随着 typescript 继续普及，会不会出现直接跑 typescript 的运行时？这里提到的微软为教育项目 makecode 研发的 static typescript，就相当有潜力成为下一代的高性能 js 系语言环境。通过限定 typescript 的静态强类型子集并为其搭建工具链，sts 可以做到无需 jit 也能接近 v8 的性能水平，同时内存占用比 v8 少两个数量级。这使得 sts 不光能用于开发普通 app 这类 io 密集的应用，还能顺利在嵌入式硬件上开发小游戏这类更偏计算密集（需逐帧更新渲染）的应用，在工程能力上是一项很大的突破。

所以说，当「鸿蒙 2.0」还需要熟练开发者勉强搭建出环境跑通 hello world 时，微软已经让上百万小朋友都能用 typescript 在网页里给教学用的掌上游戏机写小游戏入门编程了。这里没什么唱反调的意思，只希望提醒一下我们在为国产「里程碑」欢呼时，也要清醒地看到业界前沿的动向，仅此而已。

图形绘制层

理解 js 运行时之后，还剩最后一个问题，即 js 运行时中的各种 component 对象，是如何被绘制为手表等设备上的像素的呢？

这就涉及「鸿蒙 2.0」中的另一个 graphic_lite 仓库了。可以认为，这里才是真正执行实际绘制的 gui。像之前的 textcomponent 等原生组件，都会对应到这里的某种图形库 view。它以一种相当经典的方式，在 c++ 层实现并提供了「canvas 风格的立即模式 gui」和「dom 风格的保留模式 gui」两套 api 体系（对于立即模式和保留模式 gui 的区别与联系，可参见个人这篇imgui 科普回答）。概括说来，这个图形子系统的要点大致如下：

• 图形库提供了 uiview 这个 c++ 控件基类，其中有一系列形如 onclick / onlongpress / ondrag 的虚函数。基本每种 js 中可用的原生 component 类，都对应于一种 uiview 的子类。
• 除了各种定制化 view 之外，它还开放了一系列形如 drawline / drawcurve / drawtext 等命令式的绘制方法。
• 这个图形库具备名为 gfx 的 gpu 加速模块，但它目前似乎只有象征性的 fillarea 矩形单色填充能力。

在基础 ui 控件方面，不难找到一些值得一提的自研模块特性：

• 支持了简易的 recycleview 长列表。
• 支持了简易的 flex 布局。
• 支持了内部的 invalidate 脏标记更新机制。

至于 2d ui 渲染中的几项关键能力，则基本可分为路径、位图和文字三类。这个图形库在这几个方面都有涉及，最后简单介绍一下。

首先对于位图，这个图形库依赖了 libpng 和 libjpeg 做图像解码，然后即可使用内存中的 bitmap 图像做绘制。

然后对于路径，这个图形库自己实现了各种 cpu 中的像素绘制方法，典型的例子就是这个贝塞尔曲线的绘制源码：

void drawcurve::drawcubicbezier(const point& start, const point& control1, const point& control2, const point& end,
 const rect& mask, int16_t width, const colortype& color, opacitytype opacity)
{
 if (width == 0 || opacity == opa_transparent) {
 return;
 }

 point prepoint = start;
 for (int16_t t = 1; t <= interpolation_range; t++) {
 point point;
 point.x = interpolation::getbezierinterpolation(t, start.x, control1.x, control2.x, end.x);
 point.y = interpolation::getbezierinterpolation(t, start.y, control1.y, control2.y, end.y);
 if (prepoint.x == point.x && prepoint.y == point.y) {
  continue;
 }

 drawline::draw(prepoint, point, mask, width, color, opacity);
 prepoint = point;
 }
}

 基于高中的数学知识，我们不难明白这种曲线是如何绘制出来的：取足够多的点（也就是那个默认 1000 的 interpolation_range）作为插值输入，逐点计算出曲线表达式的 xy 坐标，然后直接修改像素位置所在的 framebuffer 内存即可。这种教科书式的实现是最经典的，不过如果要拿它对标 skia 里的黑魔法，还是不要勉为其难了吧。

最后对于文字的绘制，会涉及一些字体解析、定位、rtl和折行等方面的处理。这部分实际上也是组合使用了一些业界通用的开源基础库来实现的。比如对于「牢」这个字，就可以找到图形库的这么几个开源依赖，它们各自扮演不同的角色：

• harfbuzz - 用来告诉调用者，应该把「牢」的 glyph 字形放在哪里。
• freetype - 从宋体、黑体等字体文件中解码出「牢」的 glyph 字形，将其光栅化为像素。
• icu - 处理 unicode 中许多奇葩的特殊情况，这块个人不了解，略过。

到这里，我们就可以理出一个非常概括性的渲染流程了：

• js 中执行 this.hello = 'ppt' 之类的代码，触发依赖追踪。
• js 依赖追踪回调触发原生函数，更新 c++ 的 component 组件状态。
• component 更新其绑定的 uiview 子类状态，触发图形库更新。
• 图形库更新内存中的像素状态，完成绘制。

这就是个人对「鸿蒙 2.0」这套 gui 技术栈的解读了。时间有限并未进一步深挖，欢迎（文明的）批评指正。

总结

特别声明：本部分主观评论仅针对「鸿蒙 2.0」当前的 gui 框架部分，请勿随意曲解。

对于「鸿蒙 2.0」在 gui 部分的亮点，个人能想到这些：

• 确实有务实（但和当年 ppt 介绍完全两码事）的代码。
• 不是 webview 套壳，布局和绘制是自己做的。
• 无需超过大学本科水平的计算机知识，也能顺利阅读理解。

而至于明显（不只是某几行代码写得丑）的缺失或问题，目前看来则有这么一些：

js 框架层

• 没有基本的组件间通信（如 props / emit 等）能力
• 没有基本的自定义组件能力
• 没有除基础依赖追踪以外的状态管理能力

js 引擎与运行时层

• 标准支持过低，无法运行 vue 3.0 这类需 proxy 的下一代前端框架
• 性能水平弱，难以支持中大型 js 应用
• 没有开放 dom 式的对象模型 api，不利于上层抹平差异

图形渲染层

• 没有实质可用的 gpu 加速
• 没有 svg 和富文本等高级渲染能力
• canvas 完成度低，缺状态栈和很多 api

看起来槽点很多，但是你会指责汽车没有喷气式发动机吗？对于不同复杂度的场景，自然存在着不同的最优架构设计。目前看来，这套设计确实很适合嵌入式硬件和简易「小程序」的场景。但如果按照所谓「分布式全场景跨平台」的要求来审视，那么不管比起现代的 web 浏览器还是 ios 和安卓的 gui，这套架构的复杂度都是完全无法相提并论的。如果想在手机上实装，几乎必定还需要追加大量复杂模块，进行大幅的架构演化与重新设计。

当然，汽车厂商也不会说自己造的是飞机，对吧？

总之这确实是一盘自己做的麻婆豆腐，但不是某些人口中的满汉全席。
最后是个人的主观评论：
首先，这套 gui 技术栈达到了组装和借鉴开源产品时所能获得的主流水平。但论性能和表现力上限，其核心模块距离微软makecode 这类业界 cutting-edge 级的产学研结合前沿方案，仍然有数量级的代际差距。

其次，不必把它当作需要海量专家精密计算的 rocket science——不是贬低自主研发，而是真心地希望大家能明白，「这件事我也可以实际参与进来！」操作系统和 gui 没有那么神秘，已有很多国产的成熟开源产品可供学习、使用与贡献（这里顺便推荐极易体验且同为国产的 rt-thread 作为尝鲜入门之用）。毕竟只有真正搞懂了某个产品在技术上到底是怎么一回事，才不容易被别有用心的人带节奏，对吧？

最后，对于所有熟悉 javascript 的前端开发者们，你们为什么还要阴阳怪气地嘲笑鸿蒙呢？鸿蒙就是 javascript 在中国的财富密码啊！javascript 被鸿蒙这样的「国之重器」采用，可以大大增强前端的道路自信、理论自信、文化自信和技术栈自信。只要以这种形式结合拼接与自研，就可以一举在全国上下获得崇高的声望，这条路真是太让人心驰神往了呀（小声）

我们要团结起来，大力弘扬和宣传 javascript 在大国竞争中的核威慑级地位,争取上升到只要说自己会写javascript，大家就会对你肃然起敬的高度——只要你是前端程序员，买票可以插队，搭车可以让座，开房可以白嫖……好时代，来临了！

想成为国之栋梁吗？来写 javascript 吧！

不多说了，我要去实干兴邦啦！

以上就是浅谈鸿蒙 javascript gui 技术栈的详细内容，更多关于鸿蒙 javascript gui 技术栈的资料请关注其它相关文章！