鸿蒙应用开发之应用模型

应用模型

应用模型可以理解为HarmonyOS为开发者提供的应用程序开发规范，组织文件入口设置、生命周期、进程线程服务、配置项内容等，具有必备的组件和运行机制，让开发者在统一的模型进行应用开发，更简单、高效。

按照华为官方的说法，应用模型可以称为用户程序框架，是操作系统对应用程序架构的抽象，在鸿蒙系统中，Ability 是应用最基本的抽象单位，是能够完成一个独立功能的应用组件，Ability 可能有用户界面（PA），也可能没有用户界面仅执行后台功能。

FA 模型

FA 模型：HarmonyOS API 7开始支持的模型，适合简单应用。FA模型将Ability分为FA（Feature Ability）和PA（Particle Ability）两种类型，其中FA支持Page Ability，PA支持Service Ability、Data Ability、以及FormAbility。

有三个子 类型的 Ability：

PageAbility：负责用户界面与用户交互。

ServiceAbility：负责后台服务。

DataAbiltity：负责数据存储。

Stage 模型

Stage 模型：是为了解决FA模型无法解决的开发场景问题，方便开发者更加方便地开发出分布式环境下的复杂应用。HarmonyOS API 9开始新增的模型，是目前主推且会长期演进的模型。

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 模型作为鸿蒙系统的主要应用编程模型，开发者通过它能够更加便 利地开发出分布式场景下的复杂应用。