鴻蒙系統(tǒng)的啟動(dòng)流程v2.0

作者：liangkz 2021-04-19 15:37:43

系統(tǒng)

文章由鴻蒙社區(qū)產(chǎn)出，想要了解更多內(nèi)容請(qǐng)前往：51CTO和華為官方戰(zhàn)略合作共建的鴻蒙技術(shù)社區(qū)https://harmonyos.51cto.com

[[394121]]

想了解更多內(nèi)容，請(qǐng)?jiān)L問：

51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)

https://harmonyos.51cto.com

鴻蒙系統(tǒng)的啟動(dòng)流程

liangkz 2021.04.15 Ver2.0

目錄
1. 第一階段：U-Boot啟動(dòng)..................................................................................... 3
2. 第二階段：匯編代碼引導(dǎo)LiteOS-a內(nèi)核........................................................ 3
3. 第三階段：內(nèi)核LiteOS-a的C語(yǔ)言啟動(dòng)階段................................................ 4
4. 第四階段：鴻蒙系統(tǒng)框架層的啟動(dòng).............................................................. 14
5. 第四階段：鴻蒙系統(tǒng)框架層的啟動(dòng)細(xì)節(jié)...................................................... 17
6. 鴻蒙應(yīng)用(APP)的啟動(dòng)...................................................................................... 20
附錄A. #task命令查看進(jìn)程/線程信息(簡(jiǎn)表).................................................... 21

聲明：

升級(jí)文檔到v2.0后可以聲明是原創(chuàng)的了。這是上了朱有鵬老師的免費(fèi)課《想讀懂鴻蒙2.0源碼，也許你需要先懂這些》(link:https://edu.51cto.com/course/27341.html?hm)之后，做的一些總結(jié)。

課程時(shí)間一個(gè)半小時(shí)，內(nèi)容也很多，學(xué)習(xí)過程中我發(fā)現(xiàn)朱老師的ppt上部分代碼/文件，在我本地的鴻蒙系統(tǒng)代碼上找不到，或者路徑不相同，所以我就做了一些整理。

這里僅摘取課程中的鴻蒙系統(tǒng)在HI3516DV300平臺(tái)上的啟動(dòng)流程部分(從30:00開始講解啟動(dòng)過程)進(jìn)行匯總和整理，如有錯(cuò)誤，請(qǐng)朱老師和各位同學(xué)指正。后繼在學(xué)習(xí)過程中會(huì)繼續(xù)對(duì)本文當(dāng)作修正升級(jí)。附件升級(jí)了的v2.0文檔對(duì)閱讀更友好，歡迎下載收藏。

更新記錄：

我的本地代碼是基于最新發(fā)布的OpenHarmony 1.1.0 LTS(2021-04-01)版本抓取的，代碼根目錄OHOS1_1_0LTS：

$repo init -u https://gitee.com/openharmony/manifest.git -b refs/tags/OpenHarmony_release_v1.1.0 --no-repo-verify 
 
$repo sync

在根目錄下執(zhí)行

OHOS1_1_0LTS$ hb set 
 
[OHOS INFO] Input code path: . 
 
OHOS Which product do you need?   
 
->ipcamera_hispark_taurus@hisilicon 
 
OHOS1_1_0LTS$ hb build

即可開始編譯 hi3516dv300 平臺(tái)代碼。

輸出的過程文件和最終bin，在以下路徑內(nèi)：

out\hispark_taurus\ipcamera_hispark_taurus

因?yàn)楸救诉€沒有開發(fā)板，無(wú)法燒錄、抓取log分析以及做相關(guān)的操作去驗(yàn)證。

1. 第一階段：U-Boot啟動(dòng)

System startup 
 
Uncompress Ok! 
 
U-Boot 2016.11 (......) hi3516dv300 
 
............ 
 
............(省略) 
 
Hit any key to stop autoboot: 0 
 
MMC read: dev #0, block # 2048, count 16384  ...  16384 blocks read: OK 
 
## Starting application at 0x80000000...

到此為止屬于U-Boot的啟動(dòng)。

Uboot不屬于鴻蒙系統(tǒng)，這里不做進(jìn)一步分析，代碼在目錄

device\hisilicon\third_party\uboot\u-boot-2020.01

