鸿蒙系统框架层的启动细节

2024-01-28 18:38:46

本文可看做是前文《鸿蒙系统的启动流程v2.0》的第四阶段的补充和验证。

首先请看我的环境：
HiSpark AI Camera开发板(Hi3516dv300) + DevEco的HPM新建工程[Hi3516]编译的软件，项目代码默认打印的大部分log被我临时关掉了，按我自己的风格在关键点重新打印的log，log基本样例为：

[system_init] SystemInit[20-18]: system_console_init[full shell]
：[system_init] //在system_init.c 文件内
: SystemInit[20-18] //在SystemInit()函数内，大概有20步主要动作，这是第18步
：system_console_init[full shell] //这一步做了哪些事，或者打印关键信息

附件的log，是我在Hi3516开发板上抓的，大概从内核创建 Init 进程前一点点，到系统启动稳定的全过程，最后一段是点击相机应用打开摄像头的log。
我将其分成若干段，下面一步步分析其启动细节。

1. 创建 /bin/init 前：Line3~7

[system_init] SystemInit[20-18]: system_console_init[full shell]
[system_init] system_console_init()->OsShellInit()

[system_init] SystemInit[20-20]: OsUserInitProcess() Create user init process[run /bin/init]

前面的SystemInit()步骤，请自行阅读代码理解。
从 system_console_init()进去跟踪，可以确认跑的是 Hi3516/kernel/liteos_a/shell/full/ 里面的代码，而不是 Hi3516/kernel/liteos_a/apps/shell/ 里面的简化版的shell。
这个可以从后面启动shell服务时打印的“OHOS # ”可以确认，full shell会打印这个，apps的shell不会打印。
然后就是创建用户根进程 Init，并切换到用户态去跑 /bin/init 程序了。

2. /bin/init ：Line10~27 + Line180~182

[init_lite] "/bin/init" main: starting OHOS Framework...
......
[init_lite] main[4-3] enter: InitReadCfg()
......

Line180~182：

[init_cmds] DoChown, failed for 0 99 /dev/hdfwifi, err 2.

[init_lite] main[4-4] enter: while(1)...

这是 Hi3516/base/startup/services/init_lite/src/main.c 里的main函数跑的流程。【至于内核态进程怎么切换到用户态来跑这个函数，详情可阅读前文《鸿蒙系统的启动流程v2.0》的第三阶段的分析】
从这里开始到下面的 Line180~182，中间部分都是 DoJob()三个阶段做的工作，我们先主要关注init阶段的start service部分。

下面要依次启动的服务，见 /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] ServiceStart [[shell]] succeed, pid = 3.
OHOS #

如上所述，代码在 Hi3516/kernel/liteos_a/shell/full/ 具体入口函数是哪个，我没去找，感兴趣的朋友自行找一下。
在开发板跑起来之后就已经开启shell服务了，在DevEco的monitor下敲个回车键就可以一看到“OHOS #”，敲个 task 命令看一下。
需要注意的是，debug版本才会提供shell功能，release版本不提供，会 start service fail。

4.start apphilogcat ：Line33~35

[init_service] ServiceStart [[apphilogcat]] succeed, pid = 4.
[hiview_applogcat] main entering while(1)...

这是DFX子系统的logcat服务，入口见：Hi3516/base/hiviewdfx/services/hilogcat_lite/apphilogcat/hiview_applogcat.c 文件内的 main()。
函数一开始就：

    if (argc == 1) 
    {
        #ifdef OHOS_RELEASE
        return 0;
        #endif
    }

也就是debug版本才会提供logcat功能，release版本不提供。
服务会进入while(1)循环，等待条件出现，将log打印到终端和文件内。

        ret = read(fd, buf, HILOG_LOGBUFFER);
        if (ret < sizeof(struct HiLogEntry)) {
            continue;
        }

这就是条件，意味着几乎每条log都会打印到终端，也会打印到文件里去，频繁的文件读写操作，不可避免会影响系统性能(流畅性/稳定性)，这就是为什么不建议普通用户升级开发版的鸿蒙系统作为日常使用的原因之一。

另外，DFX子系统，还有一个logcat服务，不过看起来并没有启动起来：
Hi3516/base/hiviewdfx/services/hilogcat_lite/hilogcat/hiview_logcat.c
这个服务只提供log打印到终端功能，而上面的apphilogcat则是log除了打印到终端外，同时还会保存到磁盘文件中。

5.start foundation： Line38~86

这个服务的启动要重点讲一下。
入口在: Hi3516/foundation/distributedschedule/services/safwk_lite/src/main.c
在真正的 foundation 服务启动

[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();  
}

以此来启动相关的service/feature以及app上标记为 SYS_RUN()的应用，但是Hi3516上并没有跑上面这个函数，而是跑弱引用的OHOS_SystemInit():

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

我就到 Hi3516/foundation/distributedschedule/services/safwk_lite/ 目录下去看 foundation 进程相关的 README.md，内容很丰富，但貌似没有合理的解释。
那就再到 OHOS1_1_0LTS/foundation/distributedschedule/safwk_lite/ 目录下去看 README_zh.md，这回有点意思了。

