第一章：课程导论与性能基线
1.1 Buildroot 到底是什么？
先聊聊 Buildroot 吧。很多人把它当成一个「嵌入式 Linux 编译工具」，其实没那么简单。
我个人习惯把它看作一个自动化工厂。你给它一张「配料表」——也就是你的硬件配置、内核版本、文件系统需求——它就能帮你把整个嵌入式 Linux 系统从头到尾编译出来。从交叉工具链、bootloader、内核，到根文件系统里的 busybox、第三方库、你的应用程序，一条龙搞定。
我刚开始用 Buildroot 时，觉得它跟 Yocto 差不多。后来踩了坑才发现，两者思路完全不同。Yocto 是「我要什么，你给我造什么」，Buildroot 是「我给你什么，你帮我拼什么」。说白了，Buildroot 更轻量、更直接，适合我们这种追求「快速出活」的团队。
1.2 为什么需要性能调优？
你可能会问：「Buildroot 默认编译出来的系统，跑起来不也挺好吗？」
嗯，这话对了一半。默认配置确实能跑，但跑得怎么样，差别大了去了。
我在一个工业网关项目里遇到过这种情况：同样的硬件，用默认配置编译出来的系统，从按下电源键到进入应用界面，花了 18 秒。客户说不行，竞品只要 6 秒。后来我们花了三周做启动流程优化，最终压到了 4.2 秒。你想想看，这中间差了将近 14 秒，用户体验完全是两个世界。
性能调优的核心目标就三个：
- 启动更快——减少用户等待时间，提升产品竞争力
- 内存更省——嵌入式设备内存本来就金贵，能省一点是一点
- 功耗更低——启动阶段是功耗高峰，缩短启动时间等于直接省电
说白了，调优不是炫技，是实打实的商业需求。
1.3 启动流程全景图
要调优，先得知道系统是怎么「醒」过来的。嵌入式 Linux 的启动流程，我习惯把它分成四个阶段：
| 阶段 | 主要工作 | 典型耗时占比 |
|---|---|---|
| Bootloader | 初始化硬件、加载内核镜像到内存 | 10% - 20% |
| Kernel 启动 | 解压内核、初始化驱动、挂载根文件系统 | 30% - 40% |
| Init 进程 | 执行初始化脚本、启动系统服务 | 20% - 30% |
| 应用启动 | 加载用户程序、初始化业务逻辑 | 10% - 20% |
每个阶段都有优化空间。比如 Bootloader 阶段，可以裁剪不必要的硬件初始化；Kernel 阶段，可以精简驱动、优化解压算法；Init 阶段，可以并行化服务启动、去掉用不上的守护进程。
下面这张图，是我自己画的一个启动流程全景图，方便你建立整体认知：
1.4 建立性能基线的方法论
调优最忌讳「拍脑袋」。没有基线数据，你根本不知道改完是变好了还是变差了。
我见过不少工程师，上来就改内核配置、换文件系统，折腾半天自我感觉良好，一测启动时间反而变长了。为什么？因为没有基线，没有对比。
建立性能基线，我总结了一套「三步法」：
- 选指标——确定你要测量什么。常见指标有：
- 冷启动总时间（从上电到应用就绪）
- 各阶段耗时分布
- 峰值内存占用
- 根文件系统大小
- 定工具——用什么来测？
printk时间戳：内核自带，零成本bootgraph/bootchart：可视化启动过程perf：内核级性能分析- GPIO 示波器：最原始但最精确的方法
- 做记录——每次修改前，先跑一遍基线，把数据记下来。我习惯用表格记录：
| 版本 | Bootloader (s) | Kernel (s) | Init (s) | 应用 (s) | 总计 (s) |
|---|---|---|---|---|---|
| v1.0 基线 | 1.2 | 3.8 | 2.5 | 1.5 | 9.0 |
| v1.1 优化 | 0.8 | 2.1 | 1.8 | 1.2 | 5.9 |
有了基线，你才能回答三个关键问题：
- 「现在有多慢？」——量化现状
- 「瓶颈在哪？」——定位问题
- 「改完有效吗？」——验证效果
我个人习惯在项目初期就建立基线，哪怕系统还不完整。先测个大概，后面逐步细化。这样每次改动都有据可查，不会迷失方向。
1.5 本章小结
这一章我们聊了 Buildroot 的定位、性能调优的必要性、启动流程的四个阶段，以及建立基线的方法。说白了，调优不是玄学，是科学。科学的第一步，就是测量。