鸿蒙中的stage模型（新手必看）

Stage 是 HarmonyOS 3.1（API 9）版本开始新增的模型，也是目前 HarmonyOS 主推且会长期演进的模型。

在 Stage 模型中，由于提供了 AbilityStage、WindowStage 等类作为应用组件和 Window 窗口的“舞台”，因此称这种应用模型为 Stage 模型。

Stage模型的设计思想

Stage 模型之所以成为主推模型，源于其设计思想。Stage 模型的设计基于如下 3 个出发点。

1) 为复杂应用而设计

简化应用复杂度：

• 多个应用组件共享同一个ArkTS引擎（运行ArkTS语言的虚拟机）实例，应用组件之间可以方便地共享对象和状态，同时减少复杂应用运行对内存的占用。
• 采用面向对象的开发方式，使得复杂应用代码可读性高、易维护性好、可扩展性强。

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

应用组件管理和窗口管理在架构层面解耦：

• 便于系统对应用组件进行裁剪（无屏设备可裁剪窗口）；
• 便于系统扩展窗口形态；
• 在多设备（如桌面设备和移动设备）上，应用组件可使用同一套生命周期。

3) 平衡应用能力和系统管控成本

Stage 模型重新定义了应用能力的边界，以平衡应用能力和系统管控成本：

• 提供特定场景（如卡片、输入法）的应用组件，以便满足更多的使用场景；
• 规范化后台进程管理：为保障用户体验，Stage 模型对后台应用进程进行了有序治理，应用程序不能随意驻留在后台，同时应用后台行为受到严格管理，防止恶意应用行为。

Stage模型的基本概念

如下图所示展示了 Stage 模型中的基本概念。

1) AbilityStage

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

2) UIAbility组件和ExtensionAbility组件

Stage 模型提供 UIAbility 和 ExtensionAbility 两种类型的组件，这两种组件都有具体的类承载，支持面向对象的开发方式。

① UIAbility 组件是一种包含 UI 的应用组件，主要用于和用户交互。

例如，图库类应用可以在 UIAbility 组件中展示图片瀑布流，在用户选择某个图片后，在新的页面中展示图片的详细内容。同时用户可以通过返回键返回到瀑布流页面。

UIAbility 组件的生命周期只包含创建、销毁、前台、后台等状态，与显示相关的状态通过 WindowStage 的事件暴露给开发者。

② ExtensionAbility 组件是一种面向特定场景的应用组件。开发者并不能直接从 ExtensionAbility 组件派生，而是需要使用 ExtensionAbility 组件的派生类。

目前 ExtensionAbility 组件有用于卡片场景的 FormExtensionAbility，用于输入法场景的 InputMethodExtensionAbility，用于闲时任务场景的 WorkSchedulerExtensionAbility 等多种派生类，这些派生类都是基于特定场景提供的。

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

3) WindowStage

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

4) Context

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