2. 第二階段：匯編代碼引導(dǎo)LiteOS-a內(nèi)核

Uboot引導(dǎo)liteos-a內(nèi)核啟動(dòng)起來(lái)，需要有一個(gè)入口，在：

kernel\liteos_a\tools\build\liteos.ld

打開這個(gè)文件，可見：

ENTRY(reset_vector) 
 
INCLUDE board.ld 
 
SECTIONS 
 
{ 
 
...... 
 
}

reset_vector 就是整個(gè)鴻蒙內(nèi)核啟動(dòng)的入口點(diǎn)，這是一個(gè)符號(hào)，定義在：

kernel\liteos_a\arch\arm\arm\src\startup\reset_vector_mp.S

同目錄下還有一個(gè)reset_vector_up.S文件，因?yàn)镠I3516是ARM Cortex A7雙核處理器，所以需要看mp(多核)這個(gè)文件，up這個(gè)是單核的。

打開reset_vector_mp.S文件，找到“reset_vector:”符號(hào)，從這里開始跑匯編代碼，引導(dǎo)liteos-a內(nèi)核的啟動(dòng)，一直到：

“ 
 
    bl     main 
 
  
 
_start_hang: 
 
    b      _start_hang 
 
”

這里調(diào)用一個(gè) main 函數(shù)，然后執(zhí)行 _start_hang 進(jìn)入死循環(huán)，至此匯編代碼階段就結(jié)束了。

通過main函數(shù)進(jìn)入內(nèi)核LiteOS-a啟動(dòng)的C語(yǔ)言階段。

3. 第三階段：內(nèi)核LiteOS-a的C語(yǔ)言啟動(dòng)階段

上面匯編階段調(diào)用的main函數(shù)，位于：

kernel\liteos_a\platform\main.c

main函數(shù)通過OsSystemInfo();函數(shù)里打印下面這些信息

******************Welcome****************** 
 
Processor  : Cortex-A7*2 
 
Run Mode : SMP 
 
GIC Rev  : GICv2 
 
build time : ...... 
 
Kernel  : Huawei LiteOS 2.0.0.xxx 
 
******************************************** 
 
  
 
main core booting up... 
 
... 
 
...

從這一步的main開始讀liteos-a的C語(yǔ)言源碼，可以直接在鴻蒙代碼的

kernel\liteos_a\platform\main.c

進(jìn)行閱讀理解。

不過，推薦從下面?zhèn)}庫(kù)拉代碼下來(lái)讀，
鴻蒙內(nèi)核源碼注解分析：
https://gitee.com/weharmony/kernel_liteos_a_note.git
這是在鴻蒙官方開源項(xiàng)目 kernel_liteos_a 基礎(chǔ)上，給源代碼加上了給常詳細(xì)的中文注解，有利于加快理解。
需要注意的是，這個(gè)注解的內(nèi)核代碼可能版本稍舊，而上面repo下來(lái)的內(nèi)核部分代碼可能做了部分重構(gòu)和修改，會(huì)有少量的不同。

main函數(shù)截圖如下：

Line173行調(diào)用的OsMain()函數(shù)，位于：

kenerl\liteos_a\kernel\common\los_config.c

主要做了：

其中的：

OsTickInit(......); // tick初始化,包含注冊(cè)中斷事件

硬件時(shí)鐘初始化，啟動(dòng)節(jié)拍，注冊(cè)硬中斷

OsKernelInitProcess(); // 完成內(nèi)核進(jìn)程的初始化

【鴻蒙內(nèi)核源碼注解分析上的API與OpenHarmony 1.1.0 LTS(2021-04-01)上的API，有少量差異，但功能基本上是一樣的。】

代碼都在：kernel\liteos_a\kernel\base\core\los_process.c 文件內(nèi)。

下面分別來(lái)看一下：

鴻蒙內(nèi)核源碼注解分析：OsKernelInitProcess()

OsCreateResourceFreeTask()函數(shù)，下面的調(diào)用也是一樣的。

OpenHarmony 1.1.0 LTS（2021-04-01）：OsSystemProcessCreate( )

由上面的代碼截圖可以看出：

