鴻蒙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的初始化。