关于鸿蒙系统 JS UI 框架源码的分析_鸿蒙源码分析

整个过程耗时 15~30min 左右，可以在执行完第一行命令后，找到 manifest 配置文件，移除 linux 和一部分 third_party 的依赖，会更快一点。

简略版目录结构如下（略过无关目录，仅展开相关部分）：

OpenHarmony/ ├── applications # 应用程序样例 ├── base # 基础软件服务子系统集 ├── docs ├── domains # 增强软件服务子系统集 ├── drivers # 驱动子系统 ├── foundation # 系统基础能力子系统集 │ ├── aafwk # Ability 框架 │ ├── ace # JS UI 框架 │ │ ├── ace_engine # ACE 1.0, 仓库名: ace_ace_engine │ │ └── ace_engine_lite # ACE 2.0, 仓库名: ace_engine_lite │ ├── appexecfwk # 用户程序框架和包管理模块 │ └── graphic # 图形库相关的子系统 ├── interface │ └── sdk-js # JS API 的 TS 类型文件 ├── kernel # LiteOS 内核 │ ├── liteos_a │ └── liteos_m ├── test └── third_party

▐  新旧 ACE 框架

下面是 ACE 框架的架构图[5]，现在文档里描述的、IDE 里支持编写的都是这套 UI，提供的是类似小程序的 DSL[6] 开发 UI，HML(HarmonyOS Markup Language) + CSS + JS。

看起来和主流 JS + 原生渲染框架的架构都相似，提供了编译工具将源码编译成 js bundle，运行时有个在 JS 引擎启动后默认执行的 framework.min.js 文件，实现节点构建逻辑，然后在 C++ 层实现了一套 UIKit，支持的组件大概有二三十个。

在另一个不带 lite 后缀的仓库里(ace_ace_engine)，还有一套 UI 系统的实现，架构层次更加简洁，技术更加先进，应该是新一代的 UI 框架，这是 新的 ACE 框架的架构图[7]：

这套架构主体分为应用、框架、引擎以及跨平台适配这几部分，应用层就是透出给开发者的语法，有好几种模式，下文详解。框架层实现了前端框架常见的组件化、MVVM 能力，能够响应式的更新 UI。下面是 JS 引擎，使用的是 QuickJS，应该也支持 V8。再向下是渲染引擎，包含了核心的渲染管线、动画、事件和各种布局绘制算法。

最下面的 porting layer 是适配多平台的关键，定义了平台无关的 layer 数据结构，可以提交给不同的合成器(Compositor)合成渲染，从代码上看，是支持 Flutter Engine 的。

整体渲染过程

▐  容器创建和管理

鸿蒙 UI 的基本单位是 FA (Feature Ability)，对应一个 AceAbility 的实例，提供了生命周期的钩子，在执行 OnStart() 的时候会在内部创建一个 AceContainer。但是这个 AceContainer 不由 AceAbility 直接持有，而是由全局唯一的单例 AceEngine 管理。

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 配置文件。

/* 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
   自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

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

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

本文讲解了我对Android开发现状的一些看法，也许有些人会觉得我的观点不对，但我认为没有绝对的对与错，一切交给时间去证明吧！愿与各位坚守的同胞们互相学习，共同进步！

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

码讲义、实战项目、讲解视频，并且会持续更新！**

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

本文讲解了我对Android开发现状的一些看法，也许有些人会觉得我的观点不对，但我认为没有绝对的对与错，一切交给时间去证明吧！愿与各位坚守的同胞们互相学习，共同进步！

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！