HarmonyOS（二）Ability应用模型概述

目录

1 Ability概念

2 Ability形态

3 Stage优势

4 Stage模型结构

5 总结

---

注：本章内容提前声明。

基于HarmonyOS开发者3.1/4.0版本配套的开发者文档，对应API能力级别为API 9 Release。

详情可参考官网API入门第一章应用模型文档中心

---

1 Ability概念

Ability是应用所具备能力的抽象，也是应用程序的基本组成部分。主要包括组建生命周期回调、系统环境变化通知、应用跳转、卡片开发等能力。

---

2 Ability形态

随着系统的演进发展，HarmonyOS先后提供了两种应用模型：

• FA（Feature Ability）模型：HarmonyOS（API8及早期）开始支持的模型，已经不再主推。

• Stage模型：HarmonyOS 3.1 Developer Preview版本（API9）开始新增的模型，是目前主推且会长期演进的模型。在该模型中，由于提供了AbilityStage、WindowStage等类作为应用组件和Window窗口的“舞台”，因此称这种应用模型为Stage模型。

---

3 Stage优势

Stage模型与FA模型最大的区别在于：Stage模型中，多个应用组件共享同一个ArkTS引擎实例；而FA模型中，每个应用组件独享一个ArkTS引擎实例。

因此在Stage模型中，应用组件之间可以方便的共享对象和状态，同时减少复杂应用运行对内存的占用。

Stage模型作为主推的应用模型，开发者通过它能够更加便利地开发出分布式场景下的复杂应用。 

---

4 Stage模型结构

Stage模型中的应用组件是由ability这个基础概念演变而来。Stage模型提供UIAbility和ExtensionAbility两种类型的组件，都有具体的类承载，支持面向对象的开发方式。

UIAbility组件是一种包含UI界面的应用组件，主要负责用户界面和用户交互。

例如，图库类应用可以在UIAbility组件中展示图片瀑布流，在用户选择某个图片后，在新的页面中展示图片的详细内容。同时用户可以通过返回键返回到瀑布流页面。UIAbility的生命周期只包含创建/销毁/前台/后台等状态，与显示相关的状态通过WindowStage的事件暴露给开发者。

ExtensionAbility组件是负责UIAbility之外的事情，一种面向特定场景的应用组件。开发者并不直接从ExtensionAbility派生，而是需要使用ExtensionAbility的派生类。目前ExtensionAbility有用于卡片场景的FormExtensionAbility，用于闲时任务场景的WorkSchedulerExtensionAbility等多种派生类，这些派生类都是基于特定场景提供的。

例如，用户在桌面创建应用的卡片，需要应用开发者从FormExtensionAbility派生，实现其中的回调函数，并在配置文件中配置该能力。ExtensionAbility派生类实例由用户触发创建，并由系统管理生命周期。在Stage模型上，普通应用开发者不能开发自定义服务，而需要根据自身的业务场景通过ExtensionAbility的派生类来实现。

---

其他类了解：

• WindowStage

  每个UIAbility类实例都会与一个WindowStage类实例绑定，WindowStage类起到了应用进程内窗口管理器的作用，它包含一个主窗口。也就是说，UIAbility通过WindowStage持有了一个窗口，该窗口为ArkUI提供了绘制区域。

• Context

  在Stage模型上，Context及其派生类向开发者提供在运行期可以调用的各种能力。UIAbility组件和各种ExtensionAbility派生类都有各自不同的Context类，他们都继承自基类Context，但是各自又根据所属组件，提供不同的能力。

• AbilityStage

  每个Entry类型或者Feature类型的HAP在运行期都有一个AbilityStage类实例，当HAP中的代码首次被加载到进程中的时候，系统会先创建AbilityStage实例。

---

5 总结

综上所述，通过了解Ability的概念及Stage模型后，后面章节会再详细解决UIAbility的开发使用。另外，预留一个问题，大家思考🤔：UIAbility与方舟框架ArkUI之间的关系。