的 XML 标签组件，都对应一个绑定到 JerryScript 上的 C Component 类，如 TextComponent 和 pComponent 等。除 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 中的像素绘制方法，典型的例子就是这个贝塞尔曲线的绘制源码： 复制voidDrawCurve::DrawCubicBezier(constPoint& start,constPoint& control1,constPoint& control2,constPoint&end,constRect& mask,int16_t width,constColorType& 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 吧！ 不多说了，我要去实干兴邦啦！ 想了解更多编程学习，敬请关注php培训栏目！