鸿蒙UI概要分享

ZCurry
416 阅读17分钟

ArkUI简介

ArkUI（方舟UI框架）为应用的UI开发提供了完整的基础设施，包括简洁的UI语法、丰富的UI功能（组件、布局、动画以及交互事件），以及实时界面预览工具等，可以支持开发者进行可视化界面开发。

基本概念

  • UI： 即用户界面。开发者可以将应用的用户界面设计为多个功能页面，每个页面进行单独的文件管理，并通过页面路由API完成页面间的调度管理如跳转、回退等操作，以实现应用内的功能解耦。
  • 组件： UI构建与显示的最小单位，如列表、网格、按钮、单选框、进度条、文本等。开发者通过多种组件的组合，构建出满足自身应用诉求的完整界面。

两种开发范式

针对不同的应用场景及技术背景，方舟UI框架提供了两种开发范式，分别是基于ArkTS的声明式开发范式（简称“声明式开发范式”）和兼容JS的类Web开发范式（简称“类Web开发范式”）。

  • 声明式开发范式：采用基于TypeScript声明式UI语法扩展而来的ArkTS语言，从组件、动画和状态管理三个维度提供UI绘制能力。
  • 类Web开发范式：采用经典的HML、CSS、JavaScript三段式开发方式，即使用HML标签文件搭建布局、使用CSS文件描述样式、使用JavaScript文件处理逻辑。该范式更符合于Web前端开发者的使用习惯，便于快速将已有的Web应用改造成方舟UI框架应用。

在开发一款新应用时，推荐采用声明式开发范式来构建UI，主要基于以下几点考虑：

  • 开发效率： 声明式开发范式更接近自然语义的编程方式，开发者可以直观地描述UI，无需关心如何实现UI绘制和渲染，开发高效简洁。

  • 应用性能： 如下图所示，两种开发范式的UI后端引擎和语言运行时是共用的，但是相比类Web开发范式，声明式开发范式无需JS框架进行页面DOM管理，渲染更新链路更为精简，占用内存更少，应用性能更佳。

  • 发展趋势：声明式开发范式后续会作为主推的开发范式持续演进，为开发者提供更丰富、更强大的能力。

    图1 方舟UI框架示意图

    img

ArkTS声明式开发范式

基于ArkTS的声明式开发范式的方舟开发框架是一套开发极简、高性能、支持跨设备的UI开发框架，提供了构建应用UI所必需的能力，主要包括：

  • ArkTS

    ArkTS是优选的主力应用开发语言，围绕应用开发在TypeScript（简称TS）生态基础上做了进一步扩展。扩展能力包含声明式UI描述、自定义组件、动态扩展UI元素、状态管理和渲染控制。状态管理作为基于ArkTS的声明式开发范式的特色，通过功能不同的装饰器给开发者提供了清晰的页面更新渲染流程和管道。状态管理包括UI组件状态和应用程序状态，两者协作可以使开发者完整地构建整个应用的数据更新和UI渲染。ArkTS语言的基础知识请参考初识ArkTS语言。

  • 布局

    布局是UI的必要元素，它定义了组件在界面中的位置。ArkUI框架提供了多种布局方式，除了基础的线性布局、层叠布局、弹性布局、相对布局、栅格布局外，也提供了相对复杂的列表、宫格、轮播。

  • 组件

    组件是UI的必要元素，形成了在界面中的样子，由框架直接提供的称为系统组件，由开发者定义的称为自定义组件。系统内置组件包括按钮、单选框、进度条、文本等。开发者可以通过链式调用的方式设置系统内置组件的渲染效果。开发者可以将系统内置组件组合为自定义组件，通过这种方式将页面组件化为一个个独立的UI单元，实现页面不同单元的独立创建、开发和复用，具有更强的工程性。

  • 页面路由和组件导航

    应用可能包含多个页面，可通过页面路由实现页面间的跳转。一个页面内可能存在组件间的导航如典型的分栏，可通过导航组件实现组件间的导航。

  • 图形

    方舟开发框架提供了多种类型图片的显示能力和多种自定义绘制的能力，以满足开发者的自定义绘图需求，支持绘制形状、填充颜色、绘制文本、变形与裁剪、嵌入图片等。

  • 动画

    动画是UI的重要元素之一。优秀的动画设计能够极大地提升用户体验，框架提供了丰富的动画能力，除了组件内置动画效果外，还包括属性动画、显式动画、自定义转场动画以及动画API等，开发者可以通过封装的物理模型或者调用动画能力API来实现自定义动画轨迹。

  • 交互事件

    交互事件是UI和用户交互的必要元素。方舟开发框架提供了多种交互事件，除了触摸事件、鼠标事件、键盘按键事件、焦点事件等通用事件外，还包括基于通用事件进行进一步识别的手势事件。手势事件有单一手势如点击手势、长按手势、拖动手势、捏合手势、旋转手势、滑动手势，以及通过单一手势事件进行组合的组合手势事件。

  • 自定义能力

    自定义能力是UI开发框架提供给开发者对UI界面进行开发和定制化的能力。包括：自定组合、自定义扩展、自定义节点和自定义渲染。

