鸿蒙OH实战开发：鸿蒙设备启动流程之服务与应用启动流程简析-优快云博客

本文链接：https://blog.youkuaiyun.com/pengjiadashaoye/article/details/144546379

📚往期学习笔录📰：

📰 鸿蒙应用开发与鸿蒙系统开发哪个更有前景？

📰 嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~

📰 鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？

📰 记录一场鸿蒙开发岗位面试经历~

📰 持续更新中……

在 OpenHarmony 4.1 的整机启动流程中，按照以下步骤进行服务和应用的启动：

内核加载与 init 进程：bootloader 通常通过设置 cmdline 来指定内核的位置，并引导内核启动。

例如：

    kernel /boot/zImage initrd=initramfs.img console=ttyAMA0,115200 
    root=/dev/mmcblk0p2 rootwait
    someapp=arg1,arg2

内核启动后会加载 init 进程，如 init=/init root/dev/xxx。

基础环境初始化：init 进程挂载 tmpfs 和 procfs，创建基本的 dev 设备节点，提供一个基本的根文件系统。

tmpfs：这是一个内存上的文件系统，用于存储临时数据，比如在启动期间创建的目录、缓存等。它不会持久化到磁盘，当系统重启时会自动清除。

procfs：这个文件系统提供内核运行时信息的接口，如进程列表、系统配置、硬件状态等。init进程通常会挂载procfs，以便在启动早期获取和管理这些信息。

热插拔事件监听：init 进程启动 ueventd 来监控内核中的设备热插拔事件，为新插入的 block 设备分区（如 system 和 vendor 分区）创建相应的 dev 设备节点。

当设备被插入或移除时，内核会通过 uevent（用户空间事件）机制发送消息给 ueventd。ueventd 作为系统服务的一部分，负责监听这些netlink事件，并根据接收到的事件类型动态管理相应的设备节点。

服务启动：挂载完分区后，init 会扫描 /system/etc/init 目录下的 init.cfg 文件，根据配置启动各个系统服务，包括 SA（Service Ability，能力服务）。

    init.cfg文件是关键组件，它定义了系统服务的启动顺序和命令。每个服务（如serviceName）都有一个名称和可执行文件路径数组，例如：
    {
        "services" : [
            {
                "name" : "listen_test",
                "path" : ["/system/bin/sa_main"]
            }
        ]
    }

    在这个例子中，listen_test服务会在启动时运行/system/bin/sa_main。配置文件是JSON格式的，开发者需要确保添加的服务和命令按照正确的结构编写。
    init.cfg会根据配置中的jobs部分来执行一系列命令，比如：
    {
        "jobs" : [
            {
                "name" : "post-fs-data",
                "cmds" : [ "start listen_test" ]
            }
        ]
    }

服务注册与管理：每个 SA 在启动时向 samgr 注册，并获得一个 ID，应用可以通过这个 ID 来访问和调用 SA 提供的服务。在 APP_FEATURE_INIT(Init) 函数中，通过 sm->RegisterFeature() 方法将 SA 注册到 Samgr，同时提供服务实例。
用户程序管理：foundation 进程负责应用的生命周期管理和 JS 运行环境的准备。appspawn 作为应用孵化器，当接收到 foundation 的请求时，会快速孵化出新的应用进程，以减少启动时间。

Appspawn在OpenHarmony中作为应用孵化器，其主要功能是接收来自Foundation（基础服务层）或其他有权限的服务（如Ability Manager Service,AMS）的请求，这些请求通常以JSON格式包含启动新应用所需的信息。当appspawn接收到这样的请求时，它会按照指定的参数（如应用程序包名、动态库路径、用户和组ID等）来创建一个新的进程，并赋予相应的权限。

在标准系统中，appspawn的服务名称是固定的，“appspawn”，它通过监听本地socket等待客户端连接。小型系统则有所不同，appspawn在初始化后会注册服务并等待AMS或其他特定服务发送的进程间消息。

开发过程中，开发者需要了解如何使用appspawn提供的接口（如CreateClient、ConnectSocket等）来与appspawn进行通信，并构建包含应用程序启动参数的消息结构。

这些步骤是基于标准系统移植指南中的描述，并且适用于小型和标准系统设备，如 Hi3516DV300、Hi3518EV300 和 RK3568 等。对于不同内存级别的设备（如小型系统和轻量系统），可能有不同的启动组件和适配策略。

启动子系统内部涉及以下组件：

init 启动引导组件
init 启动引导组件对应的进程为 init 进程，是内核完成初始化后启动的第一个用户态进程。init 进程启动之后，读取 init.cfg 配置文件，根据解析结果，执行相应命令（见 job 解析接口说明）并依次启动各关键系统服务进程，在启动系统服务进程的同时设置其对应权限。
ueventd 启动引导组件
ueventd 负责监听内核设备驱动插拔的 netlink 事件，根据事件类型动态管理相应设备的 dev 节点。
appspawn 应用孵化组件
负责接收用户程序框架的命令孵化应用进程，设置新进程的权限，并调用应用程序框架的入口函数。
bootstrap 服务启动组件
提供了各服务和功能的启动入口标识。在 SAMGR 启动时，会调用 bootstrap 标识的入口函数，并启动系统服务。

当前 OpenHarmony 标准系统默认支持以下几个镜像：

镜像名称	挂载点	说明
boot.img	NA	内核和 ramdisk 镜像，bootloader 加载的第一个镜像
system.img	/system	系统组件镜像，存放与芯片方案无关的平台业务
vendor.img	/vendor	芯片组件镜像，存放芯片相关的硬件抽象服务
updater.img	/	升级组件镜像，用于完成升级；正常启动时不加载次镜像
userdata.img	/data	可写的用户数据镜像