創(chuàng)建2號(hào)進(jìn)程 KProcess，最高優(yōu)先級(jí)0，這是一個(gè)內(nèi)核態(tài)進(jìn)程。
創(chuàng)建KProcess的子線程ResourceTask，優(yōu)先級(jí)別5，用于資源回收
由KProcess復(fù)制(fork)出一個(gè)名叫 KIdle 的內(nèi)核態(tài)進(jìn)程，最低優(yōu)先級(jí)31
KIdle進(jìn)程創(chuàng)建子線程Idle，優(yōu)先級(jí)別31，給CPU空閑的時(shí)候使用.

注意，此時(shí)1號(hào)進(jìn)程還沒有創(chuàng)建，它是用戶態(tài)根進(jìn)程，要到稍微后面才創(chuàng)建。

可以在shell內(nèi)執(zhí)行task命令查看進(jìn)程和線程信息，表格見附錄。

OsSwtmrInit(); //軟時(shí)鐘模塊初始化

創(chuàng)建Swt_Task(software timmer)線程，父進(jìn)程是2號(hào)進(jìn)程KProcess，

OsSystemInit(); //系統(tǒng)初始化

系統(tǒng)軟硬件的初始化，由2號(hào)進(jìn)程 KProcess創(chuàng)建“system_wq”“SystemInit”“memshow_Task”等線程。

“SystemInit”線程：

跳出內(nèi)核代碼，到外部提供的SystemInit()做系統(tǒng)初始化，在:

device\hisilicon\hispark_taurus\sdk_liteos\mpp\module_init\src\system_init.c

里的SystemInit()函數(shù):

其中的：

ProcFsInit()

創(chuàng)建和掛載/proc文件系統(tǒng)，代碼見：

kernel\liteos_a\fs\proc\os_adept\proc_init.c

SDK_init() //calling SDK_init form HISI_SDK

初始化3516DV300特有的SDK，用內(nèi)部的DSP硬件來(lái)做視頻編解碼，只提供相關(guān)庫(kù)文件，不開源。

代碼在：

device\hisilicon\hispark_taurus\sdk_liteos\mpp\module_init\src\sdk_init.c

OsMountRootfs()

掛載根文件系統(tǒng)：

out\hispark_taurus\ipcamera_hispark_taurus\rootfs.tar

可以通過tar -tf rootfs.tar 命令查看里面都有些什么內(nèi)容，下面顯示一部分目錄：

OsUserInitProcess()

kernel\liteos_a\kernel\base\core\los_process.c

回到內(nèi)核代碼，鴻蒙內(nèi)核源碼注解分析：OsUserInitProcess()【最新1.1.0 LTS代碼有重構(gòu)，但意思一樣】

這時(shí)候才創(chuàng)建1號(hào)進(jìn)程Init，這是用戶態(tài)根進(jìn)程，優(yōu)先級(jí)別為28，

__user_init_entry 就是第一個(gè)用戶態(tài)根進(jìn)程的地址，它通過宏LITE_USER_SEC_ENTRY進(jìn)行定義：

代碼在：

kernel\liteos_a\kernel\user\src\los_user_init.c

LiteOS_a操作系統(tǒng)起來(lái)后，到掛載根文件系統(tǒng)，都處于內(nèi)核態(tài)(內(nèi)核空間)，創(chuàng)建第一個(gè)用戶態(tài)根進(jìn)程Init時(shí)，

通過第一個(gè)用戶態(tài)程序的地址 __user_init_entry / LITE_USER_SEC_ENTRY [ 進(jìn)入OsUserInit() 并執(zhí)行系統(tǒng)調(diào)用

"sys_call3" 切換到用戶態(tài)(用戶空間) ] 去運(yùn)行g(shù)_initPath = "/bin/init" 程序。

簡(jiǎn)單來(lái)說(shuō)第一個(gè)用戶態(tài)根進(jìn)程，實(shí)際上運(yùn)行的就是/bin/init的代碼。

1. /kernel/liteos_a/apps目錄下，是liteoa_a自帶的內(nèi)核應(yīng)用，也就是內(nèi)核的用戶態(tài)進(jìn)程，

目前有 init、shell、tftp三個(gè)內(nèi)核應(yīng)用，編譯后會(huì)在下面路徑下生成同名的可執(zhí)行文件：

