鸿蒙（HarmonyOS）开发学习 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应用生态拓展，广大开发者加入进来，一起探索和创新，共建万物互联的应用生态。

未来将来，有迹可循！

更多的鸿蒙学习指南可以扫描下方二维码免费领取！！！

## 《鸿蒙（HarmonyOS）开发学习指南》

第一章 快速入门

1、开发准备

2、构建第一个ArkTS应用（Stage模型）

3、构建第一个ArkTS应用（FA模型）

4、构建第一个JS应用（FA模型）

5、…

第二章 开发基础知识

1、应用程序包基础知识

2、应用配置文件（Stage模型）

3、应用配置文件概述（FA模型）

4、…

第三章 资源分类与访问

1、 资源分类与访问

2、 创建资源目录和资源文件

3、 资源访问

4、…

第四章 学习ArkTs语言

1、初识ArkTS语言

2、基本语法

3、状态管理

4、其他状态管理

5、渲染控制

6、…

第五章 UI开发

1.方舟开发框架（ArkUI）概述

2.基于ArkTS声明式开发范式

3.兼容JS的类Web开发范式

4…

第六章 Web开发

1.Web组件概述

2.使用Web组件加载页面

3.设置基本属性和事件

4.在应用中使用前端页面JavaScript

5.ArkTS语言基础类库概述

6.并发

7…

11.网络与连接

12.电话服务

13.数据管理

14.文件管理

15.后台任务管理

16.设备管理

17…

第七章 应用模型

1.应用模型概述

2.Stage模型开发指导

3.FA模型开发指导

4…