HarmonyOS鸿蒙Next面向万物智联的应用框架的思考和探索（下）

HarmonyOS鸿蒙Next面向万物智联的应用框架的思考和探索（下） 原文：https://mp.weixin.qq.com/s/tH1WcAhWwxmfU2FxKnT4ew，点击链接查看更多技术内容。

应用框架，是操作系统连接开发者生态，实现用户体验的关键基础设施。其中，开发效率和运行体验是永恒的诉求，业界也在持续不断的发展和演进。

本文重点围绕移动应用框架，梳理其关键发展脉络，并分析其背后的技术演进思路以及目前的局限；同时，进一步结合万物智联的新场景和新生态，围绕相应的应用框架的设计和演进，分享个人在这个领域的思考，实践，以及下一步探索。

“万物皆有裂缝，那是光照进来的地方”– 莱昂纳德 · 科恩

1、具体案例分析：ArkUI开发框架的实践，探索和演进

2019年，我们开始思考如何构建新一代应用框架，重点围绕极简开发，高能效比，跨设备以及跨平台这几个关键的设计目标，逐步演进出ArkUI以及相配套的语言，API等能力，并形成了鸿蒙生态主推的开发框架。接下来的内容将以ArkUI作为一个具体案例，来说明这块相关的实践，探索和演进。

1.1 整体概览

ArkUI是一套声明式开发框架，它具备简洁自然的UI信息语法、丰富的UI组件、多维状态管理，以及实时多维度预览等能力，帮助开发者提升应用开发效率，并能在多种设备实现生动而流畅的用户体验。同时可进一步扩展到多个OS平台。下图描述了ArkUI开发框架的整体视图：

ArkUI的关键特征如下所示：

a. 简洁自然的声明式语法； b. 高效的渲染管线以及平台一致性的渲染机制； c. 高效的方舟编译器以及运行时； d. 统一的跨平台API能力集以及扩展机制。

1.2 关键组成

ArkUI的关键组成包括以下几个方面：ArkTS语言以及相应的声明式范式；UI关键能力（布局、组件、动效以及自适应、自定义能力）；渲染管线；ArkTS编译器&运行时；可部署到轻量级设备的轻量化运行时；以及推动应用开发的生态融合设计。接下来分别展开说明。

1.2.1 ArkTS语言&声明式范式

ArkTS在TS(TypeScript)的基础上，扩展了声明式UI、状态管理等相应的能力，让开发者通过更简洁、更自然的方式开发高性能应用。

下面结合一个具体的示例，从应用开发的角度简要描述下基于ArkTS的声明式范式。

上图所示的代码示例，UI界面会显示一个 “Hello World” 的文本以及一个 “Click me” 按钮。当用户点击“Click me”按钮时，字符串变量 myText 的值会从“World” 变为“ACE ”，文本最终显示为 “Hello ACE”。

这个示例中所包含的ArkUI声明式开发范式的基本组成说明如下：

• 装饰器：用来装饰类、结构体、方法以及变量，赋予其特殊的含义，如上述示例中@Entry、@Component、@State都是装饰器。具体而言，@Component表示这是个自定义组件；@Entry则表示这是个入口组件；@State表示组件中的状态变量，这个状态变化会引起相应的 UI的自动刷新。
• 自定义组件：可复用的 UI 单元，可组合其它组件，如上述被@Component 装饰的Struct Hello。
• UI 描述：声明式的方式来描述 UI 的结构，如上述 build() 方法内部的代码块。
• 内置组件：框架中默认内置的基础和布局组件，可直接被开发者调用，比如示例中的 Column、Text、Divider、Button。
• 事件方法：用于添加组件对事件的响应逻辑，统一通过事件方法进行设置，如跟随在Button后面的onClick()。
• 属性方法：用于组件属性的配置，统一通过属性方法进行设置，如fontSize()、width()、height()、color() 等，可通过链式调用的方式设置多项属性。

具体而言，ArkTS在TS的基础上，做了以下几个方面的增强：

• 3.2.1.1 简洁自然的组件化描述机制

这里主要包括通过Struct定义的自定义组件名字；通过build()方法提供的自定义组件的内容（可基于系统的内置组件，或其他自定义组件来自由组合）；以及通用的装饰器机制（以@开始的描述符）。具体到自定义组件而言，则是通过@Component装饰器来装饰的自定义组件类型，以便其他组件来使用。同时，还定义了组件的生命周期相关的回调函数。这些共同定义了自定义组件的基础设施。

• 3.2.1.2 多维状态管理机制

状态管理主要是实现数据到UI的自动映射，以实现数据驱动UI的自动变更。上面例子中的通过@State装饰的myText即是状态管理的最简单的一种情况。实际应用开发中，则是需要多维度的状态管理。下图显示了ArkTS所涉及的状态管理的整体视图，主要也是通过相关的装饰器来完成。

