写点什么

Stage 模型深入解读

  • 2023-03-15
    上海
  • 本文字数:4088 字

    阅读完需:约 13 分钟

Stage模型深入解读

HarmonyOS 3.1 版本(API 9)推出了全新应用开发模型-Stage 模型,该模型重新定义了应用开发的能力边界,从应用开发模型的角度,支持多窗口形态下统一的应用组件生命周期,并支持跨设备的迁移和协同机制。本文为大家详细介绍 Stage 模型。


一、Stage 模型概念

应用开发模型是运行在不同 OS 上的抽象结构。OS 通过这种抽象结构,把应用开发的基础设施封装在 OS 内部。开发者通过使用应用开发模型,复用 OS 基础设施的能力,达到高效开发应用的目的。


1、什么是 Stage 模型

Stage 模型提供面向对象的开发方式,规范化了进程创建的方式,提供组件化开发机制,将组件抽象为 UIAbility 和 ExtensionAbility 两大类。UIAbility 组件的生命周期包含创建、销毁、前台、后台状态,将与界面强相关的获焦、失焦状态都放在窗口管理对象中,从而实现 UIAbility 与窗口之间的弱耦合;在服务侧,窗口管理服务依赖于组件管理服务,前者通知后者前后台变化,这样组件管理服务仅感知前后台变化,不感知焦点变化。ExtensionAbility 组件提供场景化的服务扩展机制,不提供自定义服务的能力。


相比于 FA 模型,Stage 模型提供了更灵活的开发方式,更低的内存占用和更规范化的系统管理机制。

未来 HarmonyOS 将在兼容 FA 模型的基础上,持续演进 Stage 模型。


FA 模型与 Stage 模型对比图


2、Stage 模型能力特点


Stage 模型能力示意图


Stage 模型的设计,是为了提供给开发者一个更好的开发方式,更好的适用于多设备、分布式场景。

Stage 模型的三大能力特点:


1)原生支持组件级的迁移和协同

Stage 模型的组件天生具备分布式迁移和协同的能力,它是 HarmonyOS 支持分布式能力在应用模型上的体现。


应用组件支持跨设备的数据恢复:

充分使用 ArkUI 的声明式 UI 和多页面的能力,把数据/状态保存在 UIAbility 组件实例中,逻辑修改数据,数据驱动 UI 变化。多设备间迁移 UIAbility,就是迁移 UIAbility 的数据/状态。在目标设备上通过数据/状态来恢复 UI,实现逻辑与 UI 的解耦,提升了流转开发效率。


应用组件支持跨设备的远程调用:

UIAbility 组件支持跨设备拉起另外一个设备上同名应用的同名组件实例。系统在拉起过程中,通过底层软总线的能力在两个组件实例之间建立跨设备的 RPC 连接,开发者在获取 RPC 接口后,即可进行跨设备通信,适用于应用在设备间交互的场景。


2)支持多设备形态和多窗口形态

在桌面设备上,窗口可以最大化/最小化/任意改变窗口大小,窗口间可以任意切换焦点,接收用户输入。在移动设备上,基本以全屏窗口为主,窗口之间构成栈结构,只有顶层窗口才能接收用户输入。如何在不同窗口形态的设备上,提供统一的组件模型呢?Stage 模型分离了 UIAbility 生命周期和窗口显示/焦点事件,使得窗口的焦点切换不影响 UIAbility 组件的状态。


UIAbility 的前后台状态和窗口的全屏/最小化的关系如下:

只有当窗口最小化的时候,UIAbility 组件进入后台状态,否则 UIAbility 组件处于前台状态;

当一个窗口全屏的时候,触发其他窗口最小化(可以根据产品形态确定全屏窗口个数)。


在桌面设备和移动设备的交互体验不同的情况下,系统通过实施上述规则,可以保证 UIAbility 组件的生命周期定义在多设备上保持一致。同时,不论在桌面设备还是移动设备,都遵循每个新的 UIAbility 组件实例都会创建一个任务,所以也保证了任务(Mission)机制在多设备上的一致性。


