OHOS標(biāo)準(zhǔn)系統(tǒng)的SAMGR代碼解讀（v3.1）--2--Samgr
??想了解更多關(guān)于開源的內(nèi)容，請訪問：??
OHOS標(biāo)準(zhǔn)系統(tǒng)的samgr組件位于3.1分支代碼的//foundation/distributedschedule/samgr/目錄下，在最新的master分支代碼則是//foundation/systemabilitymgr/samgr/目錄下。
1、samgr 組件的全景圖
先看samgr組件的全景圖（附件有大圖）。
從上圖中的代碼目錄結(jié)構(gòu)和編譯腳本部分，可以看到5個編譯目標(biāo)以及它們各自編譯的代碼：
- samgr_common：公共部分，提供SA Profile的解析工具、動態(tài)鏈接庫的加載和卸載等功能，主要用在上一篇分析的safwk的工作流程中，本文不再贅述。
- lsamgr：local samgr的客戶端代理，主要用于按需啟動指定的SA；該功能也同時編譯進(jìn)samgr_proxy模塊中（一并在samgr_proxy中分析）。
- samgr_proxy：samgr的客戶端代理。SA通過該代理提供的接口與samgr服務(wù)進(jìn)行交互，同時也為samgr服務(wù)向SA客戶端反饋SA的加載結(jié)果、訂閱的SA的狀態(tài)變化等功能提供Stub接口。
- samgr_init：samgr服務(wù)自啟動的配置文件，與samgr可執(zhí)行程序配套使用。
- samgr：samgr服務(wù)的可執(zhí)行程序?qū)嶓w，結(jié)合samgr_init的配置，在系統(tǒng)啟動的早期自動運行，拉起samgr服務(wù)。同時也通過Proxy向SA客戶端反饋SA的加載結(jié)果、訂閱的SA的狀態(tài)變化事件等消息。
全景圖中雖然畫出了IPC相關(guān)的結(jié)構(gòu)，但本文暫不深入IPC/RPC的分析，因此，下文重點看samgr服務(wù)的實現(xiàn)和samgr_proxy客戶端的實現(xiàn)。
2、samgr 服務(wù)的啟動流程
samgr服務(wù)在OHOS系統(tǒng)中幾乎是最早啟動的系統(tǒng)服務(wù)，它在OHOS中占據(jù)了通信中樞的重要位置（可以參考我分析的samgr_lite系列文章來進(jìn)行理解）。
samgr服務(wù)的啟動流程如全景圖左下角部分所示，看起來還是比較簡單的。
在完成 SystemAbilityManager 類對象manager的創(chuàng)建和Init()之后，就生成了全景圖右下角部分所示的結(jié)構(gòu)；然后通過IPCSkeleton::SetContextObject()將 manager 作為遠(yuǎn)程對象注冊到IPC模塊，為以后的IPC/RPC提供IRemoteObject；最后samgr服務(wù)的主線程進(jìn)入loop，開始為整個系統(tǒng)中的SA提供服務(wù)。
接下來的內(nèi)容，請結(jié)合samgr組件的全景圖和下面的IPC交互示意圖進(jìn)行理解。
3、samgr 服務(wù)端的類結(jié)構(gòu)
samgr 服務(wù)端主要的類結(jié)構(gòu)和繼承關(guān)系，見全景圖的右下角以ohos_executable(“samgr”)為起點的部分。
（1）SA死亡回調(diào)相關(guān)的成員和RPC回調(diào)相關(guān)的成員
在 SystemAbilityManager::Init() 中創(chuàng)建并初始化的與SA死亡回調(diào)相關(guān)的成員、RPC回調(diào)相關(guān)的成員，這里先放下不說，請小伙伴先自行閱讀代碼理解。
（2）SystemAbilityLoadCallbackProxy 和 SystemAbilityStatusChangeProxy
在 SystemAbilityManager 類提供的服務(wù)中，samgr會根據(jù)需要調(diào)用相關(guān)的接口向samgr_proxy發(fā)送IPC消息，以此向Proxy反饋SA的加載狀態(tài)、上線離線狀態(tài)等信息，見4.2節(jié)的簡介。
（3）SystemAbilityManagerStub 和 SystemAbilityManager
samgr服務(wù)端的主要工作在這兩個類中。
在samgr進(jìn)程啟動過程中創(chuàng)建SystemAbilityManager對象時，在SystemAbilityManagerStub的構(gòu)造函數(shù)中就會初始化一個 memberFuncMap_，將Stub要處理的消息代碼與處理函數(shù)關(guān)聯(lián)起來。
SystemAbilityManagerStub在接收到SystemAbilityManagerProxy發(fā)過來的IPC消息后，直接在memberFuncMap_中匹配消息代碼，然后轉(zhuǎn)為調(diào)用子類SystemAbilityManager的函數(shù)來做具體的服務(wù)工作，如有需要也會把處理結(jié)果返回給SystemAbilityManagerProxy。
3.1和3.2中的工作，也是由SystemAbilityManager類發(fā)起調(diào)用或者直接進(jìn)行處理的。
4、samgr_proxy的類結(jié)構(gòu)
samgr_proxy相關(guān)的類結(jié)構(gòu)和繼承關(guān)系，見全景圖的中以ohos_shared_library(“samgr_proxy”)為起點的部分。
（1）LocalAbilityManagerProxy
LocalAbilityManagerProxy類提供了向指定進(jìn)程發(fā)送IPC消息拉起按需啟動的SA的Proxy接口，由指定進(jìn)程中的LocalAbilityManagerStub接收消息，并執(zhí)行動態(tài)拉起SA的具體動作（如上一篇分析4.3節(jié)分析所示）。
例如，不管是同設(shè)備內(nèi)的進(jìn)程還是跨設(shè)備的進(jìn)程，在調(diào)用：
sptr<IRemoteObject> SystemAbilityManager::CheckSystemAbility(int32_t systemAbilityId, bool& isExist)
向samgr查詢SA時，samgr會先在已啟動的 abilityMap_ 中查找目標(biāo)SA，能找到，則表明SA已經(jīng)啟動了；找不到，則繼續(xù)在正在啟動的 startingAbilityMap_ 中查找目標(biāo)SA，能找到，則表明SA正在啟動中；還找不到，則會嘗試調(diào)用StartOnDemandAbility(SAID)來啟動目標(biāo)SA（即按需啟動SA）。StartOnDemandAbility(SAID)會在登記到onDemandAbilityMap_中的按需啟動的SA列表中查找匹配SAID的記錄，并通過SystemAbilityManager::StartOnDemandAbilityInner()向SAID所在進(jìn)程發(fā)送IPC消息，要求該進(jìn)程拉起對應(yīng)的SA，如下代碼片段所示：
void SystemAbilityManager::StartOnDemandAbilityInner(const std::u16string& procName, int32_t systemAbilityId,
AbilityItem& abilityItem)
{
......
//從 systemProcessMap_ 中獲取 LocalAbilityManagerProxy procObject
sptr<ILocalAbilityManager> procObject =
iface_cast<ILocalAbilityManager>(GetSystemProcess(procName));
......
//調(diào)用 LocalAbilityManagerProxy::StartAbility
//向 LocalAbilityManagerStub 發(fā)送IPC消息拉起參數(shù)指定的SA
procObject->StartAbility(systemAbilityId);
......
}
（2）SystemAbilityLoadCallbackStub 和 SystemAbilityStatusChangeStub
當(dāng)進(jìn)程A向samgr注冊SA_a時，samgr會調(diào)用：
void SystemAbilityManager::SendSystemAbilityAddedMsg(int32_t systemAbilityId, const sptr<IRemoteObject>& remoteObject)
{
......
auto notifyAddedTask = [systemAbilityId, remoteObject, this]() {
FindSystemAbilityNotify(systemAbilityId, ADD_SYSTEM_ABILITY_TRANSACTION);
NotifySystemAbilityLoaded(systemAbilityId, remoteObject);
};
bool ret = workHandler_->PostTask(notifyAddedTask);
......
}
其中的FindSystemAbilityNotify()會在 listenerMap_ 中查找監(jiān)聽SA_a狀態(tài)變化的監(jiān)聽者，并調(diào)用listener的回調(diào)函數(shù)，通過SystemAbilityStatusChangeProxy向SystemAbilityStatusChangeStub發(fā)送SA_a上線或離線的消息。listener所在的進(jìn)程B、進(jìn)程C…的SystemAbilityStatusChangeStub就可以收到該消息并做針對性地處理。
其中的NotifySystemAbilityLoaded()也會通過SystemAbilityLoadCallbackProxy向SystemAbilityLoadCallbackStub 發(fā)送SA_a加載成功的IPC消息到查詢SA_a的進(jìn)程B中，這樣進(jìn)程B中的SystemAbilityLoadCallbackStub 就可以收到該消息并做針對性地處理。
（3）SystemAbilityManagerProxy和 SystemAbilityManagerClient
進(jìn)程A必須要通過代理才能與samgr進(jìn)行交互（如注冊SA、查詢SA等）。
如進(jìn)程A在啟動SA_a時，必須要先通過CheckSystemAbilityManagerReady() 確認(rèn)samgr可以訪問：
bool LocalAbilityManager::CheckSystemAbilityManagerReady()
{
......
//獲取samgr的代理：SystemAbilityManagerProxy
sptr<ISystemAbilityManager> samgrProxy = SystemAbilityManagerClient::GetInstance().GetSystemAbilityManager();
while (samgrProxy == nullptr) {
HILOGI(TAG, "waiting for SAMGR...get 'samgrProxy'...");
if (timeout > 0) {
usleep(duration);
samgrProxy = SystemAbilityManagerClient::GetInstance().GetSystemAbilityManager();
} else {
HILOGE(TAG, "waiting for SAMGR...timeout[10s]...NGNGNG");
return false;
}
timeout--;
}
......
return true;
}
即能夠成功獲取samgr的代理SystemAbilityManagerProxy，這樣SA_a才能注冊到samgr中，否則表示samgr還沒有能夠正常工作，所有的SA_x都無法注冊，所以可以說samgr進(jìn)程是最早啟動的系統(tǒng)服務(wù)進(jìn)程了。
類似的，在系統(tǒng)中各個進(jìn)程需要與samgr進(jìn)行交互的時候，都是按下面這個流程進(jìn)行的：
//先獲取samgr的代理：SystemAbilityManagerProxy
sptr<ISystemAbilityManager> samgrProxy = SystemAbilityManagerClient::GetInstance().GetSystemAbilityManager();
//再通過該代理向samgr發(fā)送IPC消息，使用samgr提供的服務(wù)
samgrProxy->XxxYyy()
5、Proxy與Stub的IPC交互
一圖勝千言，兩圖勝兩千言。
請結(jié)合前面兩張圖自行閱讀代碼進(jìn)行理解。
文章相關(guān)附件可以點擊下面的原文鏈接前往下載：
https://ost.51cto.com/resource/2287。
