Yocto构建太慢？一招本地缓存复用，让二次编译提速70%+
你有没有经历过这样的场景：
第一次跑bitbake core-image-minimal，耗时整整6小时。第二天改了一行配置再构建——结果又是从头开始，又是几小时等待？
网络还在频繁下载同样的源码包，编译器重复编译早已稳定的基础组件……这哪是开发，简直是煎熬。
在嵌入式Linux的世界里，Yocto Project几乎成了定制系统构建的代名词。它强大、灵活、可裁剪到极致，但“慢”也确实是它的标签之一。尤其当你处于多分支调试、CI/CD自动化测试或团队协作开发阶段时，每一次全量构建都在消耗时间与耐心。
但其实，Yocto早就为你准备了“加速外挂”——本地缓存机制。只要合理配置，就能实现“一次辛苦，终身受益”，后续构建直接跳过90%的重复劳动，把6小时压缩成不到2小时，甚至更快。
今天我们就来拆解这套“缓存加速体系”，不讲虚的，只说你能立刻上手的实战方案。
为什么你的Yocto总是在“重新造轮子”？
BitBake 是 Yocto 的核心引擎，它按任务（task）驱动整个构建流程：获取源码 → 解压补丁 → 编译 → 打包 → 镜像生成……每个步骤都可能耗时数分钟甚至几十分钟。
问题在于，默认情况下，这些中间成果都是“一次性”的。哪怕你只是改了个镜像名称，或者切换了个分支再切回来，BitBake 往往还是会重走一遍流程——因为它不知道你之前已经做过这件事。
除非……我们告诉它：“嘿，这个我有现成的，别重来了。”
这就是缓存的意义：将已完成的任务结果保存下来，在条件不变的前提下直接复用，从而跳过执行过程。
而 Yocto 提供了三个关键层级的缓存能力：
- sstate 缓存—— 存的是“中间产物”
- DL_DIR + PREMIRRORS—— 存的是“源代码”
- 共享 TMPDIR 结构—— 存的是“全过程痕迹”
三者联动，才能真正实现高效增量构建。
sstate 缓存：让你跳过80%的编译工作
它到底存了什么？
sstate全称 shared state，翻译过来就是“共享状态”。你可以把它理解为一个智能打包机：每当某个任务完成（比如内核编译完、glibc打包好），Yocto 就会把这个结果打个包，加上一个“指纹”存起来。
下次构建时，如果 BitBake 发现当前任务的输入没有任何变化（源码没动、配置一致、依赖相同），就会比对指纹，命中后直接解包复用，完全跳过实际执行。
常见的 sstate 输出包括：
- 已编译的软件包（.ipk,.rpm,.deb）
- 内核模块和固件
- 根文件系统镜像（core-image-*）
- SDK 工具链
- 配置文件集合
这些往往是构建中最耗时的部分。一旦缓存生效，你就不再需要从零编译 busybox、systemd 或 Qt5。
怎么启用？两行配置搞定
打开你的conf/local.conf，加入以下内容：
SSTATE_DIR = "/opt/yocto-cache/sstate" SSTATE_MIRRORS ?= "file://.* file:///${SSTATE_DIR}/PATH"就这么简单？没错。第一行指定缓存存放路径，第二行告诉 BitBake：“先去这个目录找有没有现成的包”。
更进一步，如果你公司内部有统一缓存服务器，还可以加一个远程镜像：
SSTATE_MIRRORS += "\n \ https://sstate.yoctoproject.org/PATH \n \ http://mirror.internal.net/yocto/sstate/PATH"这样，本地没有就去局域网拿，还找不到再去官方源拉取。层层兜底，最大限度避免重复劳动。
⚠️ 注意：sstate 包是带签名的，只有当 MACHINE、DISTRO、TUNE 等所有影响输出的因素完全一致时才会被复用。换平台=换缓存。
下载缓存 DL_DIR：告别反复下载 Linux 内核源码
你有没有注意到每次构建，git clone linux-yocto 要跑好几分钟？wget 下载 gcc 补丁又卡半天？
这些都是因为 Yocto 默认每次都会尝试从原始地址拉取源码，即使你昨天刚下过一模一样的一份。
解决办法也很直接：集中管理所有下载内容。
DL_DIR 的作用
DL_DIR是 Yocto 的“源码仓库”，所有通过SRC_URI声明的资源（tarball、git repo、patch 文件）最终都会落到这里。
配合PREMIRRORS使用，可以做到：
- 第一次构建：正常下载，并自动缓存到 DL_DIR
- 第二次构建：直接从本地读取，跳过网络请求
- 多个项目共用：不同工程之间也能共享同一份源码
省下的不只是时间，还有带宽和稳定性风险。
实战配置示例
继续在local.conf中添加：
DL_DIR = "/opt/yocto-cache/downloads" PREMIRRORS_prepend = "\ git://.*/.* file:///${DL_DIR}/ \n \ https?://.*/.* file:///${DL_DIR}/ \n \ ftp://.*/.* file:///${DL_DIR}/"这几行的意思是：所有 git、http(s)、ftp 协议的下载请求，优先查看本地/opt/yocto-cache/downloads/目录是否存在对应文件。如果有，直接拿来用；没有才走远端。
举个例子：
- 第一次构建时，https://github.com/torvalds/linux/archive/v6.1.tar.gz会被下载并保存为：/opt/yocto-cache/downloads/v6.1.tar.gz
- 第二次遇到相同的 SRC_URI，Yocto 会先查本地路径，发现存在即跳过下载。
💡 小技巧：你可以手动把常用的大型源码包提前放进去，比如 chromium、webkit、opencv 等，首次构建速度立竿见影。
共享构建输出目录：跨项目复用的秘密武器
很多人习惯每次清理用bitbake -c cleanall，觉得“干净清爽”。但在真实开发中，这是最伤效率的操作之一。
因为cleanall不仅清除了目标产物，还会删掉 sstate 缓存、下载文件链接、工作目录……相当于把之前所有的努力全部归零。
正确的做法是：保留 TMPDIR，精细清理。
TMPDIR 到底存了啥？
默认情况下，Yocto 的临时输出目录是tmp/，里面包含几个关键子目录：
| 目录 | 用途 |
|---|---|
work/ | 每个 recipe 的解压、补丁、编译中间文件 |
sstate-cache/ | 所有生成的 sstate 包 |
deploy/images/ | 最终生成的镜像文件 |
sysroot/ | 交叉编译所需的头文件和库 |
其中work/和sstate-cache/是缓存复用的核心。只要你保留它们，哪怕换了项目分支，只要基础层一致，依然能大幅加速。
如何安全地清理？
推荐使用粒度更细的命令：
# 只清理内核相关的任务 bitbake -c clean virtual/kernel # 强制重建内核（不清除其他） bitbake -f linux-yocto && bitbake virtual/kernel而不是：
# ❌ 错误示范：全局清除，破坏缓存连续性 bitbake -c cleanall core-image-minimal后者会导致所有中间成果丢失，下次构建又要从头再来。
多人协作怎么搞？
建议将TMPDIR挂载到 NFS 或高性能 SSD 上，并设置统一路径：
# 在 local.conf 中固定输出目录 TMPDIR = "/opt/yocto-build/tmp-shared"多个开发者或 CI 节点指向同一个位置，形成“缓存池”。一个人构建过的成果，其他人可以直接继承。
当然，权限要管好，避免误删。可以用组权限 + 定期备份的方式保障安全。
团队级缓存架构设计：让整个团队一起快起来
单机优化只是起点。真正的效率飞跃，发生在整个团队共建一套缓存体系的时候。
典型部署结构
+----------------------------+ | Central Cache Server | | /opt/yocto-cache/ | | ├── downloads/ | ← DL_DIR | └── sstate-cache/ | ← SSTATE_DIR +--------------+-------------+ | +-------------------------+--------------------------+ | | | +--------v-------+ +---------v--------+ +--------v-------+ | Developer A | | Developer B | | CI Pipeline | | - 共享缓存 |<----->| - 共享缓存 |<----->| Jenkins/GitLab | +----------------+ +------------------+ +----------------+所有人构建时优先查找中心缓存，新生成的内容也自动回传。越多人参与，缓存越丰富，整体构建越快。
关键配置要点
统一路径映射
bash SSTATE_DIR = "/opt/yocto-cache/sstate" DL_DIR = "/opt/yocto-cache/downloads"开启 pre-mirror 回源机制
bash PREMIRRORS_prepend = "git://.*/.* http://mirror.internal.net/sources/"定期维护脚本
- 使用repo-delete-sstate清理过期条目
- 按 Yocto 版本分目录存储（如sstate-honister/,sstate-dunfell/）版本隔离策略
不同 Yocto 版本之间的 sstate不兼容！务必分开存储，否则可能导致构建失败或二进制异常。
常见坑点与避坑指南
❌ 缓存无效？检查这几个地方！
机器名变了
MACHINE="qemux86-64"和MACHINE="qemuarm"用的不是同一套缓存。合理规划硬件抽象层。配置变量漂移
在 local.conf 中随意添加EXTRA_OECONF或修改PACKAGECONFIG，都会导致签名变更，缓存失效。未启用 SSTATE_MIRRORS
即使本地有缓存，若未正确配置SSTATE_MIRRORS，BitBake 也不会去查。路径拼写错误
file:///${SSTATE_DIR}/PATH中的PATH是占位符，实际会被自动替换为具体路径。不要手动填写路径名。
总结：构建加速的本质是“知识沉淀”
Yocto 构建之所以慢，是因为它太“诚实”了——每一步都严格按照规则执行，不会记住上次做了什么。
而我们的任务，就是教会它“记性好一点”。
通过合理配置sstate 缓存、DL_DIR 下载缓存和共享构建目录，我们实际上是在建立一个“组织级的知识资产库”：
每一次成功的构建，都不只是产出一个镜像，更是为未来的每一次迭代积累资本。
当你下次看到 BitBake 输出NOTE: Tasks Summary: Attempted 300 tasks of which 280 were skipped due to no change，那种感觉就像——
“我曾经辛苦过一次，从此全世界都为我让路。”
这才是现代嵌入式开发应有的节奏。
如果你正在搭建 CI/CD 流水线，或是带领团队进行 Yocto 工程化落地，不妨现在就动手配置一套本地缓存系统。第一天多花半小时，换来的是未来几百次构建的持续收益。
毕竟，时间才是嵌入式开发者最稀缺的资源。
评论区聊聊：你们团队是怎么做 Yocto 缓存管理的？有没有踩过哪些大坑？欢迎分享经验！