out\hispark_taurus\ipcamera_hispark_taurus\obj\kernel\liteos_a\bin

其中init.c 做的事情很簡(jiǎn)單，就是fork一個(gè)新的用戶態(tài)進(jìn)程并運(yùn)行"/bin/shell".

2. /base/startup/init_lite目錄下的init_lite組件(init_lite module)的詳細(xì)說(shuō)明，見該目錄下的官方文檔【README_zh.md】。

查看BUILD.gn可看到它也會(huì)被編譯成 init 可執(zhí)行程序

在out\hispark_taurus\ipcamera_hispark_taurus\bin目錄下生成，同目錄下還有foundation、appspawn等可執(zhí)行程序。

3. 【疑惑、解疑】

寫本文檔的v1.0版本時(shí)，我就一直存在一個(gè)很大的疑惑，理論上LiteOS_a內(nèi)核的啟動(dòng)，從內(nèi)核態(tài)切換到用戶態(tài)時(shí)，

系統(tǒng)調(diào)用["sys_call3" ]去運(yùn)行的 g_initPath = "/bin/init" ，應(yīng)該是上面1編譯出來(lái)的init才對(duì)，可是為什么會(huì)去運(yùn)行上面2編譯出來(lái)的init呢?

因?yàn)椴欢苯臃治鯾uild.py和gen_rootfs.py等編譯腳本，我只好用了最笨的分析方法，步驟如下：

3.1 可以確認(rèn)的是兩個(gè)init，大小不一樣，生成位置也不一樣，init的生成時(shí)間1要比2早大約2分鐘。

3.2 懷疑是gen_rootfs.py在生成rootfs.tar時(shí)，只拷貝了2的init而沒有拷貝1的init到rootfs/bin目錄下。

但馬上推翻了，因?yàn)?生成的shell、tftp內(nèi)核應(yīng)用同時(shí)也拷貝到了rootfs/bin目錄下，不應(yīng)該特殊處理init：

3.3 那就有可能是gen_rootfs.py在生成rootfs.tar時(shí)，先拷貝1的init/shell/tftp到/rootfs/bin，

接著再拷貝2的init/foundation/appspawn……到/rootfs/bin時(shí)，把1的init給替換掉了。

馬上驗(yàn)證一下。

重新啟動(dòng)編譯，等2的init一生成，馬上將其改名為init5，等編譯完成后，重新打開rootfs.tar查看，

果不其然，rootfs/bin里面出現(xiàn)了init和init5，文件大小基本對(duì)應(yīng)得上，所以這就是真相。

3.4 有清楚gen_rootfs.py工作過程細(xì)節(jié)的同學(xué)麻煩從腳本分析入手確認(rèn)一下。

3.5 另，關(guān)于shell的疑問，也請(qǐng)懂的同學(xué)回復(fù)一下，這里就不分析和驗(yàn)證了：

kernel\liteos_a\apps\shell 會(huì)編譯成shell，據(jù)朱有鵬老師說(shuō)這是精簡(jiǎn)版的shell，

kernel\liteos_a\shell 這個(gè)也會(huì)編譯成shell，朱有鵬老師說(shuō)是全功能版的shell，

這兩個(gè)版本的shell，哪個(gè)會(huì)在最終的gen_rootfs.py 時(shí)拷貝到 /bin 中?

通過上面的驗(yàn)證，確認(rèn)了LiteOS_a內(nèi)核的啟動(dòng)，從內(nèi)核態(tài)切換到用戶態(tài)時(shí)，

系統(tǒng)調(diào)用["sys_call3" ]去運(yùn)行的 g_initPath = "/bin/init" ，確實(shí)是base\startup\init_lite 組件

編譯生成的init，也就是鴻蒙系統(tǒng)的第一個(gè)用戶態(tài)根進(jìn)程就是init_lite組件，這就進(jìn)入到了

鴻蒙系統(tǒng)的框架層framework的啟動(dòng)。

4. 第四階段：鴻蒙系統(tǒng)框架層的啟動(dòng)

這個(gè)應(yīng)用層實(shí)際上就是鴻蒙的framework，啟動(dòng)init入口在：

base\startup\init_lite\services\src\main.c

ReadFileToBuf()

