更多内容请访问：与华为官方共建的鸿蒙技术社区https://harmonyos.51cto.com00。简介本文档是根据OpenHarmony2.2Beta2源代码L2设备部分编写的。由于鸿蒙系统目前正处于快速发展期，本文部分内容可能已过时。建议阅读时参考最新代码，了解更多实时知识。Ability子系统实现了Ability的运行和生命周期的统一调度和管理。应用进程可以支持多个Ability，Ability具有跨应用进程和同进程内调用的能力。AbilityManagementService统一调度管理应用中的各个Ability，管理Ability的生命周期变化。这个子系统在OpenHarmony架构中的位置如下图红框所示（这里特意加大了红框的大小，因为它的内部逻辑除了包含了部分用户程序框架和系统服务层能力框架）。对于应用流程来说，能力子系统是关联最密切的核心系统模块。OpenHarmony架构图：01.基础知识Ability子系统的架构如下图所示。可以看到分为两个模块，其中AbilityKit模块位于UserProcess（用户进程），AbilityManagerService模块位于ServiceLayer（服务层）。这两个模块内部由多个关联的子模块组成。Ability子系统架构图：要理解Ability框架，需要了解以下几个概念：0）AbilityAbility是系统调度应用的最小单元，是能够完成独立功能的组件。一个应用程序可以包含一个或多个能力。能力分为FA（FeatureAbility）和PA（ParticleAbility）两种。其中FA支持PageAbility，PA支持ServiceAbility和DataAbility。1）Ability生命周期Ability生命周期（AbilityLifeCycle）是调度到INACTIVE\ACTIVE\Background等状态的Ability的统称（主要涉及PageAbility类型和ServiceAbility类型的Ability）。PageAbility类型的Ability生命周期流程如下图所示：ServiceAbility类型的Ability生命周期流程如下图所示：如果想了解更多关于Ability的信息，可以搜索参考其他相关文档鸿蒙能力。我们还将编写和分享一些详细解释Ability的文档。2）ServiceLayerServiceLayer模块运行在OpenHarmony的各个系统进程中，用于与底层进行交互，支持上层框架层的功能。它们通过IPC调用将信息传入和传出用户进程。服务层Ability子系统的模块是AbilityManagerService。3）用户进程用户进程是指OpenHarmony上层的应用进程，包括系统应用和第三方应用。每个应用程序通常运行在一个独立的用户进程中。用户进程包含框架层的模块逻辑，通过框架层的接口以IPC调用的形式使用服务层的系统服务。02.类之间的关系本节将展示服务层与用户进程的Ability子系统类关系图。在学习Ability子系统的类图之前，我们首先要了解OpenHarmony的IPC调用框架图，它是各种系统服务工作的基本机制之一。0）IPC框架目前OpenHarmony还没有在源码中完全使用IDL来生成IPC调用接口。各系统服务暂时定义为手工编写。主要类之间的关系如下图所示：IPC框架图（UML）中黄色标记的四个部分是写服务时需要实现的四个类：接口是一个抽象基类，不能实例化.用于定义跨进程调用的函数的名称、参数和返回类型；Proxy类继承IRemoteProxy类，其内部实现了Client的功能，将参数序列化，通过IPC驱动传递给服务器端，并接收服务器端的返回值；Stub类继承了IRemoteStub类，但它仍然是一个抽象类，不能被实例化。其内部实现了对来自客户端的数据进行反序列化并传递给相应的函数，并对返回值进行序列化，通过IPC驱动传递给客户端；Service类继承了Stub类，Stub类是Server端的核心业务类，用于实现各个接口的真正逻辑。由于代码量较大，这里只做简单介绍。如果大家想进一步了解IPC框架的机制和实现，我们也会在后续撰写和分享相关文档。1）系统服务流程中服务层Ability子系统类之间的关系如下图所示。绿色标注的类是整个流程的核心类，蓝色框代表与外部模块交互，粉色类代表跨进程调用接口类：能力子系统服务层（UML）核心类：AbilityManagerService：Thisclass是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（FeatureAbility），即PageAbility。FA的visibility\hierarchy等状态由Manager计算和调度，并操作相应的AbilityRecord。AbilityConnectManager：该类负责PA（ParticleAbility）中的所有ServiceAbilities。ServiceAbility的连接\生命周??期等状态由Manager计算和调度，并操作相应的AbilityRecord。DataAbilityManager：该类管理所有PA（ParticleAbility）中的DataAbility。DataAbility的连接\加载等逻辑由Manager进行计算和调度，并在对应的AbilityRecord上进行操作。其他主要类：MissionRecord：该类对应名为Mission的逻辑概念。属于同一逻辑堆栈的页面能力组合成一个任务。这些Abilities的AbilityRecord会以栈的形式存储在对应的MissionRecord中。AbilityRecord在MissionRecord中的顺序就是Ability在Mission中的存在顺序，与Ability的进出逻辑有关。MissionStack：这个类对应的逻辑概念叫做Stack。属于同一显示区域的任务组合成一个Stack。这些Missions的MissionRecords会以栈的形式存储在对应的MissionStack中。需要注意的是，MissionStack中的MissionRecord与Mission的顺序无关，每个MissionRecord都会保存自己的顺序关系。每个MissionStack实例都存储在AbilityStackManager中并由其管理。ConnectionRecord：当ServiceAbility通过connectAbility()连接时，会在系统层生成一个ConnectionRecord对象。ConnectionRecord用于记录和控制Connection的数据和状态。每个ConnectionRecord实例都存储在AbilityConnectManager中并由其管理。DataAbilityRecord：调用DataAbility时，会在系统层生成一个DataAbilityRecord对象。DataAbilityRecord用于记录和控制DataAbility的数据和状态。各个DataAbilityRecord实例存储在DataAbilityManager中并由AbilityConnectManager管理。2）用户进程用户进程中Ability子系统的类之间的关系如下图所示。绿色标注的类是整个流程的核心类，蓝色框表示与外部模块交互，粉色类表示跨进程调用的接口类：AbilitySubsystemUserProcess(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的主要操作都会交由这个EventHandler循环来完成。AbilityHandler的实例内置于AbilityThread对象中。AbilityImpl(DataAbilityImpl\PageAbilityImpl\ServiceAbilityImpl)：该类用于直接控制对应Ability的运行和状态。针对三种不同类型的Abilities，AbilityImpl派生出三个不同的派生类（DataAbilityImpl\PageAbilityImpl\ServiceAbilityImpl）来对这三种类型的Abilities进行不同的处理。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子系统的功能和结构。由于该模块代码量大，逻辑复杂，本文仅在框架层面进行说明，不做赘述。想要了解更多关于能力子系统的内容，敬请期待我们稍后分享的《OpenHarmony 源码解析之 Ability 子系统 (一)》。在本文中，我们将选取能力子系统的部分流程进行详细讲解。更多信息请访问：Harmonyos.51cto.com，与华为官方合作打造的鸿蒙技术社区
