BitBake 核心机制：任务执行模型、依赖解析、缓存与性能调优
BitBake 是 Yocto 的心脏。说白了，它就是个超级调度器。你写了几百个配方，它得知道先跑谁、后跑谁，哪些能并行，哪些必须排队。我刚开始接触 Yocto 时，总觉得 BitBake 是个黑盒子——丢进去一个 bitbake core-image-minimal，它就自己忙活半天。后来踩了不少坑，才慢慢摸清它的脾气。
这一章，我们就把它拆开看看。
任务执行模型：BitBake 到底怎么跑任务的？
每个配方（recipe）不是一整个脚本。它被拆成了多个任务（task）。比如 do_fetch、do_unpack、do_patch、do_configure、do_compile、do_install……每个任务都是一个独立的执行单元。
BitBake 的执行模型，可以理解为一个有向无环图（DAG）的遍历器。它会先解析所有配方，构建出任务依赖图，然后按拓扑顺序执行。
核心要点：BitBake 不是按配方顺序执行的，而是按任务依赖关系执行的。同一个配方的不同任务可能被其他配方的任务打断——只要依赖允许。
举个例子：libfoo 的 do_compile 依赖 libbar 的 do_populate_sysroot。BitBake 会先确保 libbar 的 sysroot 准备好了，再开始编译 libfoo。但 libfoo 的 do_fetch 和 libbar 的 do_fetch 可以同时跑——只要网络带宽扛得住。
我个人习惯用 bitbake -g 来生成依赖图，然后用 Graphviz 可视化。遇到构建失败时，这招特别管用。
依赖解析：BitBake 怎么知道谁先谁后？
依赖解析是 BitBake 最核心的能力。它分两个层面：
1. 配方级依赖（Recipe-level Dependencies）
你在配方里写的 DEPENDS 和 RDEPENDS，就是告诉 BitBake：「我依赖谁」。BitBake 会递归解析所有依赖，构建出完整的依赖树。
# 示例：libfoo 依赖 libbar 和 libbaz
DEPENDS = "libbar libbaz"
# libbar 又依赖 libcommon
# libbaz 又依赖 libcommon 和 libutils
# BitBake 会递归解析，最终得到完整的依赖图2. 任务级依赖（Task-level Dependencies）
这是更细粒度的控制。有时候你不需要整个配方，只需要它的某个任务完成。比如：
# 只有 do_configure 依赖 libbar 的 do_populate_sysroot
do_configure[depends] += "libbar:do_populate_sysroot"我在项目中遇到过一个问题：两个配方互相依赖对方的 do_populate_sysroot，结果 BitBake 报循环依赖。查了半天才发现是配方写错了，把 DEPENDS 写成了双向依赖。嗯，这里要注意——循环依赖是 BitBake 的死穴，它不会自动帮你解开。
避坑指南：我曾经在某个 BSP 层里看到有人用 DEPENDS += "${@'libfoo' if d.getVar('SOME_VAR') == '1' else ''}" 这种动态依赖。结果条件变量在不同配方里解析结果不一致，导致依赖图不稳定，构建时有时无。建议尽量用静态依赖，动态依赖只在万不得已时使用。
缓存机制：BitBake 怎么避免重复劳动？
BitBake 的缓存机制叫 Shared State Cache（sstate-cache）。它的核心思想很简单：如果某个任务的输入没变，输出就可以复用。
每个任务执行前，BitBake 会计算一个哈希值（hash）。这个哈希基于：
- 配方的内容（包括 .bb、.bbappend、.inc 文件）
- 所有依赖的哈希值
- 任务本身的输入（比如源码、补丁、配置选项）
- 全局变量（比如
TUNE_FEATURES、DISTRO_FEATURES）
如果哈希匹配，BitBake 就直接从 sstate-cache 里恢复输出，跳过实际执行。这就是为什么第二次构建比第一次快很多。
小技巧：我习惯在 local.conf 里设置 SSTATE_DIR 指向一个共享目录（比如 NFS 挂载）。这样整个团队可以共享缓存，节省大量构建时间。但要注意——不同机器架构的 sstate 不能混用，否则会出奇怪的问题。
缓存失效（cache miss）是性能杀手。常见原因包括：
| 原因 | 说明 | 排查方法 |
|---|---|---|
| 变量变化 | 比如 DISTRO_FEATURES 加了新特性 |
用 bitbake-diffsigs 对比哈希差异 |
| 源码更新 | SRC_URI 指向的仓库有新的 commit | 检查 SRCREV 是否固定 |
| 依赖链变化 | 某个上游配方的哈希变了，导致下游全部失效 | 用 bitbake -S printdiff 追踪变化链 |
| 时间戳问题 | 某些任务依赖文件时间戳而非内容 | 检查是否有 do_install 里用了 cp -p 保留时间戳 |
并行执行：BitBake 怎么同时跑多个任务？
BitBake 的并行执行分两个维度：
- BB_NUMBER_THREADS：控制同时执行的任务数（默认等于 CPU 核心数）
- PARALLEL_MAKE：控制单个任务的 make 并行度（传给
-j参数）
你想想看，如果 BB_NUMBER_THREADS=8，每个任务又 PARALLEL_MAKE=-j 8，那理论上可能同时跑 64 个编译线程。但实际效果取决于你的硬件——CPU 核心数、内存大小、磁盘 I/O 都是瓶颈。
经验值：我一般把 BB_NUMBER_THREADS 设为 CPU 物理核心数，PARALLEL_MAKE 设为 CPU 逻辑线程数。比如 4 核 8 线程的机器，就是 BB_NUMBER_THREADS = "4"，PARALLEL_MAKE = "-j 8"。这样既能充分利用 CPU，又不会因为任务切换太频繁导致性能下降。
但并行执行也有副作用。最典型的是资源竞争——多个任务同时写同一个文件，或者同时占用大量内存导致 OOM。我曾经在 8GB 内存的机器上构建一个包含 LLVM 的镜像，结果 BitBake 同时启动了 4 个 LLVM 编译任务，每个吃掉 3GB 内存……系统直接卡死。
避坑指南：对于内存密集型任务（比如 LLVM、GCC、Chromium），建议在配方里设置 PARALLEL_MAKE = "-j 2" 甚至 PARALLEL_MAKE = "-j 1"。或者用 BB_NUMBER_THREADS 限制总并发数。别贪心，稳定比速度重要。
性能调优：让 BitBake 跑得更快
调优 BitBake 性能，我总结了几个实用技巧：
1. 合理配置 sstate 缓存
把 SSTATE_DIR 放在 SSD 上。机械硬盘的随机读写性能是瓶颈。如果团队协作，用共享 sstate 缓存可以节省 70% 以上的构建时间。
2. 使用 tmpfs 加速临时文件
把 TMPDIR 的部分子目录挂载到内存盘：
# 在 local.conf 中
TMPDIR = "/tmp/yocto-build"
# 然后手动挂载 tmpfs
# mount -t tmpfs -o size=32G tmpfs /tmp/yocto-build注意：内存要够大。32GB 内存的机器，分 16GB 给 tmpfs 比较安全。
3. 减少不必要的任务
有些任务你根本不需要。比如只构建 SDK 时，可以跳过 do_populate_sysroot：
# 在配方中
do_populate_sysroot[noexec] = "1"4. 使用 bitbake -S 调试缓存问题
当缓存命中率低时，用 bitbake -S printdiff 找出是哪个变量或文件导致了哈希变化。这招我几乎每周都用。
5. 调整 BB_DISKMON_DIRS
设置磁盘监控，避免磁盘写满导致构建失败：
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K"BitBake 核心机制全景图
下面这张图展示了 BitBake 从配方解析到任务执行的全流程。我建议你把它保存下来，遇到构建问题时对照着排查。
这张图把 BitBake 的核心流程串起来了。你从左上角开始看：配方解析 → 依赖解析 → 哈希计算 → 判断缓存是否命中 → 命中则恢复缓存，否则执行任务 → 并行调度 → 生成输出 → 更新 sstate。每次构建都走这个循环。
嗯，到这里 BitBake 的核心机制就讲完了。这些内容看起来有点抽象，但你在实际项目中遇到构建问题，回头再看这一章，会有不一样的体会。毕竟，理论是灰色的，而实践之树常青。