這一步讀取的 /etc/init.cfg文件，在上面OsMountRootfs()掛載根文件系統(tǒng)的時(shí)候就掛載上了，它是

vendor\hisilicon\hispark_taurus\init_configs\init_liteos_a_3516dv300.cfg

的副本，這個(gè)文件就包含了“pre-init”“init”“post-init”的相關(guān)操作，分別是設(shè)置掛載一些設(shè)備、設(shè)置好路徑，啟動(dòng)服務(wù)等工作。

而后面的"services"則包含一組服務(wù)的定義，它們是系統(tǒng)里的關(guān)鍵進(jìn)程。

DoJob("init")

由“1號(hào)進(jìn)程init”，在應(yīng)用層通過start指令創(chuàng)建和啟動(dòng)：shell/apphilogcat/.../ai_server等3~9號(hào)進(jìn)程，它們都是用戶態(tài)進(jìn)程，父進(jìn)程都是“1號(hào)進(jìn)程init”。

init將根據(jù)上面cfg配置的job和services來(lái)做對(duì)應(yīng)的操作和啟動(dòng)對(duì)應(yīng)的服務(wù)程序，并設(shè)置它們的uid、gid、進(jìn)程優(yōu)先級(jí)和權(quán)限等。

可以在shell內(nèi)執(zhí)行task命令查看進(jìn)程和線程信息，表格見文末。

【見官方文檔：base\startup\init_lite\README_zh.md】
這個(gè)init組件(即base\startup\init_lite)負(fù)責(zé)處理從內(nèi)核加載第一個(gè)用戶態(tài)進(jìn)程(1號(hào)進(jìn)程init)開始，到第一個(gè)應(yīng)用程序啟動(dòng)之間的系統(tǒng)服務(wù)進(jìn)程啟動(dòng)過程。
init將系統(tǒng)啟動(dòng)分為三個(gè)階段：
“pre-init”階段：?jiǎn)?dòng)系統(tǒng)服務(wù)之前需要先執(zhí)行的操作，例如掛載文件系統(tǒng)、創(chuàng)建文件夾、修改權(quán)限等
“init”階段：系統(tǒng)服務(wù)啟動(dòng)階段
“post-init”階段：系統(tǒng)服務(wù)啟動(dòng)完后還需要執(zhí)行的操作
上述每個(gè)階段在配置文件init.cfg中都用一個(gè)job表示，每個(gè)job都對(duì)應(yīng)一個(gè)命令集合，init通過依次執(zhí)行每個(gè)job中的命令來(lái)完成系統(tǒng)初始化。job執(zhí)行順序：先執(zhí)行“pre-init”，再執(zhí)行“init”，最后執(zhí)行“post-init”，所有job都集中放在init.cfg的jobs數(shù)組中。
除上述jobs數(shù)組之外，init.cfg中還有一個(gè)services數(shù)組，用于存放所有需要由init進(jìn)程啟動(dòng)的系統(tǒng)關(guān)鍵服務(wù)的服務(wù)名、可執(zhí)行文件路徑、權(quán)限和其他屬性信息。
配置文件init.cfg位于代碼倉(cāng)庫(kù)/vendor/hisilicon/hispark_aries/init_configs/目錄，部署在/etc/下，采用json格式，文件大小目前限制在100KB以內(nèi)。
init組件會(huì)編譯成out\hispark_taurus\ipcamera_hispark_taurus目錄下的bin/init，同時(shí)打包在根文件系統(tǒng)rootfs.tar內(nèi)，上面掛載根文件系統(tǒng)時(shí)，會(huì)掛載成/bin/init，由第三階段的最后一步OsUserInit()調(diào)用和執(zhí)行。
【見官方文檔：base\startup\init_lite\README_zh.md】

總結(jié)：

Init_lite組件會(huì)編譯成out\hispark_taurus\ipcamera_hispark_taurus目錄下的bin/init，

然后在gen_rootfs.py生成rootfs.tar時(shí)替換掉系統(tǒng)自帶的內(nèi)核應(yīng)用init，成為系統(tǒng)第一個(gè)

用戶態(tài)根進(jìn)程的啟動(dòng)程序。并由它開啟系統(tǒng)里的其他關(guān)鍵服務(wù)進(jìn)程。

