00. 简介
本文档基于 OpenHarmony 2.2 Beta2 源码的 L2 设备部分编写。
因鸿蒙系统目前处在快速发展时期,本文中的一些内容可能会过时,建议在阅读的同时参考最新代码以了解更实时的知识。
Ability 子系统实现了对 Ability 的运行及生命周期进行统一的调度和管理,应用进程能够支撑多个 Ability,Ability 具有跨应用进程间和同一进程内调用的能力。Ability 管理服务统一调度和管理应用中各 Ability,并对Ability的生命周期变更进行管理。
该子系统在 OpenHarmony 架构中的位置见下图中红框 (这里有意增加了红框的尺寸,因为其内部逻辑除了 Ability 框架外,还包含了部分用户程序框架与系统服务层的内容)。对于应用进程来说,Ability 子系统是与之关系最紧密的核心系统模块。
OpenHarmony 架构图:
01.基础知识
Ability 子系统的架构如下图所示。可以看到其分两个模块,其中 Ability Kit 模块位于 User Process (用户进程),而 AbilityManagerService 模块位于 Service Layer (服务层)。这两个模块内部由多个相关联的子模块组成。
Ability 子系统架构图:
要理解 Ability 框架,需要先了解以下概念:
0) Ability
Ability 是系统调度应用的最小单元,是能够完成一个独立功能的组件,一个应用可以包含一个或多个 Ability。
Ability 分为 FA (Feature Ability) 和 PA (Particle Ability) 两种类,其中 FA 支持 Page Ability,PA 支持 Service Ability 和 Data Ability。
1) Ability 生命周期
Ability 生命周期 (Ability Life Cycle) 是 Ability 被调度到 INACTIVE \ ACTIVE \ BACKGROUND 等各个状态的统称 (主要涉及 PageAbility 类型和 ServiceAbility 类型的 Ability)。
PageAbility 类型的 Ability 生命周期流转如下图所示:
ServiceAbility 类型的 Ability 生命周期流转如下图所示:
如果希望了解更详细的关于 Ability 的知识,可以搜索参阅关于鸿蒙 Ability 的其他文档。我们之后也会编写一些详解 Ability 的文档并分享。
2) 服务层
服务层 (Service Layer) 的各模块运行在 OpenHarmony 的各系统进程中,用于与底层交互并支撑上层框架层的功能,其通过 IPC 调用的方式与用户进程相互传递信息。
Ability 子系统在服务层的模块为 AbilityManagerService。
3) 用户进程
用户进程 (User Process)是指 OpenHarmony 上层的应用进程,包括系统应用与三方应用等,各应用一般运行在独立的用户进程中。用户进程包含框架层的各模块逻辑,其通过框架层的接口以 IPC 调用的方式使用服务层的系统服务。
02. 类间关系
本段将展示服务层和用户进程两部分的 Ability 子系统类关系图。
在学习 Ability 子系统的类图之前,我们应先了解 OpenHarmony 的 IPC 调用框架图,这是各系统服务工作的基础机制之一。
0) IPC 框架
目前 OpenHarmony 尚未在源码全面使用 IDL 来生成 IPC 调用接口。各系统服务暂时采用人工编写的方式来定义服务接口,主要的类之间的关系见下图:
IPC 框架图 (UML)
标黄的四个部分是编写服务时需要实现的四个类:
- Interface 是一个抽象基类,不能实例化,其用于定义跨进程调用的各函数的名字 \ 参数以及返回类型;
- Proxy 类继承了 IRemoteProxy
类,其内部实现了 Client 端的各函数,将参数序列化,并通过 IPC 驱动传递到 Server 端,并接收 Server 端的返回值; - Stub 类继承了 IRemoteStub
类,但其仍是抽象类,不能实例化,其内部实现了将 Client 端传来的数据反序列化,传递给对应函数,并将返回值序列化,并通过 IPC 驱动传递到 Client 端; - Service 类继承了 Stub 类,这是 Server 端的业务核心类,用于实现各接口的真正逻辑。
因代码量比较多,这里只做简要介绍。如果希望详细了解 IPC 框架的机制与实现,我们将来也会编写并分享相关文档。
1) 服务层
Ability 子系统在系统服务进程中的类间关系如下图,标绿色的类是整个流程的核心类,蓝色的框体代表与外部模块进行交互,粉色的类代表跨进程调用的接口类:
Ability 子系统服务层 (UML)
核心类:
AbilityManagerService:
此类是 Ability 子系统的系统服务的总管。该类实现了 IAbilityManager 的 Stub 的所有接口,用以执行来自用户进程的 IPC 调用。
Ability 子系统服务的各功能由各子模块 (Manager) 负责,而 AbilityManagerService 中则包含了各子模块的实例。
当执行相应的 IPC 调用时,AbilityManagerService 会调用相应的子模块的函数进行处理,并将结果通过 IPC 返回给调用方。
AbilityRecord:
此类是应用 Ability 在系统服务中的映射。该类持有 IAbilityScheduler 的 Proxy 对象,用以对相应 Ability 所在进程进行 IPC 调用。
前文已介绍,Ability 是应用程序的最核心的组件,当应用的 Ability 在使用时,其会在系统服务中产生一个对应的 AbilityRecord 对象,记录了该 Ability 的属性和状态,AbilityRecord 对象由 AbilityManagerService 管理,当需要操作 \ 调度 Ability 时,就会调用相应的 AbilityRecord 的函数,并通过 IAbilityScheduler 的 Proxy 调用到用户进程,使用户进程做出响应动作 (如生命周期切换等)。
组成 AbilityManagerService 的重要模块:
AppScheduler:
此类调用 AppMgrClient 中的接口,用以与用户进程框架 (AppManager) 模块进行交互,Ability 所属的用户进程即由 AppManager 管理。
AbilityManagerService 持有此类的实例,用以进行与 AppManager 系统服务间的交互。
AbilityStackManager:
此类掌管所有 FA (Feature Ability),即 Page Ability。
FA 的可见性 \ 层次结构等状态由该 Manager 进行计算和调度,并对相应的 AbilityRecord 进行操作。
AbilityConnectManager:
此类掌管所有 PA (Particle Ability) 中的 Service Ability。
Service Ability 的连接 \ 生命周期等状态由该 Manager 进行计算和调度,并对相应的 AbilityRecord 进行操作。
DataAbilityManager:
此类掌管所有 PA (Particle Ability) 中的 Data Ability。
Data Ability 的连接 \ 加载等逻辑由该 Manager 进行计算和调度,并对相应的 AbilityRecord 进行操作。
其他主要类:
MissionRecord:
此类对应了名为 Mission 的逻辑概念,属于同一个逻辑栈的 Page Ability 合为一个 Misson,这些 Ability 的 AbilityRecord 会以栈的形式保存在相应的 MissionRecord 中。
MissionRecord 中的 AbilityRecord 顺序即是 Mission 中的 Ability 存在顺序,该顺序与 Ability 的进入和退出逻辑相关。
MissionStack:
此类对应了名为 Stack 的逻辑概念,属于同一个显示区域的 Mission 合为一个 Stack,这些 Mission 的 MissionRecord 会以栈的形式保存在相应的 MissionStack 中。
要注意的是,MissionStack 中的 MissionRecord 与 Mission 的顺序无关,每个 MissionRecord 会保存其自身的顺序关系。
各 MissionStack 实例保存在 AbilityStackManager 中,由 AbilityStackManager 进行管理。
ConnectionRecord:
当 Service Ability 被以 connectAbility() 的方式连接时,会在系统层产生一个 ConnectionRecord 对象。ConnectionRecord 用以记录和控制该 Connection 的数据与状态。
各 ConnectionRecord 实例保存在 AbilityConnectManager 中,由 AbilityConnectManager 进行管理。
DataAbilityRecord:
当 Data Ability 被调用时,会在系统层产生一个 DataAbilityRecord 对象。DataAbilityRecord 用以记录和控制该 Data Ability 的数据与状态。
各 DataAbilityRecord 实例保存在 DataAbilityManager 中,由 AbilityConnectManager 进行管理。
2) 用户进程
Ability 子系统在用户进程中的类间关系如下图,标绿色的类是整个流程的核心类,蓝色的框体代表与外部模块进行交互,粉色的类代表跨进程调用的接口类:
Ability 子系统用户进程 (UML)
核心类:
AbilityThread:
此类是 Ability 在用户进程中的总管,该类实现了 IAbilityScheduler 的 Stub 的所有接口,用以执行来自系统服务的 IPC 调用。
当执行相应的 IPC 调用时,AbilityThread 会对该 Ability 的数据与状态进行处理,并将结果通过 IPC 返回给调用方。
Ability:
该类是应用程序的各 Ability 的基类,含有 Ability 运作时所需要的各用户进程中的数据,并定义了各生命周期切换时的回调接口。
Ability 继承了 AbilityContext 类,AbilityContext 是一个 Context 类,其功能是与系统环境进行交互,可以获取和改变一些与应用有关的属性值。
Ability 的实例被构建在 AbilityThread 对象中。
与 AbilityThread \ Ability 交互紧密的重要类:
AbilityHandler:
该类是一个 EventHandler 类,其绑定了该应用进程的主 EventRunner,用以执行应用的主消息循环。
Ability 的主要操作都会 post 到此 EventHandler 循环中完成。
AbilityHandler 的实例被构建在 AbilityThread 对象中。
AbilityImpl (DataAbilityImpl \ PageAbilityImpl \ ServiceAbilityImpl):
该类用以直接控制对应的 Ability 的操作和状态。对于三种不同类型的 Ability,AbilityImpl 派生出三种不同的派生类 (DataAbilityImpl \ PageAbilityImpl \ ServiceAbilityImpl),用以差异处理这三类 Ability。
AbilityThread 的实例被构建在 AbilityThread 对象中。
AbilityLoader:
该类用以保存各 Ability 的构建函数,当通过相应的 Ability 的名称来构建时,会由 AbilityLoader 来查询并调用其构建函数。
AbilityLoader 使用了单例模式,在用户进程中只有一个实例。
AbilityWindow:
该类是 Window 对象的派生类,用以控制对应 Ability 的图形界面方面的逻辑,与 OpenHarmony 的图形子系统进行间接交互。
AbilityWindow 会随者 Ability 的构建而构建,其实例存于对应的 Ability 对象中。
其他主要类:
MainThread:
该类用于管理应用进程的数据和状态,是应用程序的核心类。该类实现了 IAppScheduler 的 Stub 的所有接口,用以执行来自系统服务的 IPC 调用。
MainThread 并不属于 Ability 子系统,而属于用户程序框架子系统,但该类与 Ability 子系统关系密切。
Ability 子系统的各类对象 (如 AbilityThread) 的管理,以及 Ability 的创建等流程,都由此类处理。
AbilityRecordMgr:
该类存放了所属应用进程的所有 AbilityThread 对象,AbilityThread 被封装在 LocalAbilityRecord 类中,并以 map 的形式存储于 AbilityRecordMgr 中。
AbilityRecordMgr 同样是用户程序框架子系统的一部分,其实例存储在 MainThread 类中。
AbilityManagerClient:
该类是与 AbilityManagerService 交互的桥梁,其持有 IAbilityManager 的 Proxy 对象,用以对 AbilityManagerService 所属的系统进程进行 IPC 调用。
该类被 AbilityContext 等众多类使用,用来调用 AbilityManagerService 的各接口,以执行控制系统服务或获取系统服务状态的逻辑。
03. 总结
Ability 子系统是支撑鸿蒙应用程序运行的核心模块,对于系统开发者\ 应用开发者来说,都很有必要去深入了解。
本文档对 Ability 子系统的功能和结构做了介绍,由于该模块代码量较多,逻辑较复杂,该讲解也仅是在框架层面,未深究其细节。
如果希望了解更多有关 Ability 子系统的知识,敬请期待我们后续将要分享的 《OpenHarmony 源码解析之 Ability 子系统 (一)》,在这篇我们会挑选一些 Ability 子系统的局部流程进行详细讲解。