鴻蒙系統(tǒng)框架層的啟動細節(jié)
51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)
本文可看做是前文《鴻蒙系統(tǒng)的啟動流程v2.0》的第四階段的補充和驗證。
首先請看我的環(huán)境：
HiSpark AI Camera開發(fā)板(Hi3516dv300) + DevEco的HPM新建工程[Hi3516]編譯的軟件，項目代碼默認打印的大部分log被我臨時關(guān)掉了，按我自己的風(fēng)格在關(guān)鍵點重新打印的log，log基本樣例為：
- [system_init] SystemInit[20-18]: system_console_init[full shell]
- ：[system_init] //在system_init.c 文件內(nèi)
- : SystemInit[20-18] //在SystemInit()函數(shù)內(nèi)，大概有20步主要動作，這是第18步
- ：system_console_init[full shell] //這一步做了哪些事，或者打印關(guān)鍵信息
附件的log，是我在Hi3516開發(fā)板上抓的，大概從內(nèi)核創(chuàng)建 Init 進程前一點點，到系統(tǒng)啟動穩(wěn)定的全過程，最后一段是點擊相機應(yīng)用打開攝像頭的log。
我將其分成若干段，下面一步步分析其啟動細節(jié)。
1. 創(chuàng)建 /bin/init 前：Line3~7
- [system_init] SystemInit[20-18]: system_console_init[full shell]
- [system_init] system_console_init()->OsShellInit()
- [system_init] SystemInit[20-19]: CatLogShell
- [system_init] SystemInit[20-20]: OsUserInitProcess() Create user init process[run /bin/init]
- [system_init] SystemInit[20-0]: end.
前面的SystemInit()步驟，請自行閱讀代碼理解。
從 system_console_init()進去跟蹤，可以確認跑的是 Hi3516/kernel/liteos_a/shell/full/ 里面的代碼，而不是 Hi3516/kernel/liteos_a/apps/shell/ 里面的簡化版的shell。
這個可以從后面啟動shell服務(wù)時打印的“OHOS # ”可以確認，full shell會打印這個，apps的shell不會打印。
然后就是創(chuàng)建用戶根進程 Init，并切換到用戶態(tài)去跑 /bin/init 程序了。
2. /bin/init ：Line10~27 + Line180~182
- [init_lite] “/bin/init” main: starting OHOS Framework…
- …
- [init_lite] main[4-3] enter: InitReadCfg()
- …
- [init_read_cfg] InitReadCfg[7-6(1/2/3)]: DoJob(pre-init/init/post-init)
Line180~182：
- [init_cmds] DoChown, failed for 0 99 /dev/hdfwifi, err 2.
- [init_read_cfg] InitReadCfg[7-7]: ReleaseAllJobs()
- [init_lite] main[4-4] enter: while(1)…
這是 Hi3516/base/startup/services/init_lite/src/main.c 里的main函數(shù)跑的流程。【至于內(nèi)核態(tài)進程怎么切換到用戶態(tài)來跑這個函數(shù)，詳情可閱讀前文《鴻蒙系統(tǒng)的啟動流程v2.0》的第三階段的分析】
從這里開始到下面的 Line180~182，中間部分都是 DoJob()三個階段做的工作，我們先主要關(guān)注init階段的start service部分。
下面要依次啟動的服務(wù)，見 /Hi3516/vendor/huawei/camera/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"
- ]
- }
3. start shell ：Line29~31
- [init_service_manager] StartServiceByName:idx[7-1]:[[shell]].
- [init_service] ServiceStart [[shell]] succeed, pid = 3.
- OHOS #
如上所述，代碼在 Hi3516/kernel/liteos_a/shell/full/ 具體入口函數(shù)是哪個，我沒去找，感興趣的朋友自行找一下。
在開發(fā)板跑起來之后就已經(jīng)開啟shell服務(wù)了，在DevEco的monitor下敲個回車鍵就可以一看到“OHOS #”，敲個 task 命令看一下。
需要注意的是，debug版本才會提供shell功能，release版本不提供，會 start service fail。
4.start apphilogcat ：Line33~35
- [init_service_manager] StartServiceByName:idx[7-3]:[[apphilogcat]].
- [init_service] ServiceStart [[apphilogcat]] succeed, pid = 4.
- [hiview_applogcat] main entering while(1)…
這是DFX子系統(tǒng)的logcat服務(wù)，入口見：Hi3516/base/hiviewdfx/services/hilogcat_lite/apphilogcat/hiview_applogcat.c 文件內(nèi)的 main()。
函數(shù)一開始就：
- if (argc == 1)
- {
- #ifdef OHOS_RELEASE
- return 0;
- #endif
- }
也就是debug版本才會提供logcat功能，release版本不提供。
服務(wù)會進入while(1)循環(huán)，等待條件出現(xiàn)，將log打印到終端和文件內(nèi)。
- ret = read(fd, buf, HILOG_LOGBUFFER);
- if (ret < sizeof(struct HiLogEntry)) {
- continue;
- }
這就是條件，意味著幾乎每條log都會打印到終端，也會打印到文件里去，頻繁的文件讀寫操作，不可避免會影響系統(tǒng)性能(流暢性/穩(wěn)定性)，這就是為什么不建議普通用戶升級開發(fā)版的鴻蒙系統(tǒng)作為日常使用的原因之一。
另外，DFX子系統(tǒng)，還有一個logcat服務(wù)，不過看起來并沒有啟動起來：
- Hi3516/base/hiviewdfx/services/hilogcat_lite/hilogcat/hiview_logcat.c
這個服務(wù)只提供log打印到終端功能，而上面的apphilogcat則是log除了打印到終端外，同時還會保存到磁盤文件中。
5.start foundation： Line38~86
這個服務(wù)的啟動要重點講一下。
入口在:
- Hi3516/foundation/distributedschedule/services/safwk_lite/src/main.c
在真正的 foundation 服務(wù)啟動
- [safwk_lite:main] Foundation server begin:
之前，會先打印一大段 SERVICE_INIT 和 FEATURE_INIT 的log：
- ????????????????????????????????????????????????????????????????????
- [samgr_server] SYS_SERVICE_INIT(InitializeRegistry)# **samgr**: g_server
- [samgr_lite] SAMGR_GetInstance(mutex=NULL): NO SAMGR instance, Init() to create ONE
- [samgr_lite] Init. mutex[664156832]. sharedPool[0-8] reset to 0. status=0[BOOT_SYS]
- [samgr_lite] SAMGR_GetInstance(mutex=664156832)
- [permission_service] APP_SERVICE_INIT(Init) # permissionms
- [ipc_auth_lite] APP_FEATURE_INIT(Init) : ipc_auth
- [pms_inner] APP_FEATURE_INIT(Init) : PmsInner
- [pms_server] APP_FEATURE_INIT(Init) : PmsFeature
- [ability_mgr_service] SYSEX_SERVICE_INIT(Init)# abilityms
- [ability_mgr_feature] SYSEX_FEATURE_INIT(Init): AmsFeature
- [ability_inner_feature] SYSEX_FEATURE_INIT(Init): AmsInnerFeature
- [bundle_ms_host] APP_SERVICE_INIT(Init) # bundlems
- [bundle_inner_feature] APP_FEATURE_INIT(Init) : BmsInnerFeature
- [bundle_ms_feature] APP_FEATURE_INIT(Init) : BmsFeature
- [distributed_schedule_service] SYS_SERVICE_INIT(Init) # dtbschedsrv
- [dmslite] SYS_FEATURE_INIT(Init) : dmslite
- ????????????????????????????????????????????????????????????????????
為什么呢?
一開始我也是很多問號，Hi3861平臺上，會跑 HOS_SystemInit()
- void HOS_SystemInit(void)
- {
- MODULE_INIT(bsp);
- MODULE_INIT(device);
- MODULE_INIT(core);
- SYS_INIT(service);
- SYS_INIT(feature);
- MODULE_INIT(run);
- SAMGR_Bootstrap();
- }
以此來啟動相關(guān)的service/feature以及app上標(biāo)記為 SYS_RUN()的應(yīng)用，但是Hi3516上并沒有跑上面這個函數(shù)，而是跑弱引用的OHOS_SystemInit():
- void __attribute__((weak)) OHOS_SystemInit(void)
- {
- SAMGR_Bootstrap();
- }
我就到 Hi3516/foundation/distributedschedule/services/safwk_lite/ 目錄下去看 foundation 進程相關(guān)的 README.md，內(nèi)容很豐富，但貌似沒有合理的解釋。
那就再到 OHOS1_1_0LTS/foundation/distributedschedule/safwk_lite/ 目錄下去看 README_zh.md，這回有點意思了。
- safwklite模塊負責(zé)提供基礎(chǔ)服務(wù)運行的空進程。
- safwklite是foundation進程的實現(xiàn)。
- 在foundation進程中添加服務(wù)，按照服務(wù)的模板寫完服務(wù)后在BUILD.gn中添加依賴即可。
雖然只有簡短的幾句話，但意思很明確了：
- a.foundation是一個空進程，但是它“負責(zé)提供基礎(chǔ)服務(wù)運行”
- b.服務(wù)(基礎(chǔ)服務(wù)或者開發(fā)者新增的服務(wù))要運行起來，需要按模板添加在safwklite的BUILD.gn依賴中
所以，打開safwklite的BUILD.gn看一下依賴關(guān)系：
- deps = [
- "//foundation/distributedschedule/services/samgr_lite/samgr_server:server",
- "//base/hiviewdfx/frameworks/hilog_lite/featured:hilog_shared",
- "//base/security/services/iam_lite/ipc_auth:ipc_auth_target",
- ]
- if (ohos_kernel_type == "liteos_a") {
- deps += [
- "//base/security/services/iam_lite/pms:pms_target",
- "//foundation/aafwk/services/abilitymgr_lite:abilityms",
- "//foundation/appexecfwk/services/bundlemgr_lite:bundlems",
- "//foundation/distributedschedule/services/dtbschedmgr_lite:dtbschedmgr",
- ]
- }
所以上面那一大段 SERVICE_INIT 和 FEATURE_INIT 的log中，會先分別按順序啟動幾個service(用’#‘標(biāo)記)：samgr/permissionms/abilityms/bundlems/dtbschedsrv,這是服務(wù)的名字，真正的組件名字就分別是：samgr_lite/iam_lite/abilitymgr_lite/bundlemgr_lite/dtbschedmgr_lite。
samgr_lite 組件提供了分布式任務(wù)管理和調(diào)度能力，其他所有的系統(tǒng)能力都由它管理和調(diào)度【簡單的分析見前文《理解啟動恢復(fù)子系統(tǒng)》 的5.3小節(jié)，未來會單獨寫文章對SAMGR進行詳細分析，敬請期待】。
另外四個組件，又包含各自的feature，會在這里一并進行init/注冊和提供服務(wù)(用’:'標(biāo)記)【進一步的細節(jié)，請自行去分析相關(guān)的BUILD.gn文件】。
如README.md所說，以后開發(fā)者要是開發(fā)了新的服務(wù)或者feature，都可以添加在foundation的依賴關(guān)系中。
所以，這里的foundation，實際上做的就是上面Hi3861平臺中的SYS_INIT(service) 和 SYS_INIT(feature) 兩步所做的工作。
Line60~86：
這就是調(diào)用SAMGR_Bootstrap()來注冊上面的幾個服務(wù)的具體流程了，這里先略過，詳情請自行閱讀代碼進行跟蹤和分析。
Line88~100：
這里是 dmslite 這個 feature 開始向軟總線發(fā)布dms服務(wù)了：
- [dmslite] OnInitialize(): PublishService(dms)–>>softbus
- …
- [dmslite_session] CreateSessionServer(moduleName[dms], sessionName[dms])
- [dmslite] OnPublishSuccess(publishId[1]), CreateSessionServer()
這就開始涉及到分布式軟總線子系統(tǒng)了。
剛好上周我在Hi3861平臺上對軟總線做了一番研究和調(diào)試，對此有了一點了解，為了避免軟總線的log對本文分析的流程的影響，我也暫時把軟總線的log關(guān)閉了，Hi3516和Hi3861工程都可以在foundation/communication/services/softbus_lite/os_adapter/include/os_adapter.h 找到 SOFTBUS_DEBUG 這個宏，def 或者 undef就可以打開/關(guān)閉軟總線的log了。
對于軟總線子系統(tǒng)的理解，我會另文專門分析總結(jié)，敬請期待。
6.start bundle_daemon： Line108~128
包管理服務(wù)的啟動，暫未進一步分析。
入口在：
- Hi3516/foundation/appexecfwk/services/bundlemgr_lite/bundle_daemon/src/bundle_daemon.cpp
7.start appspawn： Line132~157
啟動appspawn應(yīng)用孵化器服務(wù)，入口在：
- /Hi3516/base/startup/services/appspawn_lite/src/appspawn_service.c
這是所有應(yīng)用程序進程的父進程，appspawn通過接收應(yīng)用程序框架的命令來孵化應(yīng)用進程，具體流程這里也不做進一步深入了，請自行閱讀代碼進行分析。
8.start media_server： Line161~165
啟動媒體服務(wù)，入口在：
- Hi3516/foundation/multimedia/services/media_lite/media_main.cpp
提供播放、錄制、解析、解碼等接口能力，并提供媒體播放錄制引擎服務(wù)化能力。
- [/third_party/iniparser/src/iniparser.c] iniparser_load(/storage/data/cameradev.ini)
這里會調(diào)用三方庫來分析cameradev.ini文件(Hi3516/applications/sample/camera/media/cameradev_imx335.ini 的副本)，獲取攝像頭sensor的配置信息。
9.start wms_server： Line169~223
啟動圖形WMS組件服務(wù)，暫未進一步分析。入口在：
- Hi3516/foundation/graphic/lite/services/wms/src/server/samgr_wms.cpp
圖形服務(wù)采用C/S架構(gòu)，內(nèi)部分為窗口管理(WMS: Window Manager Service)和輸入事件管理(IMS: Input Manger Service)兩個子服務(wù)。
10.[appspawn_service] Invoke()： Line226~
這里就是 appspawn 開始孵化第一個應(yīng)用launcher，也就是我們看到的桌面。
- [appspawn_service] Invoke()
- [appspawn_service] Invoke: msg:: bundleName[com.huawei.launcher],sharedLibPaths[],identityID[73014444033],uID[101],gID[101]
再接下來的我點擊相機應(yīng)用圖標(biāo)，啟動攝像頭，也有一段log
- [appspawn_service] Invoke()
- [appspawn_service] Invoke: msg:: bundleName[com.huawei.camera],sharedLibPaths[],identityID[661424963587],uID[100],gID[100]
51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)
