一起看看鸿蒙 JavaScript GUI 技术栈(2)-木庄网络博客

首先对于位图，这个图形库依赖了 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 吧！

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