Harmony(鸿蒙)Stage模型综述

设计思想

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

​Stage模型的设计思想如下图所示。

​Stage模型的设计基于如下三个出发点：

• 应用进程的有序管理

随着设备的内存越来越大，系统中同时运行的进程数量也越来越多。当数百个进程同时运行时，如果没有有效的管理措施，则系统整体的功耗和性能将无法得到保证。Stage模型中，通过短时任务、长时任务、托管任务和延迟任务四种方法对后台进程做了有序约束。这样做使得前台进程的资源得以保障，最终能获得更好的用户体验。

• 原生支持跨端迁移和多端协同

OpenHarmony是原生分布式的操作系统，应用框架需要从架构设计上使得组件更易于实现跨端迁移和多端协同。Stage模型通过Ability与UI分离及UI展示与服务能力合一等模型特性，实现这一设计目标。

• 支持多种设备的不同窗口形态

Stage模型重新定义了Ability的生命周期。系统在架构上，将应用组件管理服务和窗口管理服务进行了彼此解耦，这样做可以方便的针对特定设备进行适配，以实现出不同的窗口形态。

基本概念

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

• HAP：OpenHarmony应用编译、分发、加载的基本单位。与开发态的module一一对应。在应用内，moduleName是其唯一标识；
• Bundle：通过appid标识的OpenHarmony应用，Bundle可以包含多个HAP，每个应用都有一个bundleName，但是bundleName并不能唯一标识一个应用，appid中包含bundleName以及其他的更多信息，能够唯一标识一个应用；
• AbilityStage：对应HAP的运行期对象，在HAP首次加载到进程中时创建，运行期开发者可见；
• Application：对应Bundle的运行期对象，运行期开发者不可见；
• Context：提供运行期开发者可以调用的各种