OpenHarmony源碼解析之Ability子系統(零)
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 子系統的局部流程進行詳細講解。