3)重新定义应用能力边界

通常情况下,应用如果可自行决定创建多少个进程、自定义服务时,系统为保证用户体验,需要在后台运行管控、进程关联启动等方面对应用的运行状态进行强管理,从而降低系统总体的内存占用和功耗开销。

Stage 模型基于场景的服务扩展、严格的后台管控机制和受限的进程模型,重新定义了应用能力边界,使进程环境从“无序”到“有序”,规范了进程管理模型。


二、Stage 模型介绍

基于 Stage 模型开发应用,下面将会从应用组件、进程模型、线程模型、任务模型、后台运行机制、应用配置文件 6 个方面进行介绍。


1、组件模型

应用开发模型中需要指明应用开发的入口。在 HarmonyOS 上,应用组件是应用开发的入口,同时也是运行时入口。用户启动、使用和退出应用过程中,应用组件会在不同的状态间切换,这些状态称为应用组件的生命周期。应用组件提供生命周期的回调函数,开发者通过应用组件的生命周期回调感知应用的状态变化。


Stage 模型组件类型


Stage 模型提供了 UIAbility 和 ExtensionAbility 两种类型的组件。

1) UIAbility 组件是一种包含 UI 界面的应用组件,主要用于和用户交互。UIAbility 的生命周期只包含创建/销毁/前台/后台等状态,通过 WindowStage 的事件暴露显示相关的状态。每个 UIAbility 组件都会有一个主窗口与之绑定,如果开发者希望开发复杂的页面和动效,我们推荐开发者使用 ArkUI 的多页面能力。


UIAbility 支持跨设备拉起同名组件,并与之协同交互的能力。


2)ExtensionAbility 组件是一种面向特定场景的应用组件,系统在特定场景下启动该组件为用户提供服务。开发者并不直接从 ExtensionAbility 派生,而是从 ExtensionAbility 的派生类派生。目前 ExtensionAbility 有用于卡片场景的 FormExtensionAbility 和用于输入法场景的 InputMethodExtensionAbility 等多种派生类。在 Stage 模型上,普通应用开发者不能开发自定义服务,也不支持开发者直接启动 ExtensionAbility,包括开发者自己编写的 ExtensionAbility。


2、进程模型


进程模型示意图


Stage 模型有三类进程,是从系统总体资源占用考虑,希望由系统负责应用进程的创建和销毁。所以不支持应用自定义配置多进程,也不支持通过接口启动进程。


1)主进程

开发者编写的 UIAbility 入口及其依赖的代码都在该进程中运行。它是由 UIAbility 组件的启动触发创建的。


2)ExtensionAbility 进程

开发者编写的同一种类型的 ExtensionAbility 组件实例都会在同一个进程中运行。不同类型的 ExtensionAbility 组件实例则在不同的进程中运行。该类进程是由系统服务在特定场景下创建,并根据用户对特定场景的使用,决定其何时销毁。同时该类进程独立于主进程创建,并且不支持与主进程之间进行 IPC 通信。


3)Render 进程

为了支持 WebView 的运行,每个应用只能创建一个 Render 进程用于运行 WebView 的渲染引擎。这个 Render 进程也是由系统负责创建和销毁。


3、线程模型

HarmonyOS 的原生应用开发语言为 ArkTS。在应用进程启动时,系统会在主线程上创建一个 ArkTS 的虚拟机实例,然后加载和执行应用的入口代码。应用组件的生命周期回调,输入事件的分发,ArkUI 的布局等操作都会在主线程上执行,所以我们推荐开发者不要在主线程上执行单次耗时过长的操作,否则容易引发卡顿。


ArkTS 通过提供 Worker API 支持并发编程。Worker 有独立的虚拟机上下文,它与主线程是两个不同的虚拟机上下文。它们之间通过 postMessage API 进行通信。这种基于消息传递的并发模型与基于锁的并发模型不同,需要开发者特别注意。


4、任务模型

