用户程序框架

用户程序框架是操作系统对应用程序架构的抽象，在鸿蒙系统中，Ability 是应用最基本的抽象单位，是能够完成一个独立功能的应用组件，Ability 可能有用户界面（PA），也可能没有用户界面仅执行后台功能，这由其具体的子类型决定。

FA 模型

FA 模型：自鸿蒙系统早期版本就有的模型，适合简单应用。。FA模型将Ability分为FA（Feature Ability）和PA（Particle Ability）两种类型，其中FA支持Page Ability，PA支持Service Ability、Data Ability、以及FormAbility。

有三个子 类型的 Ability：

• PageAbility：负责用户界面与用户交互。
• ServiceAbility：负责后台服务。
• DataAbiltity：负责数据存储。

Stage 模型

Stage 模型：是为了解决FA模型无法解决的开发场景问题，方便开发者更加方便地开发出分布式环境下的复杂应用。自 API9 新增的模型。是日后长期演进的模型。

Stage模型将Ability分为PageAbility和ExtensionAbility两大类，其中ExtensionAbility又被扩展为ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility等一系列ExtensionAbility，以便满足更多的使用场景。

Stage 模型的设计出发点

支持多设备和多窗口形态的特点

在系统运行过程中，前台应用的资源占用会被优先保障，与此同时由于应用能力不同而产生的功耗，也需要符合系统整体功耗的要求。Stage模型通过Ability与UI分离、严格的后台管控、基于场景的服务机制及单进程模型来达成这种应用能力与整体系统功耗的平衡。为了保障用户体验，鸿蒙系统上的运行环境对后台应用进行 了有序治理，应用程序不能随意驻留在后台。系统定义了四类后台任务：

支持多设备和多窗口形态的特点

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

支持多设备和多窗口形态：

为了支持多种设备形态和更易于实现多种不同的窗口形 态，需要组件管理服务和窗口管理服务在架构层面上是解耦的，从而方便裁剪，更 有利于定制不同的窗口形态。Stage 模型通过重新定义 Ability 生命周期定义，设计 组件管理服务和窗口管理服务的单向依赖来解决这一问题。

Stage 模型与 FA 模型差异

对比	FA模型	Stage模型
开发方式	提供类Web的API，UI开发与Stage模型一致。	提供面向对象的开发方式，UI开发与FA模型一致。
引擎实例	每个进程内的每个Ability实例独享一个JS VM引擎实例。	每个进程内的多个Ability实例共享一个JS VM引擎实例。
包描述文件	不支持。	支持。
开发方式	使用config.json描述HAP包和组件信息，组件必须使用固定的文件名。	使用module.json5描述HAP包和组件信息，可以指定入口文件名。
组件	提供PageAbility(页面展示)，ServiceAbility(服务)，DataAbility(数据分享)以及FormAbility(卡片)。	提供Ability(页面展示)、Extension(基于场景的服务扩展)。

总结

Stage 模型与 FA 模型最大的区别在于：Stage 模型中多个应用组件共享同一个虚拟机， 而 FA 模型中，每个应用组件独享一个虚拟机。Stage 模型作为鸿蒙系统的主要应用编程模型，开发者通过它能够更加便 利地开发出分布式场景下的复杂应用。其主要优势包括：

• 为复杂应用设计：多应用组件在运行时共享同一个虚拟机引擎，从而减少复杂应用 运行内存的占用。采用面向对象的开发方式，使得复杂应用代码可读性高、易维护、扩展性强。
• 程序逻辑与用户界面解耦：窗口部分可单独销毁和重建，窗口与 Ability 可跨设备运行，Ability 可在不启动界面的情况下响应请求。
• 开放的扩展能力点：支持卡片、输入法、快捷开关、分享、壁纸、长时任务等应用开发。

与 FA 模型相同的是 Stage 模型中的应用组件也是由 Ability 这个基础概念演化而来。在 Stage 模型中，有两类 Ability：

• UIAbility：负责用户界面和用户交互。
• ExtensionAbility：负责 UIAbility 之外的事情。事实上，ExtensionAbility 有很多的 具体类型，例如：FormExtension