OpenHarmony 源码解析之 Ability子系统 (零) 原创 精华

作者：郭雨
 

1 简介

本文档基于 OpenHarmony 2.2 Beta2 源码的 L2 设备部分编写因鸿蒙系统目前处在快速发展时期，本文中的一些内容可能会过时，建议在阅读的同时参考最新代码以了解更实时的知识。

 

Ability 子系统实现了对 Ability 的运行及生命周期进行统一的调度和管理，应用进程能够支撑多个 Ability，Ability 具有跨应用进程间和同一进程内调用的能力。Ability 管理服务统一调度和管理应用中各 Ability，并对Ability的生命周期变更进行管理。

该子系统在 OpenHarmony 架构中的位置见下图中红框 (这里有意增加了红框的尺寸，因为其内部逻辑除了 Ability 框架外，还包含了部分用户程序框架与系统服务层的内容)。对于应用进程来说，Ability 子系统是与之关系最紧密的核心系统模块。

1.1 OpenHarmony 架构图

2 基础知识

Ability 子系统的架构如下图所示。可以看到其分两个模块，其中 Ability Kit 模块位于 User Process (用户进程)，而 AbilityManagerService 模块位于 Service Layer (服务层)。这两个模块内部由多个相关联的子模块组成。

Ability 子系统架构图

要理解 Ability 框架，需要先了解以下概念：

2.1 Ability

Ability 是系统调度应用的最小单元，是能够完成一个独立功能的组件，一个应用可以包含一个或多个 Ability。

Ability 分为 FA (Feature Ability) 和 PA (Particle Ability) 两种类，其中 FA 支持 Page Ability，PA 支持 Service Ability 和 Data Ability。

2.2 Ability 生命周期

Ability 生命周期 (Ability Life Cycle) 是 Ability 被调度到 INACTIVE \ ACTIVE \ BACKGROUND 等各个状态的统称 (主要涉及 PageAbility 类型和 ServiceAbility 类型的 Ability)。

• PageAbility 类型的 Ability 生命周期流转如下图所示：

• ServiceAbility 类型的 Ability 生命周期流转如下图所示：

如果希望了解更详细的关于 Ability 的知识，可以搜索参阅关于鸿蒙 Ability 的其他文档。我们之后也会编写一些详解 Ability 的文档并分享。

2.3 服务层

服务层 (Service Layer) 的各模块运行在 OpenHarmony 的各系统进程中，用于与底层交互并支撑上层框架层的功能，其通过IPC调用的方式与用户进程相互传递信息。

Ability 子系统在服务层的模块为 AbilityManagerService。

2.4 用户进程

用户进程 (User Process)是指OpenHarmony上层的应用进程，包括系统应用与三方应用等，各应用一般运行在独立的用户进程中。用户进程包含框架层的各模块逻辑，其通过框架层的接口以 IPC 调用的方式使用服务层的系统服务。

3 类间关系

本段将展示服务层和用户进程两部分的 Ability 子系统类关系图。

在学习 Ability 子系统的类图之前，我们应先了解 OpenHarmony 的 IPC 调用框架图，这是各系统服务工作的基础机制之一。

3.1 IPC 框架

目前 OpenHarmony 尚未在源码全面使用 IDL 来生成 IPC 调用接口。各系统服务暂时采用人工编写的方式来定义服务接口，主要的类之间的关系见下图：

IPC 框架图 (UML)

标黄的四个部分是编写服务时需要实现的四个类：

0. Interface 是一个抽象基类，不能实例化，其用于定义跨进程调用的各函数的名字 \ 参数以及返回类型；

1. Proxy 类继承了 IRemoteProxy<Interface> 类，其内部实现了 Client 端的各函数，将参数序列化，并通过 IPC 驱动传递到 Server 端，并接收 Server 端的返回值；

2. Stub 类继承了 IRemoteStub<Interface> 类，但其仍是抽象类，不能实例化，其内部实现了将 Client 端传来的数据反序列化,传递给对应函数，并将返回值序列化，并通过 IPC 驱动传递到 Client 端；

3. Service 类继承了 Stub 类，这是 Server 端的业务核心类，用于实现各接口的真正逻辑。

因代码量比较多，这里只做简要介绍。如果希望详细了解 IPC 框架的机制与实现，我们将来也会编写并分享相关文档。

3.2 服务层