一个应用可以有多个页面，每个页面可以有多个组件，不同组件之间可以有相互关联。另外，数据的来源以及影响范围也可以有所不同。为此我们定义了不同维度的状态管理，来处理不同的场景。

状态管理的范围可以是组件内，组件间，页面级(LocalStorage)，应用级(AppStorage)；组件间可以是父子组件间的逐层传递，也可以是爷孙组件间跨层传递；传递方式可以单向传递（@Prop）或是双向传递（@Link）;数据的类型可以是简单类型，也可以是复杂类型；数据的来源/存储可以来自内存，持久化存储，环境参数，还可以是跨设备的分布式数据。这些构建了应用开发中所需的状态管理的基础设施，并简化了跨设备场景下的应用开发。

• 3.2.1.3 动态扩展组合机制

前面的组件化描述，状态管理机制，再配合内置组件构建了UI的基础设施。某些场景下，还需要UI描述能够动态扩展以及组合，比如基于自定义DSL（Domain Specific Language）动态的内容构建以及刷新场景，典型的案例是京东的MCube, 阿里巴巴的手淘的DynamicX等。为此，我们进一步扩展了ArkTS的语义，通过@Extend装饰器根据具体场景来动态添加/扩展组件的属性，通过@Builder装饰器来动态组合不同的组件，从而实现运行时动态构建UI视图的目标。

具体案例分析细节，可看参考资料:京东APP Open-Harmony 化的跨端开发探索：

https://www.51cto.com/article/715754.html

另外，有关ArkTS的起源和演进，可以看参考资料: 浅析eTS的起源和演进 (注：eTS是ArkTS的前称)

https://mp.weixin.qq.com/s/N2RPeboN8Fj0-8wBMZJ-7w

1.2.2 内置组件、自定义机制、动效、多设备适配

上述的ArkTS以及声明式范式的基础介绍只是描述了声明式UI的基础语法以及基础框架，如果要完成完整的UI能力则还需要其他关键组成，包括各种内置组件（容器组件、基础组件等），动效，以及自适应，自定义能力等。ArkUI在基础的图形Surface之上，构建了一整套的UI体系。

1.2.2.1 内置组件（容器组件，基础组件等）

ArkUI内置组件大致分为以下几种类型：

• 容器组件类：包括横向布局，纵向布局，堆叠布局，相对布局容器，二维的网格类型布局等；以及常用的滚动列表（横向，纵向），侧边栏容器等；
• 基础组件类：包括按钮，文本，检查框，选择框，进度条，导航等；
• 画布组件类：包含基础画布，各类线条形状路径等；
• 媒体&高级组件类：包含图片，视频等；富文本，Web组件，xComponent自绘制组件等；

通过这些内置组件以及相应的属性、事件处理能力的不同设置和组合，来覆盖应用开发中UI的典型场景。

1.2.2.2 自定义机制

ArkTS的组件化描述机制，动态扩展组合机制，加上各种内置组件，构成了自定义组件的基础，再配合基础画布/xComponent等自绘制能力，可以构建出常用场景的组件。不过，某些场景下，开发者还需要更细粒度的定制化能力，比如自定义测量/布局以实现任意形状的布局，以及在现有组件进一步定制化和扩展等。下图描述了ArkUI的自定义布局的基本流程：

如图所示，其中的onMeasure以及onLayout是框架层提供给应用开发者的接口，供开发者自定义具体的组件测量方法以及基于测量结果的布局机制，以实现任何的布局，比如瀑布流布局，环状布局等等。整体运行时流程大致如下：渲染管线触发渲染流程->触发动效->触发布局->调用开发者实现OnMeasure函数，由开发者实现测量逻辑，由ArkTS侧调用框架层相应子组件measure接口->调用开发者实现OnLayout函数，开发者实现布局逻辑，设置所有子组件位置，由ArkTS侧调用框架层相应子组件layout接口->触发渲染。

不过，更灵活的自定义能力，比如在现有组件实现方法/属性级的定制化和扩展，更便捷的自绘制能力等方面还需进一步完善。

1.2.2.3 动效

动效，即动画效果，本质上它也是一种状态驱动的UI变更。具体而言，动效是在起始状态和终止状态之间，加入了基于时间的显示效果的平滑过渡。

从作用的对象角度，动效一般包括组件本身的动效（比如各种属性变化引起的动效），转场动效（组件增减/移动，页面之间转场，共享元素在页面间转场）；从开发的方式角度，包括隐式动效（通过设置相应的参数自动触发），显式动效（通过显示调用动画接口来指定由于闭包代码导致的状态变化插入过渡动效）。

ArkUI提供了上述场景所需的动效能力，通过结合相应的状态变量，相关联的UI组件/页面，以及相应的时序曲线算法函数来共同完成。

