22、位域与压缩存储：使用位域节省内存、位域与压缩算法的结合
说实话，位域这东西，我早年做嵌入式开发时总觉得它有点「鸡肋」。你说它省内存吧，省得不多；你说它麻烦吧，用起来确实得小心。直到有一次我在一个资源受限的传感器节点上做协议栈，内存只有 4KB，一个数据包结构体就占了 60 多个字节——我算了一下，光包头就浪费了将近 30% 的空间。嗯，从那以后，我再也不敢小看位域了。
位域的基本用法
位域，说白了就是让你精确控制结构体成员占几个比特位。C 语言里最小的单位是字节，但很多时候我们根本不需要一整个字节。比如一个布尔值，1 个比特就够了；一个状态码，可能只需要 3 个比特。
struct PacketHeader {
unsigned int version : 4; // 4 bits，范围 0-15
unsigned int type : 3; // 3 bits，范围 0-7
unsigned int flag : 1; // 1 bit，0 或 1
unsigned int length : 8; // 8 bits，范围 0-255
};你看，这个结构体总共只用了 16 个比特，也就是 2 个字节。如果不用位域，用四个 unsigned int 成员，那就是 16 个字节。省了 87.5% 的内存。我当年第一次看到这个数字时，确实被震住了。
关键点：位域成员的类型必须是 int、unsigned int 或 signed int。C99 之后也支持 _Bool。位域的长度不能超过其基础类型的位宽。
位域的内存布局
这里有个坑，我踩过不止一次。位域的内存布局是编译器相关的。不同编译器、不同平台，位域的排列顺序可能不一样。
举个例子，上面的 PacketHeader，在小端模式下，version 占据低 4 位；在大端模式下，version 占据高 4 位。如果你把结构体直接写到文件里，换台机器读出来，数据就全乱了。
我曾经在一个跨平台项目中，用位域定义了一个通信协议头。在 x86 上测试一切正常，部署到 ARM 设备上后，数据解析全错。查了两天才发现是字节序问题。从那以后，我养成了一个习惯：凡是涉及跨平台的数据结构，位域只做内存中的临时表示，序列化时手动移位打包。
位域与压缩算法的结合
位域本身是一种「无损压缩」——它只是把数据按比特位紧密排列。但如果你把位域和真正的压缩算法结合起来，效果会更明显。
我个人的经验是：先用位域把结构体「压紧」，再用 LZSS 或 Huffman 等算法做二次压缩。这样做的好处是，位域消除了结构体内的填充字节，让压缩算法的输入数据更加紧凑，压缩率能提升 10%-20%。
// 未使用位域：24 字节
struct LooseData {
unsigned int a; // 4 bytes
unsigned int b; // 4 bytes
unsigned int c; // 4 bytes
unsigned int d; // 4 bytes
unsigned int e; // 4 bytes
unsigned int f; // 4 bytes
};
// 使用位域：4 字节
struct PackedData {
unsigned int a : 5;
unsigned int b : 6;
unsigned int c : 5;
unsigned int d : 5;
unsigned int e : 6;
unsigned int f : 5;
};你想想看，同样的数据，从 24 字节压缩到 4 字节，压缩率直接到了 83.3%。如果再跑一遍 LZ77，还能再压掉 30%-50%。
位域的实际应用场景
我整理了几个常见的位域使用场景，都是我在项目中实际用过的：
- 网络协议头：TCP/IP、UDP、ICMP 等协议头大量使用位域，比如 TCP 头的标志位（SYN、ACK、FIN 等）每个只占 1 个比特。
- 嵌入式寄存器映射：硬件寄存器通常按位定义功能，用位域可以直接操作特定位，代码可读性比移位操作好得多。
- 文件格式解析：BMP、PNG 等图像文件的头信息中，很多字段都是按比特位定义的。
- 状态机标志位：多个布尔状态可以用一个整数的不同位来表示，节省内存且便于批量操作。
位域的陷阱与避坑
嗯，这里要注意几个容易翻车的地方：
- 取地址操作：位域成员不能取地址（&操作符），因为它们可能不在字节边界上。如果你需要取地址，就别用位域。
- 数组：位域不能是数组类型。你不能写
unsigned int arr : 4[8]，编译器会报错。 - 性能：位域的读写操作会生成额外的移位和掩码指令，比直接访问整型变量慢。在性能敏感的热路径上，慎用。
- 线程安全：位域的读写不是原子操作。多线程环境下，两个线程同时修改同一个位域结构体的不同成员，可能会互相干扰。
我个人习惯：在性能要求不高的配置数据、协议头、状态标志等场景中放心使用位域。在热循环、高频访问的数据结构中，我会用普通的整型变量，手动做移位操作。这样既保证了性能，又保留了位域的可读性。
位域与压缩算法的实战组合
最后分享一个我实际用过的组合方案。当时做一个物联网网关，需要把传感器数据压缩后上传到云端。数据格式是这样的：
struct SensorData {
unsigned int temperature : 10; // -512 到 511，精度 0.1°C
unsigned int humidity : 8; // 0 到 255，精度 1%
unsigned int pressure : 12; // 0 到 4095，精度 0.1 hPa
unsigned int timestamp : 20; // 相对时间戳，精度 1 秒
};这个结构体总共 50 个比特，用 8 字节对齐后实际占用 8 字节。如果不用位域，四个 int 就是 16 字节。然后我用 LZ4 做流式压缩，压缩率从原来的 1.8 倍提升到了 3.2 倍。说白了，位域把数据「捋顺」了，压缩算法才能更好地找到重复模式。
好了，位域这东西，用好了是利器，用不好是坑。我的建议是：先理解你的平台和编译器行为，再决定用不用。如果你只是写单平台的应用，放心用；如果你做跨平台开发，记得做好序列化和反序列化的适配。