关于渲染:渲染引擎分析-鸿蒙OpenHarmony-JS-UI-源码阅读笔记

12次阅读

共计 7538 个字符，预计需要花费 19 分钟才能阅读完成。

作者：门柳

鸿蒙是华为研发的新一代终端操作系统，能实用于 IoT、手表、手机、Pad、电视等各种类型的设施上，扛起“国产操作系统”的大旗，也蒙受了很多非议。2021 年 6 月初公布了 OpenHarmony 2.0 Canary 版本，开源了更多子系统的代码，反对内存 128MB 以上的设施。其中就蕴含了新版本的 JS UI 框架，本文重点剖析这部分代码。（文章内容仅供参考，如有任何形容不精确的内容，感激大家后盾留言探讨与斧正~）

倡议去 OpenHarmony 官网[1] 上理解更多信息，上面是官网的技术架构图：

总结一下分为：应用层、框架层、零碎服务层、内核层四个局部。内核层次要是宏内核的 Linux 和微内核的 LiteOS，以及各项硬件驱动程序。框架层和零碎服务层分割比拟严密，有横向的框架和纵向的服务，细分成很多绝对独立的子系统，UI 框架和 Ability 框架都在这里。

留神这是 OpenHarmony 的架构，不含 GMS 和 HMS、不含 AOSP 也不反对安卓 API，与华为手机中推送的 HarmonyOS 版本是有差异的，下文开展比照。

中文名都叫做「鸿蒙」，背地还是有一些区别的。HarmonyOS 是华为研发的商用操作系统，OpenHarmony 是华为募捐给凋谢原子开源基金会 (OpenAtom) 的开源版本，两个版本之间有穿插局部，概念上有混同，所以很多探讨都在“自研”和“套壳”之间摇摆不定。

我尝试整顿了各项概念之间的关系，如下图所示。非官方图，仅供参考，所有以官网口径为准。

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

那么能够尝试答复社区里探讨鸿蒙最多的问题：

鸿蒙是不是自研的？必定有自研局部，也必定依赖一些 (国外) 三方代码。 现阶段要求所有代码都自研是不事实的，不是一两年能实现的，必定要先站在伟人的肩膀上施展翻新，而后进一步缩小依赖，解决好协定和版权问题即可。

鸿蒙是否依赖 AOSP？能够说依赖，也能够说不依赖。HarmonyOS 的兼容模式是依赖 AOSP 的 ，不然没方法兼容安卓利用； 开源的 OpenHarmony 是不依赖 AOSP 的，但目前次要用在一些低端 IoT 设施上。

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

鸿蒙的开源版本中没有 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-verify
repo 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 框架的架构图[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: 平台资源的注册和治理，以及局部通信接口，可在这里实现同层渲染性能。

在 Frontend 局部，有三种不同类型的实现，别离是基于渲染指令的命令式 UI、申明式 UI、以及无需脚本引擎，用 JSON 文件渲染的 UI。命令式 UI 和申明式 UI 都是用 QuickJS 作为脚本引擎，申明式 UI 里蕴含了 V8 的形象，然而这部分如同没有开源进去。

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

<div class="container">
  <text class="title-text">{{headTitle}}</text>
</div>

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

// xxx.js
export 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，这类技术社区里曾经有大量实际，不再开展介绍。

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

@Component
class MyDemo {
  Column(Text('Hello World!'),
    Text('Some text here')
      .fontsize(36)
      .color(Color.Red)
  ).center()}

这里是 JSView 的源代码，平铺展现进去如下所示，目前的品种还不是很多。

这种形式的劣势是组合性比拟好，各布局节点不会像 CSS 那样相互影响，布局算法比拟高效。然而摈弃了前端青睐的 HTML + CSS 的布局形式，现存的各种前端框架、组件库、款式库没法间接迁徙过去，生态建设会有些艰巨。

叫 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 相比于前一代诺基亚摩托罗拉在技术上有什么革命性的颠覆，鸿蒙的设计理念还是有一些亮点的。零碎级能力的翻新，要有个过程能力被应用层感知到。 鸿蒙兴许只是个结尾，要想带来一波爆发式的倒退，可能须要乔布斯这样的人物，把新的零碎能力转化成新一代交互、新一代产品。再思考国家政策和技术自研的趋势，鸿蒙将来可期。

OpenHarmony 官网：https://www.openharmony.cn/
ACE Lite: https://gitee.com/openharmony…
ACE Engine: https://gitee.com/openharmony…
配置文件：https://gitee.com/openharmony…
ACE 架构图：https://gitee.com/openharmony…
类小程序 DSL：https://device.harmonyos.com/…
新 ACE 架构图：https://gitee.com/openharmony…
qjs_engine.cpp: https://gitee.com/openharmony…
TaskCenter.ts: https://gitee.com/openharmony…
FlutterSceneBuilder: https://gitee.com/openharmony…

关注咱们，每周 3 篇挪动干货 & 实际给你思考！

正文完

渲染

发表至：渲染

2021-09-07

0

关于渲染:服务端渲染搭建示例

关于渲染:Unity移动端游戏性能优化简谱之-以引擎模块为划分的CPU耗时调优

关于渲染:Cube-技术解读-Cube-渲染设计的前世今生

关于渲染:渲染引擎Blender的2021年最佳渲染引擎上

关于服务器:云服务器安全吗降低风险和保护数据的-5-种方法

关于渲染:渲染引擎分析-鸿蒙OpenHarmony-JS-UI-源码阅读笔记

鸿蒙零碎概述

零碎架构分层

HarmonyOS 和 OpenHarmony 的区别

鸿蒙的 UI 子系统

源码目录构造

新旧 ACE 框架

整体渲染过程

容器创立和治理

JS UI 开发框架

JS Frontend (命令式 UI)

Declarative Frontend (申明式 UI)

Card Frontend (无脚本 UI)

节点构建流程

布局绘制渲染

探讨鸿蒙的倒退

* 参考链接

站内搜索