Ability 子系统在系统服务进程中的类间关系如下图，标绿色的类是整个流程的核心类，蓝色的框体代表与外部模块进行交互，粉色的类代表跨进程调用的接口类：

Ability 子系统服务层 (UML)

核心类：

0. AbilityManagerService：

   此类是 Ability 子系统的系统服务的总管。该类实现了IAbilityManager的 Stub 的所有接口，用以执行来自用户进程的 IPC 调用。

   Ability 子系统服务的各功能由各子模块 (Manager) 负责，而 AbilityManagerService 中则包含了各子模块的实例。

   当执行相应的 IPC 调用时，AbilityManagerService 会调用相应的子模块的函数进行处理，并将结果通过 IPC 返回给调用方。

 

1. AbilityRecord：

   此类是应用 Ability 在系统服务中的映射。该类持有 IAbilityScheduler 的 Proxy 对象，用以对相应 Ability 所在进程进行 IPC 调用。

   前文已介绍，Ability 是应用程序的最核心的组件，当应用的 Ability 在使用时，其会在系统服务中产生一个对应的 AbilityRecord 对象，记录了该 Ability 的属性和状态，AbilityRecord 对象由 AbilityManagerService 管理，当需要操作 \ 调度 Ability 时，就会调用相应的 AbilityRecord 的函数，并通过 IAbilityScheduler 的 Proxy 调用到用户进程，使用户进程做出响应动作 (如生命周期切换等)。

    

组成 AbilityManagerService 的重要模块：

0. AppScheduler：

   此类调用 AppMgrClient中的接口，用以与用户进程框架 (AppManager) 模块进行交互，Ability 所属的用户进程即由 AppManager 管理。

   AbilityManagerService 持有此类的实例，用以进行与 AppManager 系统服务间的交互。

    

1. AbilityStackManager：

   此类掌管所有 FA (Feature Ability)，即 Page Ability。

   FA 的可见性 \ 层次结构等状态由该 Manager 进行计算和调度，并对相应的 AbilityRecord 进行操作。

    

2. AbilityConnectManager：

   此类掌管所有 PA (Particle Ability) 中的 Service Ability。

   Service Ability 的连接 \ 生命周期等状态由该 Manager 进行计算和调度，并对相应的 AbilityRecord 进行操作。

    

3. DataAbilityManager：

   此类掌管所有 PA (Particle Ability) 中的 Data Ability。

   Data Ability 的连接 \ 加载等逻辑由该 Manager 进行计算和调度，并对相应的 AbilityRecord 进行操作。

    

其他主要类：

0. MissionRecord：

   此类对应了名为 Mission 的逻辑概念，属于同一个逻辑栈的 Page Ability 合为一个 Misson，这些 Ability 的 AbilityRecord 会以栈的形式保存在相应的 MissionRecord 中。

   MissionRecord 中的 AbilityRecord 顺序即是 Mission 中的 Ability 存在顺序，该顺序与 Ability 的进入和退出逻辑相关。

    

1. MissionStack：

   此类对应了名为 Stack 的逻辑概念，属于同一个显示区域的 Mission 合为一个 Stack，这些 Mission 的 MissionRecord 会以栈的形式保存在相应的 MissionStack 中。

   要注意的是，MissionStack 中的 MissionRecord 与 Mission 的顺序无关，每个 MissionRecord 会保存其自身的顺序关系。

   各 MissionStack 实例保存在 AbilityStackManager 中，由 AbilityStackManager 进行管理。

    

2. ConnectionRecord：

   当 Service Ability 被以connectAbility()的方式连接时，会在系统层产生一个ConnectionRecord对象。ConnectionRecord 用以记录和控制该 Connection 的数据与状态。

   各ConnectionRecord实例保存在AbilityConnectManager中，由 AbilityConnectManager 进行管理。

    

3. DataAbilityRecord：

   当 Data Ability 被调用时，会在系统层产生一个 DataAbilityRecord 对象。DataAbilityRecord 用以记录和控制该 Data Ability 的数据与状态。

   各 DataAbilityRecord 实例保存在 DataAbilityManager 中，由 AbilityConnectManager 进行管理。

 

3.3 用户进程

Ability 子系统在用户进程中的类间关系如下图，标绿色的类是整个流程的核心类，蓝色的框体代表与外部模块进行交互，粉色的类代表跨进程调用的接口类：

