渲染引擎分析 - 鸿蒙(OpenHarmony) JS UI 源码阅读笔记_open harmony

作者：门柳

鸿蒙是华为研发的新一代终端操作系统，能适用于 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 的区别

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

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

首先鸿蒙应用是打包成 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