关于鸿蒙系统 JS UI 框架源码的分析(1)，面试被逆袭

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新HarmonyOS鸿蒙全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上鸿蒙开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注鸿蒙）

正文

AceContainer 提供了 UI 渲染的各项能力，是个总的管理类，提供了生命周期和功能调度接口，内部划分了许多子模块：

1. Frontend: 前端代码的执行环境，JS 或者 JSON，有这层抽象或许还可以支持其他脚本引擎。

2. TaskExecutor: 单一线程内的任务管理器，类似其他渲染引擎中的 TaskRunner。

3. AssetManager: 资源管理器，可用于加载 JS 代码、图片、字体等资源。应该也具备缓存能力。

4. PipelineContext: 渲染管线的管理类，监听 vsync 回调刷新内部脏节点的布局、绘制、渲染。

5. AceView: 渲染生成的 UI 根节点，可以贴到外层容器中。

6. PlatformResRegister: 平台资源的注册和管理，以及部分通信接口，可在这里实现同层渲染功能。

▐  JS UI 开发框架

在 Frontend 部分，有三种不同类型的实现，分别是基于渲染指令的命令式 UI、声明式 UI、以及无需脚本引擎，用 JSON 文件渲染的 UI。命令式 UI 和 声明式 UI 都是用 QuickJS 作为脚本引擎，声明式 UI 里包含了 V8 的抽象，但是这部分好像没有开源出来。

• JS Frontend (命令式 UI)

「命令式 UI」是从引擎实现角度的说法，因为底层是基于渲染指令的，真正透出给开发者的语法，可以对接声明式、响应式的前端框架，比如 Vue.js。鸿蒙官网的 JS UI 背后对应的就是 JSFrontend，语法和小程序很像，应该是从之前的快应用继承而来，每个组件对应了 xx.hml 的模板文件、xx.css 的样式文件、xx.js 的脚本文件以及 xx.json 配置文件。

{{headTitle}}

