关于鸿蒙系统 JS UI 框架源码的分析(1)

文章共3,620字 · 阅读需要大约13分钟

一键AI生成摘要，助你高效阅读

问答

m0_74530944

1061人浏览 · 2024-04-01 11:35:19

m0_74530944 · 2024-04-01 11:35:19 发布

首先鸿蒙应用是打包成 HAP (Harmony Ability Package) 格式分发的，和安卓 APK 一样都是压缩包，包结构大同小异。分发到端上之后，统一由鸿蒙(概念)的 API 承接，然后就分了不同的模式。在华为手机上推送的鸿蒙版本，可以无感兼容安卓应用，肯定是依赖了 AOSP 的。而开源的部分主要面向低端的 IoT 设备，或者手表手环之类的，甚至可以没有屏幕，2021年6月开源的版本刚支持了内存 128MB 以上的设备，还无法独立支撑手机上的应用。这是“套壳”和“自研”的两个极端场景，都未必是稳定的最终状态。而介于两者之间，总架构里框架层和系统服务层的各项子系统，是比较独立解耦的，能同时用在这些场景中，但是功能还不够健全，一部分已经开源了，比如微内核和 JS UI 框架，还有一部分未开源。兼容安卓不是长久之计，开源部分功能简陋，那么中间不确定的这一块会不会是未来的主链路呢？鸿蒙未来会不会真的发展成一个自主研发的全平台操作系统呢？拭目以待吧。

那么可以尝试回答社区里讨论鸿蒙最多的问题：

**鸿蒙是不是自研的？肯定有自研部分，也肯定依赖一些(国外)三方代码。**现阶段要求所有代码都自研是不现实的，不是一两年能完成的，肯定要先站在巨人的肩膀上发挥创新，然后进一步减少依赖，处理好协议和版权问题即可。

鸿蒙是否依赖 AOSP？可以说依赖，也可以说不依赖。HarmonyOS 的兼容模式是依赖 AOSP 的，不然没办法兼容安卓应用；开源的 OpenHarmony 是不依赖 AOSP 的，但目前主要用在一些低端 IoT 设备上。

如果没有特殊说明，下文中提到的「鸿蒙」都特指 OpenHarmony。

鸿蒙的 UI 子系统

鸿蒙的开源版本中没有 Java UI（至少我没找到），实现 JS UI 的框架叫 ACE，是 Ability Cross-platform Environment 的简称，有两个仓库：ace_engine_lite [2] 对应 ACE 旧架构，ace_ace_engine [3] 对应 ACE 新架构，两者的实现原理和上层语法都是不同的。

▐ 源码目录结构

OpenHarmony 开源代码托管在 gitee 上，组下有两百多个仓库，建议按照官方源码获取的文档下载代码，源码目录结构和各仓库的对应关系可以参考 manifest 仓库的配置文件[4]。

如果你的环境已经配置好，执行下面这两行命令即可：

repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verifyrepo sync -c

整个过程耗时 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 渲染的各项能力，是个总的管理类，提供了生命周期和功能调度接口，内部划分了许多子模块：

Frontend: 前端代码的执行环境，JS 或者 JSON，有这层抽象或许还可以支持其他脚本引擎。
TaskExecutor: 单一线程内的任务管理器，类似其他渲染引擎中的 TaskRunner。
AssetManager: 资源管理器，可用于加载 JS 代码、图片、字体等资源。应该也具备缓存能力。
PipelineContext: 渲染管线的管理类，监听 vsync 回调刷新内部脏节点的布局、绘制、渲染。
AceView: 渲染生成的 UI 根节点，可以贴到外层容器中。
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() 接口，可以更新模板的数据，具备一定的动态化能力。