1. 课程导入
在嵌入式 Linux、工业控制、车载终端、边缘计算网关等场景中，设备从上电到业务可用的时间，往往直接决定用户体验与产品竞争力。内核启动完成后，第一个用户态进程通常就是 init。它像一位“总调度员”，负责挂载文件系统、加载驱动模块、配置网络、启动服务、拉起应用程序，并最终把系统交到用户手中。本课程围绕“定制 init 脚本实现系统快速启动工程”展开，目标不是简单写一个能跑的启动脚本，而是建立一套可度量、可裁剪、可并行、可回退的启动工程方法。
学习目标
- 理解 init 在系统启动链路中的位置、职责与生命周期。
- 掌握从内核交接、init 解析、服务编排到业务就绪的完整启动路径。
- 能够识别启动耗时瓶颈，使用时间戳、日志与启动阶段划分进行量化分析。
- 能够通过脚本裁剪、依赖重排、并行启动、延迟加载等手段优化启动时间。
- 建立快速启动工程的评估指标、验证方法与回退策略。
init 脚本在系统启动中的角色
系统启动通常经历 BootROM、Bootloader、内核解压与初始化、挂载根文件系统、执行 init、启动用户态服务等阶段。init 是内核启动完成后的第一个用户态进程，PID 为 1。它承担三类核心职责：第一，完成系统基础环境初始化，例如挂载 /proc、/sys、/dev、/tmp，设置主机名、时区、环境变量；第二，按依赖关系启动系统服务，例如网络、日志、数据库、通信中间件；第三，监控关键进程，在异常退出时进行重启或进入恢复模式。
传统 SysV init 通过 /etc/inittab 和 /etc/init.d/ 脚本串行执行，结构清晰但启动慢。BusyBox init 常见于嵌入式系统，配置简单、体积小，适合资源受限设备。systemd 通过单元依赖和并行启动提升效率，但依赖较复杂。对于定制快速启动工程，常见做法是基于 BusyBox init 或轻量级 init，配合自定义脚本，精确控制启动顺序与并行度。
快速启动工程的整体框架
快速启动工程不是单点优化，而是一套从度量到验证的闭环。整体框架可分为五层：
- 度量层：在 Bootloader、内核、init 脚本、关键服务中插入时间戳，记录各阶段耗时，形成启动时间基线。
- 分析层：通过日志、
bootchart、systemd-analyze或自定义打点，找出耗时最长的阶段与阻塞点。 - 优化层：裁剪无用服务、合并脚本、调整依赖顺序、并行启动、延迟加载、预加载缓存、使用只读文件系统减少 I/O。
- 验证层：在目标硬件上多次冷启动，统计平均值、最大值与抖动，确认优化效果稳定。
- 回退层：保留原始启动脚本与配置，出现异常时可快速切换，避免“优化后无法启动”的风险。
核心原则：先度量，后优化；先保证可启动，再追求快启动；任何优化都必须有回退路径。
案例场景：工业网关的启动优化
某工业网关采用 ARM Cortex-A7 平台，原启动脚本串行执行 18 个服务，从上电到业务可用约 28 秒。通过打点发现，网络配置等待 DHCP 超时占 8 秒，日志服务与数据库服务串行启动占 6 秒，非关键调试服务占 3 秒。优化措施包括：将网络配置改为静态 IP 并并行启动；将日志与数据库改为依赖就绪后异步启动；裁剪调试服务；将部分驱动模块改为按需加载。最终启动时间降至 11 秒，且通过回退脚本保证异常时可恢复原启动流程。
# 启动打点示例
echo "init start: $(date +%s.%N)" > /dev/kmsg
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs devtmpfs /dev
echo "base env ready: $(date +%s.%N)" > /dev/kmsg
# 并行启动无依赖服务
/etc/init.d/network start &
/etc/init.d/logger start &
wait
echo "core services ready: $(date +%s.%N)" > /dev/kmsg
# 业务应用启动
/usr/bin/gateway_app &
echo "business ready: $(date +%s.%N)" > /dev/kmsg学习路径与常见误区
| 阶段 | 学习重点 | 产出物 |
|---|---|---|
| 第 1～5 章 | 启动链路、init 角色、脚本语法、阶段划分 | 启动时间基线、阶段打点脚本 |
| 第 6～15 章 | 服务依赖、并行启动、裁剪策略、文件系统优化 | 优化后的 init 脚本、依赖关系图 |
| 第 16～25 章 | 实测调优、异常处理、回退机制、自动化验证 | 启动测试报告、回退方案 |
| 第 26～30 章 | 工程化封装、版本管理、持续集成、复盘 | 快速启动工程模板与规范 |
常见误区：一是只关注 init 脚本本身，忽略内核与 Bootloader 耗时；二是盲目并行，导致资源竞争或依赖错乱；三是没有基线数据，优化效果无法量化；四是删除服务时未确认业务依赖，造成功能缺失；五是没有回退方案，现场设备无法恢复。
建议：从本章开始，为你的目标设备建立一份“启动时间记录表”，记录每次冷启动的总时间与各阶段时间。后续每一章的优化，都应以这张表为依据，做到可对比、可复现、可回退。
init 脚本是系统启动从内核态走向用户态的关键桥梁，也是快速启动工程中最可控、最值得深入优化的环节。掌握启动链路、阶段划分、度量方法与优化原则，是后续定制脚本、裁剪服务、并行编排和工程化落地的基础。