• 0

  • 514

浅析鸿蒙 JavaScript GUI 技术栈

1个月前

众所周知,刚刚开源的「鸿蒙 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.jsobserver.jssubject.js),相当于有且只有这么一个功能:

一个可以 watch 的 ViewModel。

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

JS 引擎与运行时层

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

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

那么在「鸿蒙 2.0」中,JS 运行时是如何搭建出来的呢?有这么几条重点:

  • JS 引擎选择了 JerryScript,这是一款由三星开发的嵌入式 JS 引擎。
  • 每种形如 <text><div> 的 XML 标签组件,都对应一个绑定到 JerryScript 上的 C++ Component 类,如 TextComponentDivComponent 等。
  • 除 UI 原生对象外,还有一系列在 JS 中以 @system 为前缀的 built-in 模块,它们提供了 JS 中可用的 Router / Audio / File 等平台能力(参见 ohos_module_config.h)。

这里特别值得一提的是 Router。它和 vue-router 等常见 Web 平台路由的实现原理有很大区别,是专门在运行时内深度定制的(参见 router_module.cppjs_router.cppjs_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 渲染中的几项关键能力,则基本可分为路径、位图和文字三类。这个图形库在这几个方面都有涉及,最后简单介绍一下。

首先对于位图,这个图形库依赖了 libpnglibjpeg 做图像解码,然后即可使用内存中的 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 吧!

不多说了,我要去实干兴邦啦!

免责声明:文章版权归原作者所有,其内容与观点不代表Unitimes立场,亦不构成任何投资意见或建议。

程序员

514

相关文章推荐

未登录头像

暂无评论