OpenHarmony开源鸿蒙学习入门–Ability和Stage基本概念理解

Ability是什么？

在OpenHarmony中，Ability是应用所具备能力的抽象，也是应用程序的重要组成部分。Ability是系统调度应用的最小单元，是能够完成一个独立功能的组件，一个应用可以包含一个或多个Ability。 类似Android中的Application和Activity的融合。

了解过商业鸿蒙，HarmonyOS的同学应该会很熟悉Ability。作为本是同根生的两个系统，不管是在框架上还是在组件定义上都有很强的相似性。但是也需要注意，两者还是有区别的，一定不能混淆。

FA和Stage又是什么？

在OpenHarmony中，Ability框架模型结构具有两种形态，FA和Stage：
需要注意的是，这两种模型，会导致项目包结构不同，所以一定要确认好使用哪种类型。

（1）FA模型
第一种形态为FA模型。API 8及其更早版本的应用程序只能使用FA模型进行开发。

FA模型将Ability分为FA（Feature Ability）和PA（Particle Ability）两种类型，其中FA支持Page Ability，PA支持Service Ability、Data Ability、以及FormAbility；

PageAbility是具备ArkUI实现的Ability，是用户具体可见并可以交互的Ability实例；ServiceAbility也是Ability一种，但是没有UI，提供其他Ability调用自定义的服务，在后台运行；DataAbility也是没有UI的Ability，提供其他Ability进行数据的增删查服务，在后台运行；FormAbility是卡片Ability，是一种界面展示形式。

FA模型的包结构：

（2）Stage模型

第二种形态为Stage模型。从API 9开始，Ability框架引入了Stage模型作为第二种应用形态。

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

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

应用的能力与系统总体功能和功耗的平衡​在系统运行过程中，前台应用的资源占用会被优先保障，与此同时由于应用能力不同而产生的功耗，也需要符合系统整体功耗的要求。Stage模型通过Ability与UI分离、严格的后台管控、基于场景的服务机制及单进程模型来达成这种应用能力与整体系统功耗的平衡。原生支持组件级的迁移和协同OpenHarmony是原生支持分布式的操作系统，应用框架需要从架构设计上使得组件更易于实现迁移和协同。Stage模型通过Ability与UI分离及UI展示与服务能力合一等模型特性，实现这一设计目标。支持多设备和多窗口形态的特点为了支持多种设备形态和更易于实现多种不同的窗口形态，需要组件管理服务和窗口管理服务在架构层面上是解耦的，从而方便裁剪，更有利于定制不同的窗口形态。Stage模型通过重新定义了Ability生命周期定义和设计组件管理服务和窗口管理服务的单项依赖解决这一问题。

Stage模型的设计，主要是为了方便开发者更加方便地开发出分布式环境下的复杂应用。

FA和Stage两种模型的差异？

下表给出了两种模型在设计上的差异：

（1）进程线程共享的区别:
FA进程线程模型

应用独享独立进程，Ability独享独立线程，应用进程在Ability第一次启动时创建，并为启动的Ability创建线程，应用启动后再启动应用内其他Ability，会为每一个Ability创建相应的线程。每个Ability绑定一个独立的JSRuntime实例，因此Ability之间是隔离的。

（2）Ability类型存在差异；

（3）Ability生命周期存在差异；