/* xxx.css */.container { flex-direction: column; margin-top: 20px; margin-left: 30px;}.title-text { color: #1a1a1a; font-size: 50px;}

// xxx.jsexport default { data: { headTitle: ‘Capture the Beauty in This Moment’ }}

上述代码将会打包编译成一个 js 文件，动态加载执行。

在初始化 JS 执行环境时，会先绑定一系列的原生接口，然后执行内置的 js framework，然后动态加载执行用户的 js 代码。在 js frontend 的 qjs_engine.cpp [8] 文件中，可以看到向 JS 环境中注册的接口：

因为 QuickJS 是支持 ES6 Module 的，这些接口是注册到了 ace 的模块中，可以用 import 导入，环境中也有 ace 这个全局环境：

import * as ace from ‘ace’

// 创建 body 节点ace.domCreateBody(0, ‘div’, {/* attrs /}, {/ styles /}, {/ events */})

ACE 中实际发送渲染指令的代码在 third_party_jsframework 的 TaskCenter.ts[9] 中，接口的设计以及渲染指令的格式都与 alibaba/weex 的 TaskCenter.js 基本相同，也用 JS 模拟了简版 DOM API，上面对接了小程序风格的 DSL，这类技术社区里已经有大量实践，不再展开介绍。

• Declarative Frontend (声明式 UI)

这方面公开的资料不多，从代码上来看，并不是用 HML + CSS 的方式构建 UI，而是像 Flutter 一样用原子化的布局函数组合 UI，Flutter 里是用 Widget，鸿蒙的声明式 JS UI 用的是 JSView。再结合 jsproxyClass.js 里的代码来分析，提供了 ECMAScript 规范中的装饰器/注解辅助编程，预估代码写起来是这个样子的：

@Componentclass MyDemo { Column( Text(‘Hello World!’), Text(‘Some text here’) .fontsize(36) .color(Color.Red) ).center()}

这里是 JSView 的源代码，平铺展示出来如下所示，目前的种类还不是很多。

这种方式的优势是组合性比较好，各布局节点不会像 CSS 那样互相影响，布局算法比较高效。但是抛弃了前端喜爱的 HTML + CSS 的布局方式，现存的各种前端框架、组件库、样式库没法直接迁移过来，生态建设会有些艰难。

• Card Frontend (无脚本 UI)

叫 CardFrontend 有点奇怪，可能是主要用在鸿蒙桌面 Widget 这种卡片化场景里吧。它是不依赖脚本引擎的，而是由特定格式的 JSON 文件驱动渲染。

JSON 文件的格式还没有明确的文档，这里有个测试用例，能看到主体分为 template、styles、actions、data 这几部分，模板里可以写花括号的数据绑定 {{some.data}}，里边可以写简单的 JS 表达式，也不是完全静态的。而且 CardFrontend 类上有 UpdateData() 接口，可以更新模板的数据，具备一定的动态化能力。

▐  节点构建流程

上面的三种前端框架对应了不同的 UI 开发方式，但是后半段的节点构建、布局绘制算法都是同一条链路，而且是用 C++ 自绘渲染的，不依赖系统 UI，一致性比较好。把完整的节点构建流程画出来如下所示：

声明式 UI 的 JSView 是直接绑定到 JS 环境里的，由页面/卡片代码直接调度，JSView 有大量的派生类，分别对应了原子化的样式描述。JSView 树会生成一颗 Component 树，节点基本是一一对应的，比如 JSGrid 会生成 GridLayoutComponent、JSText 会生成 TextComponent。

JSFrontend 和 CardFrontent 都是合成了渲染指令(C++)，一个由前端框架 diff 生成，一个直接从 JSON 解析，然后构建内部一棵精简的 DOM 树(C++)，注意这棵所谓 DOM 树是没有绑定到 JS 环境里的，没法通过 JS API 直接操作。每个 DOM 节点都会再生成一个 Component 节点。

Component 的派生类 RenderComponent 是可以直接生成 RenderNode 的，算是一条更短的链路吧。比如 ImageComponent 就继承自 RenderComponent。另一个派生类是 ComposedComponent，是由其他 Component 组合而来的。Element 也是相似的数据结构，派生了 RenderElement 和 ComposedElement。Component 可以构建 Element 和 RenderNode，Element 可以构建 RenderNode，坦白讲我还没看明白这两棵树的差异，未来是不是可以把 Component 和 Element 合并呢？

RenderNode 是真正的布局节点，其他渲染引擎叫 RenderObject 或者 LayoutObject，派生了很多子类，实现了各式各样的布局算法，类型设计和 Flutter 的 Widget 接近。RenderNode 先布局再绘制，产出的数据结构是 Layer Tree，这一层在鸿蒙里是用来跨平台的，也就是官方架构图里的 Porting Layer[7]，提交给不同的合成器就可以跨不同的平台。

比较有意思的是，鸿蒙的 third_party 里有 flutter，而且实现了一个 FlutterSceneBuilder [10]，porting layer 的数据结构和 Flutter Engine 的 layer 也基本一致，在 flow 里还添加了 ohos_layers 的代码。换句话说，鸿蒙的新的 ACE 框架或许可以跑在 Flutter Engine 之上，Flutter Framework 或许也可以跑在鸿蒙的 Graphic UI 上。

▐  布局绘制渲染

实现渲染管线的核心类是 PipelineContext，内部存储了多份脏节点的队列，当节点属性发生变化时，不会立即触发布局和绘制，而是加入到缓存的队列里。同时监听系统 vsync 信号，每帧按序 flush 内部记录的脏节点，依次执行动画检测、节点重新构建、重新布局、重新绘制、刷新光标等流程。

核心代码是截图中的这两段，有所简化，每帧 vsync 会触发 OnVsyncEvent() 回调，如果 surface 已经初始化好，则依次刷新内部的脏节点，如果包含动画，则调用 RequestFrame() 请求触发下一帧 vsync。首先 dirty Elements 会触发 Rebuild() 重新构建 RenderNode，并且调用 MarkNeedLayout() 把它加到待布局的队列里，然后 FlushLayout 会刷新这个队列，调用节点的 OnLayout() 方法计算布局，然后把自身再加入到待绘制的队列里，然后 FlushRender() 依次调用节点的 Repaint() 方法重新绘制，生成 layer tree。

探讨鸿蒙的发展

在鸿蒙开发者大会上还贴过这么一张图，手机、平板、PC 的设备数已经很久没有大幅增长了，在未来五年里也没有多少增量。但是 IoT 设备，比如手表、线下大屏、车机等装置越来越多，IoT 设备数还处于快速发展的阶段。鸿蒙的判断未来是万物互联的时代，目标是打造「面向多智能终端、全场景的分布式操作系统」。与 AliOS 相比，鸿蒙诞生在了合适的时间，有足够大的空间。

鸿蒙系统的微内核系统，硬件驱动和子系统是可插拔的，可以很好的兼容从低端到高端、形态差异很大的 IoT 设备。还有一个特点就是 Ability 的跨设备流转，发挥华为在通信技术上的优势，多个硬件设备可以在系统层直连，说不定可以催生出一些新的玩法。

对于新兴事物，一直拿旧的事物做类比，看到的只有与旧事物相同的部分，没有看到的才是真正的价值所在。如果鸿蒙只兼容安卓，没有差异化的功能，就没有太大的发展意义，只解决了“国产化”的情怀。也很难讲 Android/iOS 相比于前一代诺基亚摩托罗拉在技术上有什么革命性的颠覆，鸿蒙的设计理念还是有一些亮点的。系统级能力的创新，要有个过程才能被应用层感知到。鸿蒙也许只是个开头，要想带来一波爆发式的发展，可能需要乔布斯这样的人物，把新的系统能力转化成新一代交互、新一代产品。再考虑国家政策和技术自研的趋势，鸿蒙未来可期。

参考链接

1. OpenHarmony 官网：https://www.openharmony.cn/

2. ACE Lite: https://gitee.com/openharmony/ace_engine_lite

3. ACE Engine: https://gitee.com/openharmony/ace_ace_engine

4. 配置文件：https://gitee.com/openharmony/manifest/blob/master/default.xml

5. ACE 架构图：https://gitee.com/openharmony/ace_engine_lite/blob/OpenHarmony-2.0-Canary/figures/JS%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E6%A1%86%E6%9E%B6.png

6. 类小程序 DSL：https://device.harmonyos.com/en/docs/apiref/js-framework-file-0000000000616658

7. 新 ACE 架构图：https://gitee.com/openharmony/ace_ace_engine/blob/OpenHarmony-2.0-Canary/figures/JS-UI%E6%A1%86%E6%9E%B6%E6%9E%B6%E6%9E%84.png

8. qjs_engine.cpp: https://gitee.com/openharmony/ace_ace_engine/blob/OpenHarmony-2.0-Canary/frameworks/bridge/js_frontend/engine/quickjs/qjs_engine.cpp#L1925-1940

9. TaskCenter.ts: https://gitee.com/openharmony/third_party_jsframework/blob/OpenHarmony-2.0-Canary/runtime/main/manage/event/TaskCenter.ts#L127-133

10. FlutterSceneBuilder: https://gitee.com/openharmony/ace_ace_engine/blob/OpenHarmony-2.0-Canary/frameworks/core/pipeline/layers/flutter_scene_builder.

✿  拓展阅读

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注鸿蒙）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

ne_builder.

✿  拓展阅读

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注鸿蒙）
[外链图片转存中…(img-BolTSk9d-1713613167663)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！