Ability 子系统用户进程 (UML)

核心类：

0. AbilityThread：

   此类是 Ability 在用户进程中的总管，该类实现了 IAbilityScheduler 的 Stub 的所有接口，用以执行来自系统服务的IPC调用。

   当执行相应的 IPC 调用时，AbilityThread 会对该 Ability 的数据与状态进行处理，并将结果通过IPC返回给调用方。

    

1. Ability：

   该类是应用程序的各 Ability 的基类，含有 Ability 运作时所需要的各用户进程中的数据，并定义了各生命周期切换时的回调接口。

   Ability 继承了 AbilityContext 类，AbilityContext 是一个 Context 类，其功能是与系统环境进行交互，可以获取和改变一些与应用有关的属性值。

   Ability 的实例被构建在AbilityThread对象中。

    

与 AbilityThread \ Ability 交互紧密的重要类：

0. AbilityHandler：

   该类是一个 EventHandler 类，其绑定了该应用进程的主 EventRunner，用以执行应用的主消息循环。

   Ability 的主要操作都会 post 到此 EventHandler 循环中完成。

   AbilityHandler 的实例被构建在 AbilityThread 对象中。

    

1. AbilityImpl (DataAbilityImpl \ PageAbilityImpl \ ServiceAbilityImpl)：

   该类用以直接控制对应的 Ability 的操作和状态。对于三种不同类型的 Ability，AbilityImpl 派生出三种不同的派生类 (DataAbilityImpl \ PageAbilityImpl \ ServiceAbilityImpl)，用以差异处理这三类 Ability。

   AbilityThread 的实例被构建在 AbilityThread 对象中。

    

2. AbilityLoader：

   该类用以保存各 Ability 的构建函数，当通过相应的 Ability 的名称来构建时，会由 AbilityLoader 来查询并调用其构建函数。

   AbilityLoader 使用了单例模式，在用户进程中只有一个实例。

 

3. AbilityWindow：

   该类是 Window 对象的派生类，用以控制对应 Ability 的图形界面方面的逻辑，与 OpenHarmony 的图形子系统进行间接交互。

   AbilityWindow 会随者 Ability 的构建而构建，其实例存于对应的 Ability 对象中。

    

其他主要类：

0. MainThread：

   该类用于管理应用进程的数据和状态，是应用程序的核心类。该类实现了 IAppScheduler 的 Stub 的所有接口，用以执行来自系统服务的 IPC 调用。

   MainThread 并不属于 Ability 子系统，而属于用户程序框架子系统，但该类与 Ability 子系统关系密切。

   Ability 子系统的各类对象 (如 AbilityThread) 的管理，以及 Ability 的创建等流程，都由此类处理。

    

1. AbilityRecordMgr：

   该类存放了所属应用进程的所有 AbilityThread 对象，AbilityThread 被封装在 LocalAbilityRecord 类中，并以 map 的形式存储于 AbilityRecordMgr 中。

   AbilityRecordMgr 同样是用户程序框架子系统的一部分，其实例存储在 MainThread 类中。

    

2. AbilityManagerClient：

   该类是与 AbilityManagerService 交互的桥梁，其持有 IAbilityManager 的 Proxy 对象，用以对 AbilityManagerService 所属的系统进程进行 IPC 调用。

   该类被 AbilityContext 等众多类使用，用来调用 AbilityManagerService 的各接口，以执行控制系统服务或获取系统服务状态的逻辑。

4 总结

Ability 子系统是支撑鸿蒙应用程序运行的核心模块，对于系统开发者\ 应用开发者来说，都很有必要去深入了解。
 
本文档对 Ability 子系统的功能和结构做了介绍，由于该模块代码量较多，逻辑较复杂，该讲解也仅是在框架层面，未深究其细节。
 
如果希望了解更多有关 Ability 子系统的知识，敬请期待我们后续将要分享的 《OpenHarmony 源码解析之 Ability 子系统 (一)》，在这篇我们会挑选一些 Ability 子系统的局部流程进行详细讲解。

 
文中绘制图片有压缩，故而打包放置附件内

更多原创内容请关注：开鸿 HarmonyOS 学院

入门到精通、技巧到案例，系统化分享HarmonyOS开发技术，欢迎投稿和订阅，让我们一起携手前行共建鸿蒙生态。