应用通过提供的声明式动画接口，进行动画业务逻辑组织；通过状态更新监听器，监听绑定动画的属性；动画对象提供动画参数存储能力的数据结构，包括动画持续时间、动画曲线、延迟时间等。组件树提供真实组件渲染节点，包含平移、旋转、缩放等效果渲染节点。动画引擎提供动画驱动能力。最终触发节点的重新绘制，通过渲染引擎进行界面更新。

ArkUI动效相关能力目前还比较基础，相关时序/效果算法的丰富度，以及动效的细粒度控制/自定义能力等都在持续增强演进中。

1.2.2.4 多设备适配（界面自适应，交互自适应等）

ArkUI围绕多设备适配提供了系统化的多层次的解决方案。下图显示了其中的关键内容。

如图所示，UI维度的多设备适配从上到下分为三个层次：场景样例，布局能力，视觉交互：

• 场景样例：联合用户体验设计对常用组件的组合场景作出定义和输出样例代码，包含：顶部、入口、分栏、瀑布流、Banner、视频列表、视频宫格、图文、图片详情等；
• 布局能力：包含响应式能力：响应式组件（List 、Navigation、Grid、Swiper、Tabs、栅格布局组件），响应式能力（栅格系统、自定义断点系统、媒体查询）；以及自适应能力：常用自适应组件+自适应能力（隐藏、延伸、缩放、均分、占比、拉伸、折行）等；
• 视觉交互：包含分层参数/主题风格：支持多设备上采用不同的主题风格，深浅主题，自定义主题样式等，满足应用的个性化皮肤; 多态组件：支持统一的组件描述，不同的设备呈现效果；交互归一：屏蔽设备差异统一交互逻辑，把不同的设备的交互输入集合进行统一的事件归类定义，然后控件完成对应的统一响应。

在配套开发工具方面，通过DevEco IDE（Integrated Development Environment）的实时多设备预览等相关能力，进一步降低多设备开发成本。

当然，完整的应用的多设备适配还需结合相应系统的能力，比如系统能力的运行期识别判断，应用的模块化打包分发，以及面向不同设备的弹性部署等。

完整内容，可看参考资料：鸿蒙生态应用开发白皮书

https://developer.huawei.com/consumer/cn/doc/harmonyos-bps?ha_source=wd&ha_sourceId=89000070

1.2.3 渲染管线

ArkUI整体渲染管线流程主要包括ArkTS源代码通过相应的编译工具链编译成中间代码（其间会使用到ArkUI的框架API），方舟运行时运行相应的字节码（也可以是AOT后的代码），最终通过ArkUI框架运行时完成完整的渲染流程。

上图显示了主要的渲染流程，其中有几个关键特征：

1. 扁平化的按需组合的渲染管线。通过声明式UI前后端的融合设计，开发范式中的UI描述基本可以直接映射到后端组件。同时，后端组件的相关属性基于组合式按需构建，进一步提升构建速度并降低内存开销；
2. 数据依赖的自动收集。开发者只需通过相关的装饰器修饰好状态变量， ArkUI框架则会结合语言的相关特性（属性代理等机制）来自动识别并构建相应的依赖，实现相应的渲染刷新；
3. 通过方舟编译器以及运行时基于类型的编译优化以及AOT机制，实现语言执行性能的进一步提升。

在上述基础上，2022年，ArkUI渲染架构又做了进一步升级：

如上图所示，渲染架构主要进行了以下三个方面的升级：

1. 多节点按需组合模型→单节点+属性按需组合模型

原先架构下组件树构建时，同一组件的不同属性是通过基础节点叠加相应的格外属性的节点来按需构建，复杂场景下这容易造成节点过多从而引起性能以及内存负担。新的架构下实现了单节点模型，附加按需的属性集合以及相应任务处理器，从而大幅降低节点树的层级。另外，通过对相关任务处理器的分离，也为后续进一步的细粒度并行化改造打下了相应的基础。

1. 数据依赖组件级更新→细粒度函数级更新

原先架构下数据依赖只是跟踪到了自定义组件层级。新的架构下引入了最小化更新机制，对自定义组件中的build函数进一步分解为细粒度的函数的组合，并实现了将数据依赖直接定位到相应的子节点上，从而实现更精细化的更新，进一步提升UI更新效率。

1. 三颗树→一颗树

原先架构下多棵树存在的主要目的是实现差量比较更新。通过最小化更新机制的引入，差量比较就不是必要的，同时，再结合数据结构重构，可在相关节点上生成渲染信息，这样原先的三颗树合并成了一棵树，进一步提升了组件渲染速度并降低内存。

1.2.4 方舟编译器&运行时

方舟编译器&运行时的关键目标是要实现可对标静态类型语言（比如Swift/Java/Kotlin）的性能体验，以及和声明式框架深度融合从而实现高效的声明式开发。

![业界JS/TS的典型性能问题](https