5. 第四階段：鴻蒙系統(tǒng)框架層的啟動(dòng)細(xì)節(jié)

上面第四階段簡(jiǎn)單解釋了鴻蒙系統(tǒng)的關(guān)鍵系統(tǒng)進(jìn)程和相關(guān)服務(wù)的啟動(dòng)。

這一小節(jié)就要看看shell/apphilogcat/.../ai_server等3~9號(hào)進(jìn)程的具體啟動(dòng)過程和調(diào)用的相關(guān)代碼入口。

DoJob(“init”)會(huì)根據(jù)cmds的順序啟動(dòng)相關(guān)服務(wù)：

"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" 
 
            ]

這些服務(wù)程序都對(duì)應(yīng)在根目錄的/bin下存在(除了hiview?需平臺(tái)確認(rèn))

1.1 start shell

啟動(dòng)shell服務(wù)，進(jìn)程ID是3。精簡(jiǎn)版和全功能版的shell，代碼分別在：

kernel\liteos_a\apps\shell 
 
kernel\liteos_a\shell\full

具體跑哪個(gè)，目前存疑，待驗(yàn)證。

1.2 start apphilogcat

啟動(dòng)apphilogcat服務(wù)，進(jìn)程ID是4。

base\hiviewdfx\hilog_lite

hilog_lite組件，提供DFX(Design For X，面向X的設(shè)計(jì))子系統(tǒng)在輕量系統(tǒng)和小型系統(tǒng)的流水日志功能。

詳情見目錄下的【README_zh.md】

base\hiviewdfx\hilog_lite\services\apphilogcat\hiview_applogcat.c 
 
base\hiviewdfx\hilog_lite\services\hilogcat\hiview_logcat.c

main() 里面都是log文件的相關(guān)操作

1.3 start foundation

啟動(dòng)foundation服務(wù)，進(jìn)程ID是5。

foundation\distributedschedule\safwk_lite

safwk_lite 是foundation進(jìn)程的實(shí)現(xiàn)，負(fù)責(zé)提供基礎(chǔ)服務(wù)運(yùn)行的空進(jìn)程。

safwk_lite 屬于分布式任務(wù)調(diào)度子系統(tǒng)的一個(gè)模塊。

詳情見目錄下的【README_zh.md】 saf: system ability (SA) framework

foundation\distributedschedule\safwk_lite\src\main.c 
 
main()里有調(diào)用: OHOS_SystemInit();

同文件有定義，不過是弱引用：

void __attribute__((weak)) OHOS_SystemInit(void) 
 
{ 
 
    SAMGR_Bootstrap();  
 
}

在base\startup\bootstrap_lite\services\source\system_init.c 有另一個(gè)定義：

void OHOS_SystemInit(void) 
 