用户在操作应用的过程中,经常需要对已经操作过的应用进行切换,这些操作记录(不同 OS 的操作对象定义可能不同)经常被称为任务。应用任务管理模型需要定义任务的操作对象,以及任务创建和销毁的方式和时机。


在 HarmonyOS 上,每次用户启动一个新的 UIAbility 组件实例,都会生成一个新的任务(Mission)。例如,用户启动一个视频应用后,切换到“任务中心”界面,将会看到视频应用这个任务,当用户点击这个任务时,系统会把该任务切换到前台,如果这个视频应用中的视频编辑功能也是通过应用组件编写的,那么在用户启动视频编辑功能时,会创建视频编辑的应用组件实例,在“任务中心”界面中,将会展示视频应用、视频编辑两个任务。


任务(Mission)中记录了组件和快照的信息,并在系统中持久化。即使任务对应的组件实例销毁,任务仍然存在。如果用户从任务中心中选择某个任务,任务对应的组件实例会被拉到前台并获焦,如果它对应的组件实例已经销毁,系统会创建一个新的组件实例与之对应。


开发者在用户交互设计上需要特别注意,避免产生过多的任务。如果开发者希望使用多个页面交互,推荐使用 ArkUI 的页面栈能力。


HarmonyOS 的任务模型不提供任务栈的能力,每个应用可以有多个任务在任务中心呈现,不同应用的任务不会以栈的形式堆叠在一起,避免了不同应用间任务混淆不清的情况。


5、后台运行机制


后台运行示意图


当应用的所有前台 UIAbility 组件都进入后台的时候,系统认为该应用进入后台。应用在后台运行的机制对设备续航影响很大。HarmonyOS 后台运行机制的设计初衷是希望应用进程在系统规则范围内运行,并使用户可感知,避免应用进程在后台运行,而用户不感知的情况。我们提供了如下几种后台任务(Task):


1)短时任务

系统每天会给申请了短时任务的应用分配一定的后台运行配额。


2)长时任务

系统定义了若干种后台长时运行的任务类型,开发者需要在应用的配置文件中配置,并需要上架审核。这样该应用在设备上后台运行的时候,就可以保持长时间运行,同时系统会通过用户可感知的 UI 提示用户有后台进程正在运行。例如导航,录音,音乐等场景。


3)无任务

默认情况下,应用不申请任何后台运行方式,则会在应用进程进入后台 10 秒钟后被冻结挂起,应用无法收到外部非用户操作事件。


4)闲时任务

对于一些 CPU 密集型,且对实时性要求不高的任务,比如科学计算等场景,系统提供了闲时任务机制。例如设备充电等适当的时机向应用提供后台运行的能力,开发者可以通过 Work-SchedulerExtensionAbility 使用该机制,系统会根据当前的系统状态和用户使用频次决策唤醒时机。


5)托管任务

对于一些可以托管给系统执行的任务。比如下载等场景,系统提供代理任务的 API,由系统代理实现任务,应用进程会处于冻结状态。


6、应用配置文件

Stage 模型提供了全新的应用配置文件,它包含应用信息、应用组件信息、权限信息、开发者自定义信息等,这些信息在编译构建、分发和运行阶段分别提供给编译工具、应用市场和操作系统使用。


Stage 应用模型是 HarmonyOS 应用开发的基础架构,它从组件模型、面向对象开发方式、进程/线程模型等方面对 FA 模型进行了全面的优化,提高了应用开发效率。后续我们将在应用模型的基础设施、大型应用开发、拓展应用形态、跨设备能力和性能体验等方面继续打磨,支撑 HarmonyOS 应用生态拓展,广大开发者加入进来,一起探索和创新,共建万物互联的应用生态。


未来将来,有迹可循!



用户头像

每一位开发者都是华为要汇聚的星星之火 2021-10-15 加入

提供HarmonyOS关键技术解析、版本更新、开发者实践和活动资讯,欢迎各位开发者加入HarmonyOS生态,一起创造无限可能!

评论

发布
暂无评论
Stage模型深入解读_HarmonyOS_HarmonyOS开发者_InfoQ写作社区