特点

  • 开发效率高，开发体验好

    • 代码简洁：通过接近自然语义的方式描述UI，不必关心框架如何实现UI绘制和渲染。
    • 数据驱动UI变化：让开发者更专注自身业务逻辑的处理。当UI发生变化时，开发者无需编写在不同的UI之间进行切换的UI代码， 开发人员仅需要编写引起界面变化的数据，具体UI如何变化交给框架。
    • 开发体验好：界面也是代码，让开发者的编程体验得到提升。

  • 性能优越

    • 声明式UI前端和UI后端分层：UI后端采用C++语言构建，提供对应前端的基础组件、布局、动效、交互事件、组件状态管理和渲染管线。
    • 语言编译器和运行时的优化：统一字节码、高效FFI-Foreign Function Interface、AOT-Ahead Of Time、引擎极小化、类型优化等。

  • 生态容易快速推进

    能够借力主流语言生态快速推进，语言相对中立友好，有相应的标准组织可以逐步演进。

整体架构

图1 整体架构图

img

  • 声明式UI前端

    提供了UI开发范式的基础语言规范，并提供内置的UI组件、布局和动画，提供了多种状态管理机制，为应用开发者提供一系列接口支持。

  • 语言运行时

    选用方舟语言运行时，提供了针对UI范式语法的解析能力、跨语言调用支持的能力和TS语言高性能运行环境。

  • 声明式UI后端引擎

    后端引擎提供了兼容不同开发范式的UI渲染管线，提供多种基础组件、布局计算、动效、交互事件，提供了状态管理和绘制能力。

  • 渲染引擎

    提供了高效的绘制能力，将渲染管线收集的渲染指令，绘制到屏幕的能力。

  • 平台适配层

    提供了对系统平台的抽象接口，具备接入不同系统的能力，如系统渲染管线、生命周期调度等。

通用规则

  • 默认单位

    表示长度的入参单位默认为vp，即入参为number类型、以及Length和Dimension类型中的number单位为vp。

  • 异常值处理

    输入的参数为异常（undefined，null或无效值）时，处理规则如下：

    （1）对应参数有默认值，按默认值处理；

    （2）对应参数无默认值，该参数对应的属性或接口不生效。

img

布局

组件

路由

状态管理（V1稳定版）

在声明式UI编程框架中，UI是程序状态的运行结果，用户构建了一个UI模型，其中应用的运行时的状态是参数。当参数改变时，UI作为返回结果，也将进行对应的改变。这些运行时的状态变化所带来的UI的重新渲染，在ArkUI中统称为状态管理机制。

