3、系统启动流程概览：从上电到桌面显示的完整链路

各位同学，今天我们来聊聊鸿蒙系统启动的完整链路。说实话，很多做嵌入式开发的朋友，做了好几年都搞不清按下电源键之后，芯片内部到底发生了什么。我当年刚入行时也是这样，直到有一次调试一个启动失败的问题，才逼着自己把整个流程啃了一遍。

鸿蒙系统的启动，说白了就是一场接力赛。从硬件复位到桌面显示，中间要经过好几个阶段。每个阶段都有自己的职责，一个环节出问题，整个系统就起不来。嗯，咱们今天就把这条链路拆开看看。

3.1 第一阶段：BootROM——芯片的第一口"奶"

按下电源键的那一刻，CPU的复位向量会跳到一个固定的地址。这个地址里存放的是芯片出厂时固化的BootROM代码。BootROM是只读的，你改不了它，我也改不了它。

BootROM的职责其实很简单：

• 硬件自检：检查CPU、内存、时钟等基本硬件是否正常。我遇到过一块板子，上电后死活起不来，最后发现是晶振虚焊了。BootROM检测到时钟异常，直接卡死在那。
• 初始化存储控制器：让CPU能访问Flash和RAM。没有这一步，后面的代码根本没地方放。
• 加载Bootloader：从Flash（比如eMMC、NAND）中把Bootloader代码读到RAM里，然后跳过去执行。

3.2 第二阶段：Bootloader——系统的"引路人"

Bootloader是芯片厂商或设备厂商自己写的。鸿蒙系统常用的Bootloader是uboot，当然也有厂商自己魔改的版本。

Bootloader要干的事比BootROM多得多：

• 初始化更多外设：比如串口、USB、网卡。我记得有一次调试，uboot阶段串口没输出，我以为是代码跑飞了，查了半天才发现是串口引脚复用配置错了。
• 加载内核镜像：从存储介质（eMMC、SD卡、网络）中把鸿蒙内核镜像读到内存里。
• 传递启动参数：告诉内核内存布局、设备树信息、根文件系统位置等。
• 提供烧录和调试功能：uboot里可以刷固件、修改环境变量，这是开发阶段的救命稻草。

3.3 第三阶段：内核启动——系统的"心脏"开始跳动

Bootloader跳转到内核入口后，内核开始接管系统。鸿蒙内核的启动流程大致如下：

// 内核启动核心流程（伪代码）
start_kernel() {
    setup_arch();           // 架构相关初始化（MMU、中断向量表）
    trap_init();            // 异常处理初始化
    mm_init();              // 内存管理初始化
    sched_init();           // 调度器初始化
    init_IRQ();             // 中断控制器初始化
    console_init();         // 控制台初始化（终于能看到日志了）
    // ... 其他子系统初始化
    rest_init();            // 创建init进程
}

这里有个细节：控制台初始化之前，你什么都看不到。如果内核在console_init之前崩溃了，你连个错误提示都没有。我曾经调试一个内核启动崩溃的问题，只能靠JTAG单步跟踪，那叫一个痛苦。

内核启动的最后一步是rest_init()，它会创建第一个用户态进程——init进程。从这一刻起，系统从内核态切换到用户态。

3.4 第四阶段：init进程——用户空间的"一号首长"

init进程是鸿蒙系统用户空间的第一个进程，PID为1。它的职责是启动所有其他系统服务。

鸿蒙的init进程会做以下几件事：

• 解析启动脚本：鸿蒙使用.cfg或.rc格式的配置文件，里面定义了要启动哪些服务、依赖关系、启动顺序。
• 启动关键服务：比如servicemanager（服务管理器）、hdf（硬件驱动框架）、foundation（基础服务框架）等。
• 监控服务状态：如果某个服务挂了，init进程可以自动重启它。这个机制在嵌入式设备上特别重要，因为设备可能长时间无人值守。

我个人习惯在init脚本里加一些调试打印，比如每个服务启动前后都打一条日志。这样如果某个服务启动失败，我能立刻定位到是哪个环节出了问题。

3.5 第五阶段：系统服务启动——从"能用"到"好用"

init进程启动的服务是分层次的：

服务层次	典型服务	职责
核心服务	servicemanager, hdf	服务注册与发现、硬件抽象
系统服务	foundation, ability_manager	应用管理、生命周期管理
UI服务	window_manager, render_service	窗口管理、图形渲染
应用服务	launcher, systemui	桌面、状态栏

这些服务之间有依赖关系。比如，window_manager必须在render_service启动之后才能工作。如果依赖关系没处理好，服务启动就会失败。

嗯，这里要注意：服务启动顺序是写在配置文件里的，但实际运行中可能会有竞态条件。我曾经遇到一个bug，两个服务同时访问同一个硬件资源，导致其中一个初始化失败。后来在配置里加了wait_for依赖才解决。

当所有核心服务启动完毕，launcher（桌面程序）开始运行，用户就能看到桌面了。从按下电源键到这一刻，通常需要3到10秒，具体取决于硬件性能和系统复杂度。

---