{ 
 
    MODULE_INIT(bsp); 
 
    MODULE_INIT(device); 
 
    MODULE_INIT(core); 
 
    SYS_INIT(service); 
 
    SYS_INIT(feature);

MODULE_INIT(run); //SYS_RUN(HelloWorld); 從這里開始啟動(dòng)，待驗(yàn)證。

//系統(tǒng)服務(wù)框架子系統(tǒng)啟動(dòng) [system ability (SA) framework] 
 
 //foundation\distributedschedule\samgr_lite 
 
 SAMGR_Bootstrap();

1.4 start bundle_daemon

啟動(dòng)bundle_daemon服務(wù)，進(jìn)程ID是6。

foundation\appexecfwk\appexecfwk_lite

包管理組件服務(wù)，用戶程序框架子系統(tǒng)。

詳情見目錄下的【README_zh.md】

foundation\appexecfwk\appexecfwk_lite\services\bundlemgr_lite\bundle_daemon\src\main.cpp 
 
main()里有調(diào)用: HOS_SystemInit();

同文件有定義，同樣是弱引用，不過暫未發(fā)現(xiàn)其他地方有定義：

void __attribute__((weak)) HOS_SystemInit(void) 
 
{ 
 
    SAMGR_Bootstrap();  
 
}

1.5 start appspawn

啟動(dòng)appspawn服務(wù)，進(jìn)程ID是7。

base\startup\appspawn_lite

appspawn_lite 應(yīng)用孵化器組件，負(fù)責(zé)接受應(yīng)用程序框架的命令孵化應(yīng)用進(jìn)程，設(shè)置其對(duì)應(yīng)權(quán)限，并調(diào)用應(yīng)用程序框架的入口。

詳情見目錄下的【README_zh.md】

base\startup\appspawn_lite\services\src\main.c

main() 跑的流程基本上與bundle_daemon的一樣。

1.6 start media_server

啟動(dòng)media_server服務(wù)，進(jìn)程ID是8。

foundation\multimedia\media_lite

media_lite媒體子系統(tǒng)組件(C++實(shí)現(xiàn))，提供播放、錄制、解析、解碼等接口能力，并提供媒體播放錄制引擎服務(wù)化能力。詳情見目錄下的【README_zh.md】

foundation\multimedia\media_lite\services\media_main.cpp

1.7 start wms_server

啟動(dòng)wms_server服務(wù)，進(jìn)程ID是9。

oundation\graphic\wms

圖形服務(wù)采用C/S架構(gòu)，內(nèi)部分為窗口管理(WMS: Window Manager Service)和輸入事件管理(IMS: Input Manger Service)兩個(gè)子服務(wù)。APP調(diào)用客戶端接口完成窗口狀態(tài)獲取、事件處理等操作，服務(wù)端與硬件交互實(shí)現(xiàn)送顯、輸入事件分發(fā)等。

詳情見目錄下的【README_zh.md】

foundation\graphic\wms\services\wms\wms.cpp

1.8 start hiview

啟動(dòng)hiviewr服務(wù)，進(jìn)程ID是10。

base\hiviewdfx\hiview_lite

hiview_lite組件，提供DFX子系統(tǒng)整體的初始化功能，控制各組件按需啟動(dòng)

static void Init(void) 
 
{ 
 
} 
 
SYS_SERVICE_INIT(Init);

1.9 start sensor_service

啟動(dòng)sensor_server服務(wù)，進(jìn)程ID是11。

base\sensors\sensor_lite

泛Sensor服務(wù)子系統(tǒng)提供了輕量級(jí)sensor服務(wù)基礎(chǔ)框架。

詳情見目錄下的【README_zh.md】

1.10 start ai_server

啟動(dòng)ai_server服務(wù)，進(jìn)程ID是12。

foundation\ai\engine

AI業(yè)務(wù)子系統(tǒng)是OpenHarmony提供原生的分布式AI能力的子系統(tǒng)。

詳情見目錄下的【README_zh.md】

5.11 HMOS的Service

HMOS的init進(jìn)程啟動(dòng)后，接下來(lái)會(huì)啟動(dòng)上面一系列的服務(wù)(應(yīng)該還會(huì)有其他更多的)，對(duì)于這些服務(wù)，鴻蒙OS有一個(gè)統(tǒng)一管理，所有的服務(wù)都被注冊(cè)到如下的動(dòng)態(tài)數(shù)組當(dāng)中。

base\startup\init_lite\services\src\init_service_manager.c 
 
static Service* g_services = NULL; 
 
static int g_servicesCnt = 0;

具體情況需閱讀代碼進(jìn)行理解。

6. 鴻蒙應(yīng)用(APP)的啟動(dòng)

在hi3516dv300平臺(tái)(帶屏幕)的桌面(也就是launcher進(jìn)程)上點(diǎn)擊camera應(yīng)用圖標(biāo)，這時(shí)候會(huì)啟動(dòng)camera應(yīng)用程序，實(shí)際上會(huì)通過“7號(hào)進(jìn)程appspawn”創(chuàng)建子進(jìn)程“com.huawei.camera”，這是一個(gè)應(yīng)用程序進(jìn)程，其父進(jìn)程并不是launcher進(jìn)程，而是appspawn進(jìn)程。

實(shí)際上所有的應(yīng)用程序的父進(jìn)程都是appspawn進(jìn)程。

鴻蒙應(yīng)用開發(fā)的第一個(gè)示例程序“helloworld”的啟動(dòng)也應(yīng)該類似。

#include <stdio.h> 
#include "ohos_init.h" 
#include "ohos_types.h" 
void HelloWorld(void) 
{ 
    printf("[Init] Hello World!\n"); 
} 
SYS_RUN(HelloWorld);