自定义组件拥有变量，变量必须被装饰器装饰才可以成为状态变量，状态变量的改变会引起UI的渲染刷新。如果不使用状态变量，UI只能在初始化时渲染，后续将不会再刷新。 下图展示了State和View（UI）之间的关系。

img

  • View(UI)：UI渲染，指将build方法内的UI描述和@Builder装饰的方法内的UI描述映射到界面。
  • State：状态，指驱动UI更新的数据。用户通过触发组件的事件方法，改变状态数据。状态数据的改变，引起UI的重新渲染。

基本概念

  • 状态变量：被状态装饰器装饰的变量，状态变量值的改变会引起UI的渲染更新。示例：@State num: number = 1,其中，@State是状态装饰器，num是状态变量。

  • 常规变量：没有被状态装饰器装饰的变量，通常应用于辅助计算。它的改变永远不会引起UI的刷新。以下示例中increaseBy变量为常规变量。

  • 数据源/同步源：状态变量的原始来源，可以同步给不同的状态数据。通常意义为父组件传给子组件的数据。以下示例中数据源为count: 1。

  • 命名参数机制：父组件通过指定参数传递给子组件的状态变量，为父子传递同步参数的主要手段。示例：CompA({ aProp: this.aProp })。

  • 从父组件初始化：父组件使用命名参数机制，将指定参数传递给子组件。子组件初始化的默认值在有父组件传值的情况下，会被覆盖。示例：

    @Componentstruct MyComponent {  @State count: number = 0;  private increaseBy: number = 1;
  build() {  }}
