11 月 4 日，松山湖畔，第四届华为开发者大会召开。
作为开发者，自然最关注的是大会中关于开发框架/套件以及开发者工具的部分，毕竟这是和开发者直接打交道的领域。无论是大会上着重强调的原子化卡片、分布式服务、超级中转站等功能，其底层都是基于 HarmonyOS 3 新的技术体系架构。
在 11 月 5 日上午开发者主题演讲里，华为技术专家用三句话定义了这一代的鸿蒙操作系统：
一次开发，多端部署；
可分可合，自由流转；
统一生态，原生智能。
愿景很美好，但是要达成这样的技术全景，需要的技术板块非常多，不由让人怀疑完成度究竟如何。其实道理很简单，因为一旦涉及到衔接开发者，衍生出来的问题就会像石头扔进平静的水潭里一般——设计系统、运行时管理、UI框架、编程范式、调试、调优、测试、日志、上架、分发……特别是还要面对当前这些已经被其他成熟平台把开发体验喂养得极其挑剔的开发者，鸿蒙真的做好准备了么？
顺着这个思路，我尝试在主题演讲和开发者论坛里寻找答案。
好在我的答题本上不是空空如也，近一段时间里，百度正在使用鸿蒙的新 UI 框架 ArkUI 以及 Stage 应用模型制作了 OpenHarmony 版本的百度 APP。除此之外，我还在动态化跨端开发方面尝试推进和 ArkUI 对接，并取得了初步的成果。
先来看一下 HarmonyOS 的技术栈，由下至上分为三层，依次是：
* 由 HarmonyOS Design、ArkTS、ArkUI、ArkCompiler 为基础的开发基础框架/套件层；
* 由 DevEco Studio 和 DevEco Testing 组成的开发者工具层；
* 由 AppGallery Connect（AGC）支撑应用上架、分发和运营层。
展开来讲的话，篇幅会很长，本文会抓住其中最重要的部分进行分析，这里我给出四个关键词：**性能**、**可控**、**体验**、**动态**。
注：本文提到的内容大部分面向明年 Q1 鸿蒙将要退出的 3.1 版本的操作系统。
且听我一一道来。
性能
性能依赖轻量级的运行时环境，鸿蒙 3.1 版本的革新有很多。这里讲解其中最重要的 3 点：
* ArkUI 渲染树归一
* Stage 应用模型带来的资源优化
* Runtime 轻量化并发
我们知道，一般渲染框架的后台架构由三棵树支撑（以 flutter 为例，Widget Tree、Element Tree、Render Tree），它们各司其职。有的是为了衔接组件系统，有的是为了在内存中维护真正的结构信息（承担 Virtual DOM 的责任），有的为了桥接底层渲染引擎。
ArkUI 在此基础上进行了融合升级，把多节点组合模型升级为“单节点+属性”的组合模型，将数据依赖组件级更新升级为细粒度函数级更新，从而从而实现三棵渲染树的归一，提升了组件构建速度，降低了内存占用。
（上图来源于大会主题演讲）
按照鸿蒙官方给出的数据，这次技术升级带来的性能收益包括：渲染速度提升 20%、渲染内存降低 30%、渲染指令数降低 20%。
除了渲染树优化，鸿蒙应用模型进行了彻底的迭代，从 API 7 支持的 FA 应用模型切换为 API 9 的 Stage 应用模型，FA 模型在未来会淡出历史舞台。Stage 模型相关的知识点有很多，在性能这一 Part，我们着重了解下它带来的最为重大的变化——同一个虚拟机中可以容纳更多个组件。这使得开发者更为方便地共享状态的同时，还能大幅降低内存的占用率：
（上图来源于分论坛——鸿蒙开发套件（语言与框架）——利用Stage应用模型快速构建HarmonyOS应用）
除了应用模型的更新，在 ArkCompiler 运行时层面，鸿蒙打造了 Lite Actor 轻量化并发模型。鸿蒙除了轻量化基础架构，还支持了对象共享机制（目前支持不可变对象的共享，未来还会支持可变对象的部分共享）：
（上图来源于分论坛——DevEco开发工具新特性——深入浅出ArkCompiler）
在支持传统的基于 Worker 的多线程之余，鸿蒙还支持新的 Task Pool API。从代码体验上来说，相比 Worker，Task Pool 的使用更加直观清晰，开发者无需关心并发实例的生命周期，业务无需关心场景下并发负载问题，因为负载管理在运行时由 OS 层面统一协同处理，管控线程数和线程资源开销。
当然，除了以上三点之外，ArkUI 的 AOT 编译管线、XComponent 接入底层的高性能渲染方案以及各种性能调优后的高阶组件库……都大幅提升了 3.1 版本的鸿蒙的运行性能。
可控
先来问大家一句：开发的时候你最怕什么？
我自己的答案是：不可控。无法收敛的 bug，时不时会冒出的所谓的“底层”问题，以及黑盒的构建、编译、渲染 pipeline……这些都是程序员头发的终极杀手。
毕竟大家都习惯把命运掌握在自己手里，新版本的鸿蒙自然也想到了这点，我认为主要体现在 3 个方面：
* 基于 ArkTS 的声明式开发范式
* Stage 模型对鸿蒙应用运行规则的重构
* Hvigor 对构建任务流的自由扩展
你可能会想：ArkTS 的声明式开发范式和可控性有什么关系？毕竟 JS/CSS/Template 的单文件合一在别的框架的 SFC 模式里早就实践过，而且声明式的开发模式已经不是什么新鲜的事情。但深入来看， ArkTS 在可控性和标准化这里做得更加“极致”了些。
通过装饰器，ArkUI 把一切组件 UI 相关的开发彻底“乐高化”，包括组件定义、入口定义、状态定义、UI Builder 定义、组件扩展定义。并且，ArkUI 提供的丰富的内置组件、属性方法和事件方法，都让 UI 开发变得更加可控。
再来说下 Stage 模型。前文提到 Stage 模型时主要说了它对于虚拟机管控和组件资源占用和内存共享的优化，这里主要想强调的是，与 FA 模型（以及 AOSP 生态为代表的复杂的应用模型）不同，Stage 模型简化了鸿蒙应用的运行规则。
在 Stage 模型里，Ability 被分位 UI Ability 和 Extension Ability，前者是一个 UI 容器，每一个对应一个独立的任务（MIssion），在主进程中运行；而后者是一个模板服务（使用是需要使用 Extension Ability 的派生类），衔接系统服务，场景化地支持特定服务，虽然在单独的进程中运行，但是和主进程有一样的 uid，共享数据目录。
（上图来源于分论坛——鸿蒙开发套件（语言与框架）——利用Stage应用模型快速构建HarmonyOS应用）
Stage 模型体现了鸿蒙“节制”的设计思想，不支持开发者配置多进程，不支持开发者自定义服务，不支持应用直接拉起自己的场景服务；只支持应用间 UI 展示界面的相互调起以及通过系统服务调起场景服务。
最后聊一下 Hvigor 对构建任务流的自由扩展（Hvigor 是 DevEco 集成的官方构建打包工具）。说实话，在来参加 HDC 之前，我对 Hvigor 构建工具的认知还处于黑盒状态，只是从之前的技术交流中知道它使用了主流的 Web 向的前端构建方案（Webpack），当然因为其 TS 超级的语言特性，也包括了相关的语言编译方面的 Configuration。但是在听了华为工程师的分享后，我了解到，在 Hvigor 的构建 pipeline 中，工具会为开发者预留了很多 Task 插槽，可以插入到你想要介入的编译构建环节：
（上图来源于分论坛——DevEco开发工具新特性——DevEco Hvigor 工具助力灵活高效构建打包）
比如构建前的集成环境检测、构建过程中插桩修改特定代码和资源以及构建打包的后置任务。开发者可以复用 Hvigor 的调度能力，提升任务的执行效率。
对开发范式、应用模型和构建打包的精心设计，让开发者享受到“我命由我不由天”，除此之外，在开发调试、调优和测试环节，鸿蒙的开发者工具也做了大量的工作，这里且不一一赘述。
体验
用户体验永远是绕不开的话题，HarmonyOS 给自己的定位是“面向万物互联时代的全场景分布式操作系统”。对于一个分布式系统，最有挑战也最需要解决的就是体验一致性问题。在本次 HDC 开发者大会里，对于这个问题，鸿蒙从设计和技术两个维度给出了解决方案：
* 设计上，深入实践响应式布局的设计方案
* 技术上，做到一次开发多端部署
用户体验在 UI 层面的基础是设计系统。从十几年前我刚开始接触前端开发，栅格化就植入了我的大脑，今天看鸿蒙的新设计语言，基础依然如是。之前的 HDC 大会上，设计方向就提出了“屏幕断点”的概念，针对不同设备和不同尺寸的屏幕进行差异化的布局和显示，这次迭代，鸿蒙基于栅格系统又强化了这一概念。
栅格系统由 Margin（边界大小，决定了整体宽度）、Gutter（内容 Column 间距）和 Column（内容占位元素）三个属性构成，是响应式布局的基础。
（上图来源于分论坛——鸿蒙开发套件（语言与框架）——HarmonyOS动态响应式布局介绍）
通过断点、Media Query 和栅格化，响应式布局可以实现界面随外部容器大小有级不连续变化。而在系统默认推荐的超小、小、中、大四个屏幕断点的基础上重构栅格系统，使得局部容器的变化方式可以相互独立，共同打造 Harmony（和谐）的交互体验。
技术上，鸿蒙对交互事件手势进行了归一化处理，提供了大量的具备自适应布局能力的组件，但是，比较吸引我的是鸿蒙对于端（系统）能力的处理和封装。
做过移动端开发的同学都知道，端能力的纷杂堪比当年对 IE 6/7/8 以及各种移动版本 Webview 的支持，而因为端能力的适配问题引入的 bug 以及不良开发体验给很多程序员都带来了不好的体验。对于语言层面，可以针对 JS 引擎不同版本进行统一的 polyfill 管控，而对于系统的端能力，如何分而治之，则需要投入更大的精力。这不光影响功能是否正常运行，对于 OpenHarmony 这种分布式的 OS，由于需要支持更重 IoT 设备，端能力的管控显得更加重要。
为此，鸿蒙引入了一种叫做 syscap（System Capability）的机制来解决端能力的管控问题，把系统能力分为支持能力集、要求能力集和联想能力集。
（上图来源于分论坛——鸿蒙开发套件（语言与框架）——一次开发，多端部署）
支持能力集是针对设备的，不同设备的能力集合不一样；要求能力集，顾名思义，是针对应用在不同设备上需求的交集，因为必须提供这些能力应用才可用；联想能力集则针对开发场景，是在 IDE 中针对能力进行的联想 API 集合。
你可能会问，既然设备之间的能力不一样，那么在使用能力的时候，如何判断哪些能力可用，哪些能力不可用？答案是：`CanIUse`。对，就是大家在 Web 开发中经常做兼容性查询的那个 CanIUse 网站同名的查询接口，开发者可以通过这个方法来判断设备是否支持某个系统能力。
能力的支持程度决定了分发结果，而开发者也可以在配置文件中对联想能力和要求能力进行配置。
配置，这两个字很关键。
鸿蒙力求使用最少的代码，依赖声明式的 UI 编程和丰富的组件库，依赖项目丰富的配置文件，落地“一多开发”模式，为开发者提供良好的编程体验，为用户提供优秀的跨设备使用体验。
动态
**城外的人想进去，城里的人想出来。**
动态化也一样。一方面是 ArkUI 能够做到跨平台，另一方面是其他跨平台框架能够桥接到 ArkUI。
对于 ArkUI 来说，除了作为 HarmonyOS 原生的应用框架，以及原子化服务的基础运行环境，它的目标还有一个，就是作为三方应用的通用跨平台框架：
（上图来源于分论坛——鸿蒙开发套件（语言与框架）——如何利用ArkUI开发跨平台的应用程序）
这里背后要解决的问题很多，比如组件和 API 的适配，系统能力的适配，资源适配，工作流的适配等等。
从美的技术专家的分享中，能够看到，在“把 ArkUI 变成通用跨平台的框架”这条路上，鸿蒙团队和第三方开发者已经做了很多工作。比如 MiniX，这是基于 OpenHarmony ArkUI 二次开发的适配美的 IoT 场景的跨端应用开发框架，已经对组件和 API 进行了分级适配，并且还开发了配套的定制化的 VSCode 插件。
（上图来源于分论坛——鸿蒙开发套件（语言与框架）——ArkUI跨平台能力节约开发成本实践）
对于三方框架向 ArkUI 桥接这一个路径，鸿蒙同京东进行了深入的合作。京东轻量级的跨端渲染框架 MCube 将内容通过动态化模板的方式下发到端侧，经过 DSL 解析来实现局部数据更新。与此同时，可以借助 ArkUI 的统一渲染能力，减少渲染节点，实现性能和功耗的优化。
（上图来源于分论坛——鸿蒙开发套件（语言与框架）——HarmonyOS开发语言与框架新进展）
对于三方框架如何同 ArkUI 声明式开发范式进行桥接，我也给出了自己的看法，即“混合跨端开发方式”。百度的动态化开发框架 Talos 以及其包含的轻量级动态化方案 Talos Lite，未来会和 OpenHarmony 技术栈进行深入的整合。
动态化命令式的三方框架想要桥接到 ArkUI 声明式的开发范式上，需要整合三方库自己的 Element Tree 和鸿蒙的节点树，实现 widget 层的组件级别的渲染驱动，而 ArkUI 暴露的 XComponent 组件以及自定义组件的开发模式，能让这一桥接过程变得更加深入，性能更加高效（Talos-OH 2.0）。与此同时，像 MCube、Talos Lite 这样的“描述协议型”的轻量级跨端渲染方案，则能充分发挥出 ArkUI 高性能的渲染特性。
因此我认为，基于“体验一致性”、“性能”、“复杂度”和“标准化对齐”的决策模型，能够指导开发者进行正确的技术选型：
（上图来源于分论坛——鸿蒙开发套件（语言与框架）——Talos应用框架与ArkUI对接实践）
无论是让三方框架接入鸿蒙生态，还是让 ArkUI 自身成为跨端开发框架，鸿蒙都在对外展示其极大的包容度。相信在不久的将来，OpenHarmony 会以开源开放的姿态，成为主流跨端开发框架的选型之一，同时也成为更多三方框架的坚实基座。
说些其他的话
性能、可控、体验、动态——这是我凝练出的，本次 HDC 大会给软件开发者传达出的最重要的四个词。
当然，除了开发语言、框架、套件和开发者工具，本次 HDC 大会的内容丰富程度远超出这片文章所涵盖的范畴。特别是大会开设的创新体验专区，让我在自己感兴趣的领域也收获不少。举几个例子：
* WebXR 和游戏。我们知道，虽然 OpenHarmony 在底层能力上为 APP 开发者提供了强有力的渲染能力加持，但带给我惊喜的是，在华为浏览器里，同 Web 标准的对接也走得十分深入。我在现场体验了鸿蒙结合 cocos 引擎制作的 WebXR 互动游戏，虽然没有纵深效果，但是稳定性和性能还是不错的。
* 音视频智能制作，也就是 AIGC。从内部的 DEMO 应用来看，华为的音视频智能制作主要还是围绕多媒体模板以及配套的图形图像算法和模型来智能生成视频和处理后的图像。有一些调参的选项可供配置，但是更深层的联动还在开发中，期待后续的正式版。
* AR。根据现场体验，基于单摄像头视觉算法的效果，跟 iOS 的 LiDAR 技术加持的扫描效果，虽然速度上有一定的差距，但是效果还好（可能跟场地场景有关），比较超预期。
当然，这场技术盛宴给我的收获，除了对鸿蒙操作系统和其软件体系的深入了解，还有松山湖景区——华为的欧洲小镇带给每一位到访者的惬意——虽然立冬前几天经常细雨蒙蒙，却给人一种滋养万物的感觉。
总结
如果用一个词来总结这次的 HDC 的技术峰会，我会选择：成熟。
2019年，鸿蒙初现；
2020年，面向智能硬件生态伙伴发布全新品牌鸿蒙智联；
2021年，鸿蒙 2 推出，全面应用于智能手机等多种终端设备；
2022年，鸿蒙 3 如约而至。
一个 OS 的打造是要经历时间的历练，从 0 到 1 时，展现的是气魄，而从 1 到 100，需要的是定力。
我十分期待明年 Q1，鸿蒙 3.1 的发布会如约展示其日臻成熟的一面；我更期待，明年 HDC 的大会上，OpenHarmony 能更加夯实其基础能力，在不久的将来，成为移动 OS 的一枚坚实的鼎足，为移动应用提供一个出色的基座。
