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

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