safwklite模块负责提供基础服务运行的空进程。
safwklite是foundation进程的实现。
在foundation进程中添加服务，按照服务的模板写完服务后在BUILD.gn中添加依赖即可。

虽然只有简短的几句话，但意思很明确了：
a.foundation是一个空进程，但是它“负责提供基础服务运行”
b.服务(基础服务或者开发者新增的服务)要运行起来，需要按模板添加在safwklite的BUILD.gn依赖中
所以，打开safwklite的BUILD.gn看一下依赖关系：

        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(用'#'标记)：samgr/permissionms/abilityms/bundlems/dtbschedsrv,这是服务的名字，真正的组件名字就分别是：samgr_lite/iam_lite/abilitymgr_lite/bundlemgr_lite/dtbschedmgr_lite。
samgr_lite 组件提供了分布式任务管理和调度能力，其他所有的系统能力都由它管理和调度【简单的分析见前文《理解启动恢复子系统》 的5.3小节，未来会单独写文章对SAMGR进行详细分析，敬请期待】。
另外四个组件，又包含各自的feature，会在这里一并进行init/注册和提供服务(用':'标记)【进一步的细节，请自行去分析相关的BUILD.gn文件】。
如README.md所说，以后开发者要是开发了新的服务或者feature，都可以添加在foundation的依赖关系中。
所以，这里的foundation，实际上做的就是上面Hi3861平台中的SYS_INIT(service) 和 SYS_INIT(feature) 两步所做的工作。

Line60~86：
这就是调用SAMGR_Bootstrap()来注册上面的几个服务的具体流程了，这里先略过，详情请自行阅读代码进行跟踪和分析。

Line88~100：
这里是 dmslite 这个 feature 开始向软总线发布dms服务了：

[dmslite] OnInitialize(): PublishService(dms)-->>softbus
......
[dmslite_session] CreateSessionServer(moduleName[dms], sessionName[dms])
[dmslite] OnPublishSuccess(publishId[1]), CreateSessionServer()

这就开始涉及到分布式软总线子系统了。
刚好上周我在Hi3861平台上对软总线做了一番研究和调试，对此有了一点了解，为了避免软总线的log对本文分析的流程的影响，我也暂时把软总线的log关闭了，Hi3516和Hi3861工程都可以在foundation/communication/services/softbus_lite/os_adapter/include/os_adapter.h 找到 SOFTBUS_DEBUG 这个宏，def 或者 undef就可以打开/关闭软总线的log了。
对于软总线子系统的理解，我会另文专门分析总结，敬请期待。

6.start bundle_daemon： Line108~128

包管理服务的启动，暂未进一步分析。
入口在：Hi3516/foundation/appexecfwk/services/bundlemgr_lite/bundle_daemon/src/bundle_daemon.cpp

7.start appspawn： Line132~157

启动appspawn应用孵化器服务，入口在：
/Hi3516/base/startup/services/appspawn_lite/src/appspawn_service.c
这是所有应用程序进程的父进程，appspawn通过接收应用程序框架的命令来孵化应用进程，具体流程这里也不做进一步深入了，请自行阅读代码进行分析。

8.start media_server： Line161~165

启动媒体服务，入口在：
Hi3516/foundation/multimedia/services/media_lite/media_main.cpp
提供播放、录制、解析、解码等接口能力，并提供媒体播放录制引擎服务化能力。

[/third_party/iniparser/src/iniparser.c] iniparser_load(/storage/data/cameradev.ini)

这里会调用三方库来分析cameradev.ini文件(Hi3516/applications/sample/camera/media/cameradev_imx335.ini 的副本)，获取摄像头sensor的配置信息。

9.start wms_server： Line169~223

启动图形WMS组件服务，暂未进一步分析。入口在：
Hi3516/foundation/graphic/lite/services/wms/src/server/samgr_wms.cpp
图形服务采用C/S架构，内部分为窗口管理（WMS: Window Manager Service）和输入事件管理（IMS: Input Manger Service）两个子服务。

10.[appspawn_service] Invoke()： Line226~

这里就是 appspawn 开始孵化第一个应用launcher，也就是我们看到的桌面。

[appspawn_service] Invoke()
[appspawn_service] Invoke: msg:: bundleName[com.huawei.launcher],sharedLibPaths[],identityID[73014444033],uID[101],gID[101]

再接下来的我点击相机应用图标，启动摄像头，也有一段log

[appspawn_service] Invoke()
[appspawn_service] Invoke: msg:: bundleName[com.huawei.camera],sharedLibPaths[],identityID[661424963587],uID[100],gID[100]

附件是完整的log，能理解多少就看各位的造化了~.~。
感谢阅读。

文章相关附件可以点击下面的原文链接前往学习

原文链接：https://harmonyos.51cto.com/posts/4498#bkwz

想了解更多关于鸿蒙的内容，请访问：

51CTO和华为官方战略合作共建的鸿蒙技术社区

https://harmonyos.51cto.com/#bkwz

上一篇：prestodb2020年度回顾翻译


下一篇：AR Foundation（2），扫码显示两个模型