1. SDK镜像概述：从零开始理解你的系统“照片”
大家好，我是你们的老朋友。今天咱们聊聊SDK镜像。
说实话，我刚入行那会儿，对“镜像”这个词挺懵的。不就是个文件吗？后来踩了不少坑才明白——镜像就是嵌入式设备的“系统快照”。你想想看，你的手机、路由器、智能摄像头，它们上电后跑的那一套东西，全打包在一个文件里，这就是镜像。
核心定义：SDK镜像 = Bootloader + Kernel + Rootfs + App分区 + 配置数据。它是设备出厂前烧录到Flash里的完整系统。
1.1 镜像的组成结构：四层“蛋糕”
一个典型的嵌入式镜像，我习惯把它拆成四层。每一层都有它的脾气。
| 分区名称 | 作用 | 典型大小 | 我踩过的坑 |
|---|---|---|---|
| Bootloader | 硬件初始化，加载内核 | 64KB ~ 2MB | 曾经把uboot编译太大，分区装不下，板子变砖 |
| Kernel | 操作系统核心，驱动管理 | 2MB ~ 8MB | 驱动模块没裁剪，内核膨胀到12MB，Flash放不下 |
| Rootfs | 根文件系统，用户空间基础 | 4MB ~ 64MB | busybox编译时忘了删gzip，多了200KB |
| App分区 | 应用程序、配置文件、数据 | 8MB ~ 128MB | 客户要求OTA升级，App分区没留余量，尴尬 |
嗯，这里要注意：分区大小不是拍脑袋定的。你得先算清楚Flash总容量，再根据功能需求分配。我见过太多项目，前期分区随便分，后期功能加不进去，只能重新布局Flash，那叫一个痛苦。
1.2 镜像文件格式：.img、.squashfs、.ubifs
格式这东西，说白了就是“怎么把数据塞进Flash”。不同的Flash类型，适合不同的格式。
.img 格式：最原始的“裸镜像”
就是二进制数据的直接拷贝。我早期做单片机项目时常用。优点是简单，缺点是没压缩、没校验。
# 生成一个16MB的空白镜像
dd if=/dev/zero of=rootfs.img bs=1M count=16
# 把文件系统挂进去
sudo mount -o loop rootfs.img /mnt
sudo cp -a rootfs/* /mnt/
sudo umount /mnt我的习惯：.img格式适合NAND Flash，但一定要加上ECC校验。不然数据翻转了，你都不知道。
.squashfs：只读压缩文件系统
这个我特别喜欢。它把文件系统压缩成一个只读的块设备。优点是体积小（压缩率通常50%~70%），缺点是运行时不能写。
# 制作squashfs镜像
mksquashfs rootfs/ rootfs.squashfs -comp xz -b 128K
# 查看压缩率
ls -lh rootfs/ rootfs.squashfs注意：squashfs适合存放不变的系统文件。如果你需要运行时修改配置，得搭配一个可写的overlay分区。我曾经没做overlay，结果客户想改个WiFi密码都改不了，被骂惨了。
.ubifs：专为NAND Flash设计的文件系统
UBIFS是JFFS2的升级版。它针对大容量NAND做了优化，支持磨损均衡、掉电恢复。我一般在Flash大于64MB时用它。
# 制作UBIFS镜像
mkfs.ubifs -r rootfs/ -m 2048 -e 128KiB -c 1024 -o rootfs.ubifs
# 打包成ubi镜像
ubinize -o ubi.img -m 2048 -p 128KiB ubinize.cfg选型建议：
- NOR Flash（小容量，< 16MB）：用squashfs + JFFS2 overlay
- NAND Flash（中容量，16MB~256MB）：用UBIFS
- eMMC（大容量，> 256MB）：用ext4 + squashfs混合
1.3 镜像大小对产品的影响：每一KB都是钱
你可能会想：“多几MB怎么了？现在Flash又不贵。” 嗯，这话在消费电子上可能对，但在嵌入式领域，每一KB都直接关系到成本、性能和可靠性。
我举个例子。之前做一款智能门锁，Flash选的是8MB NOR。客户要求加一个语音播报功能，结果音频文件一放，镜像从5MB涨到7.5MB。你猜怎么着？
- 成本：8MB NOR涨价到16MB，BOM成本多了$0.8。年出货100万片，就是80万美元。
- 性能：镜像大了，烧录时间从30秒变成60秒。产线效率直接砍半。
- 可靠性：Flash剩余空间太少，磨损均衡效果差，寿命缩短。
- OTA升级：镜像大了，下载时间变长，失败率上升。用户骂声一片。
镜像大小的影响矩阵：
| 维度 | 镜像每增加1MB的影响 |
|---|---|
| BOM成本 | Flash升级一档，成本增加$0.3~$1.5 |
| 烧录时间 | 增加10~30秒（取决于烧录器速度） |
| OTA下载时间 | 2G网络下增加约5分钟 |
| 系统启动时间 | 增加0.5~2秒（解压+挂载） |
| Flash寿命 | 剩余空间减少，磨损加剧，寿命缩短20%~50% |
所以，我每次做SDK发布前，都会做一件事：镜像大小审计。把每个分区的大小列出来，看看有没有“虚胖”的地方。比如，删掉没用的驱动模块、用strip去掉调试符号、用xz压缩代替gzip。这些操作加起来，往往能省下30%~50%的空间。
避坑指南：我曾经为了省空间，把rootfs里的locale全删了。结果客户是德国人，系统显示不了德语，被投诉了。所以，裁剪前一定要确认客户需求。有些“无用”文件，对特定用户就是刚需。
1.4 知识体系结构图
下面这张图，是我自己总结的SDK镜像知识体系。你可以把它当作本章的“地图”。
这张图把本章的核心内容串起来了。从左到右，从上到下，分别是“组成结构”、“文件格式”、“大小影响”。你可以在后续章节中，随时回来参考这张图。
好了，关于SDK镜像的基本概念，咱们就聊到这儿。记住一句话：镜像不是越大越好，也不是越小越好，而是“刚刚好”最好。这个“刚刚好”，需要你对硬件、软件、客户需求都有深刻理解。后面几章，我会带你一步步掌握裁剪和优化的具体技巧。
可可精品资料库