Hi3516的SAMGR--系統服務框架子系統-6-系統服務的啟動
在進入正題之前，我們先來簡單了解一下在系統服務的啟動方式上，輕量系統和小型系統(包括了標準系統，后面一樣)的差別。
不管是輕量系統還是小型系統，系統服務和特性(service/feature)的Init函數，都會用SYS_SERVICE_INIT /SYS_FEATURE_INIT或者SYSEX_SERVICE_INIT/APP_SERVICE_INIT/SYSEX_FEATURE_INIT/APP_FEATURE_INIT等一組宏來做標記，這組宏定義在 //utils/native/lite/include/ohos_init.h文件內。
打開這個文件，可以看到：
在對“LAYER_INITCALL”這個宏的展開上，輕量系統和小型系統的差別就開始了。
命令行進入B_LTS項目代碼根目錄，執行$find ./ -name *.gn | xargs grep -in "LAYER_INIT_SHARED_LIB" 指令，可以查到"LAYER_INIT_SHARED_LIB"定義的地方，在 //foundation/distributedschedule/samgr_lite/samgr/BUILD.gn:14。
打開看一下：
- config("external_settings_shared") {
- defines = [ "LAYER_INIT_SHARED_LIB" ]
- }
- if (ohos_kernel_type == "liteos_m") {
- static_library("samgr") {
- ......
- }
- }
- if (ohos_kernel_type == "liteos_a" || ohos_kernel_type == "linux") {
- shared_library("samgr") {
- ......
- public_configs += [ ":external_settings_shared" ]
- }
- }
也就是說輕量系統沒有定義"LAYER_INIT_SHARED_LIB"，而小型系統則是包含這個宏的定義的，為什么要將"LAYER_INIT_SHARED_LIB"的定義要放在samgr_lite/samgr組件上，這個稍后會講到。
輕量系統：
輕量系統上，LAYER_INITCALL使用__attribute __((section(“section_name”)))來展開， 其作用是在編譯階段，將函數或數據鏈接到指定的名為"section_name"對應的段中。在系統啟動時，再通過MODULE_INIT/SYS_INIT宏引導去"section_name"對應的段中找到記錄的入口函數，并依次執行它們。
注意，這種啟動方式是串行的，前一個服務的入口函數沒有執行完，并不會執行后一個服務的入口函數，這就是不能在SYS_SERVICE_INIT /SYS_FEATURE_INIT等宏標記的入口函數做太多事情、特別是不能做阻塞式的事情的原因。
更具體的啟動細節，請去《Hi3861_WiFiIoT工程的一點理解》進行閱讀理解。
小型系統：
小型系統上，LAYER_INITCALL使用__attribute __((constructor))來展開，對應還有一個__attribute __((destructor))，它們就類似于C++的類中的構造函數和析構函數的作用。
- 如果函數被設定為constructor屬性，則該函數會在main()函數開始執行之前被自動地先執行;
- 如果函數被設定為destructor屬性，則該函數會在main()函數執行結束之后或者exit()被調用后，被自動地執行。
這在小型系統中非常有用，比如某個進程的運行依賴ServiceA和FeatureAa，ServiceA和FeatureAa的Init函數都用SYS_SERVICE_INIT /SYS_FEATURE_INIT標記了，那在這個進程啟動時的main函數執行之前，ServiceA和FeatureAa的Init函數就會先于main被執行。所以，小型系統中，梳理清楚關鍵進程的服務依賴關系就顯得非常重要了。
下面我們就進入正題，小型系統的系統服務的整體的啟動流程。
我們知道，鴻蒙系統從內核態切換到用戶態，跑的第一個進程Init，也叫用戶態根進程，它讀取并分析/etc/init.cfg配置文件(//vendor/hisilicon/hispark_taurus/init_configs/init_liteos_a_3516dv300.cfg的副本)，根據上面的記錄，按順序啟動幾個關鍵的系統進程：
- {
- "name" : "init",
- "cmds" : [
- "start shell",
- "start apphilogcat",
- "start foundation",
- "start bundle_daemon",
- "start appspawn",
- "start media_server",
- "start wms_server",
- "start hiview",
- "start sensor_service",
- "start ai_server"
- ]
- },
系統啟動的log如下：
這里的“[init_service] ServiceStart:[[xxxx]]:OK, pid[x].”僅僅表明用戶態根進程已經為服務進程創建好了運行的基礎環境并拿到了服務進程的Pid，并不代表服務進程已經完全可以正常工作了。服務進程需要去執行自己的main()函數跑起來，而在這之前，又需要先去跑完它依賴的所有的“ServiceA和FeatureAa”的__attribute __((constructor))函數，然后main()的最后一步，一般是進入while (1) { pause() }狀態，也就是服務進程進入后臺，默默守護著本進程以及它的所有子進程/子線程，有點像蜂王/蟻后一樣，進程對內/外提供的服務、功能、接口等具體工作，由它的子子孫孫來完成。
上面提到，一個服務進程對別人的依賴關系非常重要，下表是我對上面init OK的9個進程的依賴關系所做的一些梳理，把每一個進程的依賴關系一層層找到列了出來，從上到下，把對三方庫的依賴、重復出現的依賴，都灰化掉了，這樣看起來就清爽多了。【每次重洗整理都發現會有一些小小的疏漏，所以這個表格還不算完美】
從系統啟動完整過程的log看這9個進程的實際啟動順序與上面/etc/init.cfg給出的順序并不一一對應：
- Line 167: {Process:shell}
- Line 170: {Process:apphilogcat}
- Line 182: {Process:sensor_service}
- Line 195: {Process:bundle_daemon}
- Line 284: {Process:ai_server}
- Line 345: {Process:wms_server}
- Line 347: {Process:media_server}
- Line 573: {Process:foundation}
- Line 1678: {Process:appspawn}
這是因為有些進程依賴關系很少，就啟動得快一些，而foundation進程，依賴非常多的東西，所以啟動得非常慢。
前面說到“為什么要將 LAYER_INIT_SHARED_LIB 的定義要放在samgr_lite/samgr組件上”，因為輕量系統不用__attribute __((constructor))這個機制，LAYER_INIT_SHARED_LIB的定義放在哪里，對輕量系統來說無所謂;而小型系統，看看上面的依賴關系表，shell/apphilogcat/media_server三個進程不依賴其他的ServiceA和FeatureAa，也不依賴samgr組件，所以對它們來說，LAYER_INIT_SHARED_LIB的定義放在哪里，也無所謂;而其他進程都需要依賴samgr，并且是由samgr來管理和啟動該進程所依賴的所有ServiceA和FeatureAa，所以LAYER_INIT_SHARED_LIB的定義，最低層次放在samgr是非常合適的，可以把系統組件的耦合程度降到最低。
3號進程shell由內核提供，直接啟動，這是full shell，代碼在//kernel/liteos_a/shell/full/目錄下。
4號進程apphilogcat，依賴關系非常簡單，僅僅依賴一個三方庫和由 //base/hiviewdfx/hilog_lite/frameworks/featured/ 目錄下的代碼編譯生成的動態鏈接庫hilog_shared，所以也是直接啟動了。
5號進程foundation，依賴的東西非常多，需要到很后面才會跑到main函數，這個后面詳細講。
反倒是依賴關系相對簡單的10號進程sensor_service、6號進程bundle_daemon、11號進程ai_server首先跑完依賴關系，進入main的while (1) { pause() } 狀態。
9號進程wms_server，啟動起來之后，它的子線程就無休止地監測按鍵/屏幕觸控等輸入性質或者窗口顯示性質的事件，并做出響應。
8號進程media_server，媒體服務進程看上去是最干凈的，只由//device/hisilicon/hardware/multimedia:libhdi_media提供支持，最終由liteos_a:kernel提供支持。
7號進程appspawn，是最后啟動的系統進程，它起來之后，就可以通過它孵化出第一個應用進程launcher，以及后面其他的應用進程。
上面shell/apphilogcat/media_server三個進程不依賴于samgr，也不依賴于其他的Service/Feature，我們這里就先不說了。
其他6個系統進程，每個進程都有自己獨立的地址空間，互相之間不能直接訪問，需要通過進程間通信來進行交互。
獨立的系統進程，在自己獨立的地址空間內，啟動自己所依賴的Service/Feature，由自己空間內的SamgrLiteImpl g_samgrImpl來管理，完全就是一個獨立的輕量系統，這里可以去看看我前面的文章《Hi3861的SAMGR--系統服務框架子系統-3》，但注意還是會有一些較大的差異。
下面以不算簡單，但又不復雜的wms_server進程為例，進行分析。
打開 //foundation/graphic/wms/BUILD.gn 文件，查看它的依賴關系，簡化整理如下：
hdi_input/lite_graphic_hals，需要外圍硬件設備的支持，硬件驅動啟動的時候就會加載運行了。
samgr和lite_ipc_adapter，都沒有__attribute __((constructor))修飾，這是兩個獨立的動態鏈接庫，裝載進來就直接用，注意，是samgr自己而已，并不包含"samgr_server:server"和"samgr_client:client"。
Broadcast服務，包含了“Provider and subscriber”feature，不過好像實際上并沒有使用到。
wms_server進程還依賴本進程代碼中提供的WMS/IMS服務，都沒有feature。
整理的表格如下：
從上表的依賴關系來看，它就依賴一個broadcast 組件提供的Service/Feature，以及它自己wms_server組件所提供的Service：WMS/IMS，所以從實際跑起來的log可以驗證，在main()跑起來之前，__attribute __((constructor))修飾的Servic/Feature的Init函數先跑起來：
在main函數跑起來之前，wms_server進程地址空間內，已經有一張由本進程的SamgrLiteImpl g_samgrImpl控制的靜態展開圖了(這里就不放展開圖了，可以參考《Hi3861的SAMGR--系統服務框架子系統-2》的展開圖進行理解)。
main( )中，跑完HiFbdevInit()/InitDriver()后，會通過HOS_SystemInit()來調用SAMGR_Bootstrap()函數，為上面三個service：Broadcast/WMS/IMS 創建各自的 TaskPool、Task、Queue，其中WMS/IMS是同級別的SHARED_TASK，所以它們共用一個Task/Queue，在收發消息時將會通過ServiceID來做區分。Task運行起來之后，立即監聽自己的消息隊列，處理消息。
三個service：Broadcast/WMS/IMS的消息隊列，各自會首先收到一個MSG_DIRECT消息，由HandleInitRequest()來處理，這個HandleInitRequest() 內，會調用DEFAULT_Initialize(serviceImpl)來初始化Service/Feature。
DEFAULT_Initialize(serviceImpl) 函數內的行為，對于輕量系統來說，就是調用Service/Feature的生命周期函數Initialize()/OnInitialize()來完成初始化工作，就OK了，SAMGR_RegisterServiceApi() 函數是空的樁函數。但是對于小型系統來說，SAMGR_RegisterServiceApi()有另外的實現，它是進入一個新世界的入口，這里先點到為止，后面我們會詳細講。
至此，系統服務進程wms_server就可以開始工作了。
“[wms.cpp] main[5-4]: GetInstance()->Run()”這一步，InputManagerService instance對象就開始無休止地監測按鍵/屏幕觸控等輸入性質的事件，并做出響應。
“[wms.cpp] main[5-5]: while(1)”這一步，也通過“OHOS::LiteWM::GetInstance()->MainTaskHandler();”開始無休止地根據需要重繪窗口顯示內容。
其他五個進程，啟動情況類似，或更簡單一些，或更復雜一些，但都會跑類似的流程，各個進程內部，都由自己的SamgrLiteImpl g_samgrImpl來管理本進程內的Service/Feature，進程內部的Service線程，直接通過消息隊列機制來進行通信即可，要想跨進程進行交互，那就需要更復雜的機制了。