@Componentstruct Parent {  build() {    Column() {      // 从父组件初始化，覆盖本地定义的默认值      MyComponent({ count: 1, increaseBy: 2 })    }  }}

  • 初始化子组件：父组件中状态变量可以传递给子组件，初始化子组件对应的状态变量。示例同上。

  • 本地初始化：在变量声明的时候赋值，作为变量的默认值。示例：@State count: number = 0。

装饰器总览

ArkUI状态管理V1提供了多种装饰器，通过使用这些装饰器，状态变量不仅可以观察在组件内的改变，还可以在不同组件层级间传递，比如父子组件、跨组件层级，也可以观察全局范围内的变化。根据状态变量的影响范围，将所有的装饰器可以大致分为：

  • 管理组件拥有状态的装饰器：组件级别的状态管理，可以观察组件内变化，和不同组件层级的变化，但需要唯一观察同一个组件树上，即同一个页面内。
  • 管理应用拥有状态的装饰器：应用级别的状态管理，可以观察不同页面，甚至不同UIAbility的状态变化，是应用内全局的状态管理。

从数据的传递形式和同步类型层面看，装饰器也可分为：

  • 只读的单向传递；
  • 可变更的双向传递。

图示如下，具体装饰器的介绍，可详见管理组件拥有的状态和管理应用拥有的状态。开发者可以灵活地利用这些能力来实现数据和UI的联动。

img

上图中，Components部分的装饰器为组件级别的状态管理，Application部分为应用的状态管理。开发者可以通过@StorageLink/@LocalStorageLink实现应用和组件状态的双向同步，通过@StorageProp/@LocalStorageProp实现应用和组件状态的单向同步。

管理组件拥有的状态，即图中Components级别的状态管理：

  • @State：@State装饰的变量拥有其所属组件的状态，可以作为其子组件单向和双向同步的数据源。当其数值改变时，会引起相关组件的渲染刷新。
  • @Prop：@Prop装饰的变量可以和父组件建立单向同步关系，@Prop装饰的变量是可变的，但修改不会同步回父组件。
  • @Link：@Link装饰的变量可以和父组件建立双向同步关系，子组件中@Link装饰变量的修改会同步给父组件中建立双向数据绑定的数据源，父组件的更新也会同步给@Link装饰的变量。
  • @Provide/@Consume：@Provide/@Consume装饰的变量用于跨组件层级（多层组件）同步状态变量，可以不需要通过参数命名机制传递，通过alias（别名）或者属性名绑定。
  • @Observed：@Observed装饰class，需要观察多层嵌套场景的class需要被@Observed装饰。单独使用@Observed没有任何作用，需要和@ObjectLink、@Prop联用。
  • @ObjectLink：@ObjectLink装饰的变量接收@Observed装饰的class的实例，应用于观察多层嵌套场景，和父组件的数据源构建双向同步。

仅@Observed/@ObjectLink可以观察嵌套场景，其他的状态变量仅能观察第一层，

管理应用拥有的状态，即图中Application级别的状态管理：

  • AppStorage是应用程序中的一个特殊的单例LocalStorage对象，是应用级的数据库，和进程绑定，通过@StorageProp和@StorageLink装饰器可以和组件联动。
  • AppStorage是应用状态的“中枢”，将需要与组件（UI）交互的数据存入AppStorage，比如持久化数据PersistentStorage和环境变量Environment。UI再通过AppStorage提供的装饰器或者API接口，访问这些数据。
  • 框架还提供了LocalStorage，AppStorage是LocalStorage特殊的单例。LocalStorage是应用程序声明的应用状态的内存“数据库”，通常用于页面级的状态共享，通过@LocalStorageProp和@LocalStorageLink装饰器可以和UI联动。

其他状态管理V1功能

@Watch用于监听状态变量的变化。

$$运算符：给内置组件提供TS变量的引用，使得TS变量和内置组件的内部状态保持同步。

最佳实践

避免在自定义组件的生命周期内执行高耗时操作

图2 自定义组件生命周期流程图

点击放大

如上图所示，自定义组件创建完成之后，在build函数执行之前，将先执行aboutToAppear()生命周期回调函数。此时若在该函数中执行耗时操作，将阻塞UI渲染，增加UI主线程负担。因此，应尽量避免在自定义组件的生命周期内执行高耗时操作。对于复杂计算的耗时场景，可以将计算结果进行缓存处理。对于不需要等待结果的高耗时任务，可以采用多线程处理该任务，通过并发的方式避免主线程阻塞。在aboutToAppear()生命周期函数内建议只做当前组件的初始化逻辑，其他业务逻辑可以按需提前或延后处理。假设在首页视频列表中的子组件内需要初始化创建一个复杂播放器对象，该对象的创建非常耗时。若在该组件的aboutToAppear()函数中对创建该对象，当首页加载渲染时，列表内每个子组件的渲染都将等待相应的播放器对象初始化创建完成，此时页面加载将非常耗时甚至可能出现白屏。

  aboutToAppear(): void {
    // ❌反例：getStringSync接口的入参直接使用资源，未使用资源ID
    getContext().resourceManager.getStringSync($r('app.string.app_name'));
    // ✅推荐；
    getContext().resourceManager.getStringSync($r('app.string.app_name').id);
  }

结论：参数为资源信息时比参数为资源ID值时耗时更多。所以当需要使用类似方法时，使用资源ID值作为参数更优，可有效减少自定义组件生命周期耗时。

优先使用@Builder方法代替自定义组件

在应用开发时，减少自定义组件的使用，尤其是自定义组件在循环中的使用，将成倍减少FrameNode节点树上CustomNode节点数量，有效缩短页面的加载和渲染时长。当在应用中使用自定义组件时，可以优先考虑使用@Builder函数代替自定义组件，@Builder函数不会在后端FrameNode节点树上创建一个新的树节点。如，在使用ForEach循环展示卡片列表信息时，若卡片组件仅作展示，无需使用自定义组件的复杂能力如生命周期函数时，可以创建一个@Builder函数代替创建自定义卡片组件。

img

合理使用布局

  • 精简节点数，移除冗余的节点

  • 使用扁平化布局减少节点数

    0000000000011111111.20240822113813.08531691133865794381803962890204:50001231000000:2800:4157A696E2502D1EF241E993CC20C87BC107FF7C71441BF01D0053449C834300.png

  • 合理控制元素显示与隐藏

    建议遵循以下原则来选择使用控制方式：

    • 在对性能要求较高，并且会频繁切换元素的显示与隐藏的情况下，应该避免使用if条件判断，而改为通过visibility的属性控制，这样在切换Visibility.None和Visibility.Visible时，可以省去组件创建的时间，直接进入渲染过程。
    • 如果组件的创建非常消耗资源，且不会立即使用，也并非频繁切换交互的情况下，只在特定条件下才会出现时，可以通过if/else来进行内容的显示与隐藏控制，来达到懒加载的效果。

  • 合理使用布局容器

    相同布局深度和节点数，性能：Column/Row/Stack > Flex > Grid/GridItem/RelativeContainer

  • Scroll嵌套List场景下，给定List组件宽高

    Scroll嵌套List时：

    • List没有设置宽高时，List的所有子组件ListItem都会参与布局。
    • List设置宽高，只有布局区域内的ListItem子组件会参与布局。
    • List使用ForEach加载子组件时，无论是否设置List的宽高，都会加载所有子组件。
    • List使用LazyForEach加载子组件时，没有设置List的宽高，会加载所有子组件，设置了List的宽高，会加载List显示区域内的子组件。

  • 将自定义组件的属性移至自定义组件内部

    给自定义组件添加属性时，实际上是给自定义组件套了一层不可见的组件，而给自定义组件添加的属性，实际上也是绑定在这层不可见的组件上的。所以，给自定义组件添加属性与自定义组件内部添加属性二者相比，自定义组件内部添加属性会少一层不可见组件，使得总节点数量降低，从而可以提升性能。

    // 反例
@Component
export struct example {
  build() {
    Column() {
      // 自定义组件
      FlowListStruct({
        // 自定义组件传递参数
        ...
      }).backgroundColor('#FFFFFF')
    }
    .width('100%')
    .height('100%')
  }
}

状态管理最佳实践

在实际开发中，合理选择装饰器主要包含以下三步：

1.首先根据状态需要共享的范围大小，尽量选择共享能力小的装饰器方案，优先级依次为@State+@Prop、@State+@Link或@State+@Observed+@ObjectLink > @Provide+@Consume > LocalStorage > AppStorage。

2.当共享的状态的组件间层级相差较大时，为避免较差的代码可扩展性和可维护性，@Provide+@Consume的方案要优于层层传递的共享方案。

3.对于具有相同优先级的@State+@Prop、@State+@Link或@State+@Observed+@ObjectLink 三个方案，应结合状态的复杂程度和装饰器各自的特性选择。

实际开发中，应根据业务需求衡量优先级选择合适的装饰器，整体可参考如下建议：

  1. @State+@Prop：适合状态结构简单，且共享状态的组件间层级相差不大的场景。或功能上要求子组件不实时同步修改给父组件的场景。
  2. @State+@Link：适合状态结构复杂，且共享状态的组件间层级相差不大的场景。或功能上要求子组件对状态的修改实时同步给父组件的场景。
  3. @State+@Observed+@ObjectLink：适合需要观察嵌套类对象的子属性变化的场景或对象数组的数据项属性变化的场景，如监听列表卡片上某个属性的变化。
  4. @Provide+@Consume：适合用于对于整个组件树而言“全局”的状态，且该状态改动不频繁的状态共享场景，如共享界面的路由信息。
  5. AppStorage：适合对于整个应用而言“全局”的变量或应用的主线程内多个UIAbility实例间的状态共享，如用户信息。
  6. LocalStorage：适合对于单个Ability而言“全局”的变量，主要用于不同页面间的状态共享场景。

developer.huawei.com/consumer/cn…

参考

官方文档

avatar
文章
阅读
粉丝