看起来和主流 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()
接口,可以更新模板的数据,具备一定的动态化能力。
▐ 节点构建流程
上面的三种前端框架对应了不同的 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 内部记录的脏节点,依次执行动画检测、节点重新构建、重新布局、重新绘制、刷新光标等流程。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数HarmonyOS鸿蒙开发工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上HarmonyOS鸿蒙开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新
如果你觉得这些内容对你有帮助,可以添加VX:vip204888 (备注鸿蒙获取)
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新**
如果你觉得这些内容对你有帮助,可以添加VX:vip204888 (备注鸿蒙获取)
[外链图片转存中…(img-dNGOmcBt-1712746907552)]
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!