OpenHarmony源码解析之Ability子系统(零)

开发 前端
因鸿蒙系统目前处在快速发展时期,本文中的一些内容可能会过时,建议在阅读的同时参考最新代码以了解更实时的知识。

[[424757]]

想了解更多内容,请访问:

51CTO和华为官方合作共建的鸿蒙技术社区

https://harmonyos.51cto.com

 00. 简介

本文档基于 OpenHarmony 2.2 Beta2 源码的 L2 设备部分编写。

因鸿蒙系统目前处在快速发展时期,本文中的一些内容可能会过时,建议在阅读的同时参考最新代码以了解更实时的知识。

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

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

OpenHarmony 架构图:

OpenHarmony 源码解析之 Ability子系统 (零)-鸿蒙HarmonyOS技术社区

01.基础知识

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

Ability 子系统架构图:

OpenHarmony 源码解析之 Ability子系统 (零)-鸿蒙HarmonyOS技术社区

要理解 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 生命周期流转如下图所示:

OpenHarmony 源码解析之 Ability子系统 (零)-鸿蒙HarmonyOS技术社区

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

OpenHarmony 源码解析之 Ability子系统 (零)-鸿蒙HarmonyOS技术社区

如果希望了解更详细的关于 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)

OpenHarmony 源码解析之 Ability子系统 (零)-鸿蒙HarmonyOS技术社区

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

  • Interface 是一个抽象基类,不能实例化,其用于定义跨进程调用的各函数的名字 \ 参数以及返回类型;
  • Proxy 类继承了 IRemoteProxy 类,其内部实现了 Client 端的各函数,将参数序列化,并通过 IPC 驱动传递到 Server 端,并接收 Server 端的返回值;
  • Stub 类继承了 IRemoteStub 类,但其仍是抽象类,不能实例化,其内部实现了将 Client 端传来的数据反序列化,传递给对应函数,并将返回值序列化,并通过 IPC 驱动传递到 Client 端;
  • Service 类继承了 Stub 类,这是 Server 端的业务核心类,用于实现各接口的真正逻辑。

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

1) 服务层

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

Ability 子系统服务层 (UML)

OpenHarmony 源码解析之 Ability子系统 (零)-鸿蒙HarmonyOS技术社区

核心类:

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)

OpenHarmony 源码解析之 Ability子系统 (零)-鸿蒙HarmonyOS技术社区

核心类:

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 子系统的局部流程进行详细讲解。

想了解更多内容,请访问:

51CTO和华为官方合作共建的鸿蒙技术社区

https://harmonyos.51cto.com

 

责任编辑:jianghua 来源: 鸿蒙社区
相关推荐

2021-11-08 15:04:47

鸿蒙HarmonyOS应用

2022-01-06 16:17:58

鸿蒙HarmonyOS应用

2022-02-17 20:57:07

OpenHarmon操作系统鸿蒙

2021-12-17 16:42:09

鸿蒙HarmonyOS应用

2023-04-12 15:31:11

系统服务管理鸿蒙

2022-01-10 15:30:11

鸿蒙HarmonyOS应用

2021-11-18 10:28:03

鸿蒙HarmonyOS应用

2022-05-10 11:17:27

电话子系统数据服务模块

2022-05-24 15:46:51

Wi-FiSTA模式

2023-04-06 09:14:11

多模输入子系统鸿蒙

2021-09-13 15:15:18

鸿蒙HarmonyOS应用

2022-01-13 10:11:59

鸿蒙HarmonyOS应用

2023-06-28 15:00:02

开源鸿蒙输入系统架构

2021-09-17 14:38:58

鸿蒙HarmonyOS应用

2022-02-14 14:47:11

SystemUIOpenHarmon鸿蒙

2022-01-20 14:33:29

openharmonwayland协议鸿蒙

2022-03-18 16:07:04

Graphic子系统鸿蒙

2022-05-17 10:42:36

reboot源码解析

2021-11-25 09:54:54

鸿蒙HarmonyOS应用

2022-07-05 16:03:29

电源管理子系统鸿蒙
点赞
收藏

51CTO技术栈公众号