鴻蒙OS開源代碼精要解讀之—— 系統服務框架子系統(服務啟動)

作者介紹：

中科創達OpenHarmony研究組

說明：

中科創達OpenHarmony研究組第一時間對https://codechina.csdn.net/openharmony上開源的代碼進行了詳盡的代碼研讀和學習，為此，我們打算撰寫一系列篇幅中等，內容精煉的原始碼分析文章來引領大家更進一步的走進鴻蒙OS，隨著對代碼的了解，廣大開發者想親自動手參與的意愿和信心也會隨之增強——這也是鴻蒙OS開源的意義所在，

本篇內容摘要：

Samgr模塊提供了面向服務體系結構（SOA）的開發框架基礎，提供了Servcie、Feature和Founction的基本模型，以及注冊和發現功能，是鴻蒙Framework非常重要的部分，系統中基于Samgr開發了許多服務，如Broadcast service, Bootstrap Servcie等，用戶也可以基于Samgr開發框架開發自己的Service，

本篇介紹了OpenHarmony服務按序注冊和啟動的流程，

主要結構體

關鍵成員說明：

1. struct TaskConfig：在注冊Service時提供，描述了Servcie對應的task的優先級，堆疊等資訊

2. struct TaskPool：初始化Service時生成

• queueId:創建taskpool時生成，通過不同的queueId來向不同的Servcie task發送訊息

3. struct Service：要注冊的Servcie，用戶需要實作如下四個函式：

• GetName：回傳Servcie名稱
• Initialize：Servcie初始化函式，一般是要保存Service初始化生成的身份資訊用于后續收發訊息
• MessageHandle：資訊處理函式
• TaskConfig：回傳Service對應的Task配置

4. struct Operations：記錄Servcie的時間戳等資訊

5. struct ServiceImpl：注冊Servcie實際上注冊的是ServiceImpl

• Service *service：注冊的Servcie
• TaskPool *taskPool：初始化時申請的taskpool
• Vector features：Service下的子feature
• int16 serviceId：serviceId的值為servcie在Vector中的位置，這個值在加載時就已經確定，
• uint8 inited：初始化標志

6. struct SamgrLiteImpl：全域只有一個SamgrLiteImpl g_samgrImpl，

• BootStatus status：Service啟動的狀態，目前定義了以下狀態值：
  • BOOT_SYS：將要啟動系統Service
  • BOOT_SYS_WAIT：正在啟動系統Service
  • BOOT_APP：將要啟動APP Servcie
  • BOOT_APP_WAIT：正在啟動APP Servcie
  • BOOT_DYNAMIC：將要啟動Dynamic Servcie
  • BOOT_DYNAMIC_WAIT：正在啟動Dynamic Service
• Vector services：注冊Servcie時將一個servcieImpl結構體追加到Vector末尾，用于后面的初始化

啟動流程

下圖Servcie注冊的流程：

1. 系統service使用SYS_SERVICE_INIT，SYS_FEATURE_INIT，用戶Service使用APP_SERVICE_INIT，APP_FEATURE_INIT來注冊服務，對于M核，把服務的注冊函式放到指定的段，在啟動時找到此段呼叫所有的函式，對于A核這個宏定義使用了__attribute__(constructor)的特性，這個特性在在程式加載后，程式執行之前執行注冊函式

2. 注冊Servcie主要是把ServiceImpl追加到全域g_samgrImpl的成員services Vector，并根據Servcie在向量表中的序號來確定ServcieID，

3. 注冊Feature主要是把FeatureImpl追加到對應服務的的features Vector,并根據Feature在向量表中的序號來確定FeatureID

下圖是Service初始化流程：

4. 服務初始化的入口是SAMGR_Bootstrap(foundation/distributedschedule/services/samgr_lite/samgr/samgr_lite.c)，主要實作以下功能：

a. 先更新全域g_samgrImpl的status：

而Status有如下的列舉：

那么更新的邏輯就是這樣子了：

如果status為BOOT_SYS == 0b,更新后是BOOT_SYS_WAIT == 1b;

如果status為BOOT_APP == 10b,更新后是BOOT_APP_WAIT == 11b;

如果status為BOOT_DYNAMIC == 100b,更新后是BOOT_DYNAMIC_WAIT == 101b;

如果status為BOOT_SYS_WAIT == 1b; BOOT_APP_WAIT == 11b; BOOT_DYNAMIC_WAIT == 101b;更新后不變，

g_samgrImpl的初始狀態是BOOT_SYS，首次呼叫會更新為BOOT_SYS_WAIT

b. 收集全域g_samgrImpl->servcies Vector中還沒有被初始化，狀態為SVC_INIT的servcie,一起初始化

5. 為收集的每個Servcie創建TaskPool和創建訊息佇列，并拿到訊息佇列的句柄，以后向某個Servcie執行緒發送訊息時就會發送給相應的佇列，

6. 將函式HandleInitRequest發送到訊息佇列，這個函式將會在Service執行緒創建啟動后，在Service對應的執行緒中執行，如果沒有申請到佇列，或者沒有申請到taskpool,就在當前執行緒中執行初始化操作

7. 為每個申請到佇列和taskpool的service創建和啟動Task，

下圖是Task的執行流程

Task回圈執行以下內容：

從訊息佇列中獲取exchange并拿到ServiceImpl

如果訊息型別為MSG_ACK或者MSG_DIRECT，就執行exchange->handler函式，結合上一步，初始化時執行HandleInitRequest

如果是其他型別（Request），則會呼叫Feature的 OnMessage或者Servcie的MessageHandle，然后再執行handler，

8. Service task啟動后會從佇列中獲取到HandleInitRequest并執行，主要做了以下的作業：

• 呼叫service的Initialize和feature OnInitialize函式，并將初始化程序中的ServcieID，FeatureID，和QueueID作為引數傳出，service一般會保存該ID用于以后身份鑒別，
• 更新Servcie的狀態為SVC_IDLE
• 檢查全域g_samgrImpl的services vector是否還有未初始化的servcie(如圖，pose >= size,則表示Service已經全部初始化完成)，如果都完成了就更新status到下一個狀態，并給Bootstrap服務發送訊息告知此階段初始化已完成

9. Bootstrap服務收到訊息后就會加載下一階段的程式，如果此時sys service已經完成，將會加載app

10. 用戶Service使用APP_SERVICE_INIT，APP_FEATURE_INIT注冊app service到全域g_samgrImpl的services vector中

11. SendBootRequest服務初始化入口SAMGR_Bootstrap作為handler傳給bootstrap service，用戶程式加載完成后bootstrap又會呼叫SAMGR_Bootstrap函式，回傳第4步去初始化app servcie

12. 以此類推，最終按順序完成sys service, app service, dynamic的初始化，