你写typedef struct { uint8_t id; uint32_t data; uint16_t crc; } Packet;的时候大概率觉得这是 7 个字节。毕竟 142 嘛。sizeof(Packet)打印出来是 12。多出来的 5 个字节是编译器偷偷塞进去的。它没告诉你也没问你同不同意。这 5 个字节是嵌入式工程师和内存打交道的第一课。这一课的终点不是省几个字节是怎么用 struct 把整个系统的架构撑起来。我从业十几年接手过的祖传项目里struct 用得好的代码越改越顺struct 用得乱的改一个字段崩三处。这篇文章我想顺着内存的第一个字节这条线从 padding 一路讲到面向对象把中间那些踩过的坑都摆出来。sizeof 凭什么不是 7对齐和填充先把这个 12 字节的谜题拆开。typedef struct { uint8_t id; // 1 字节 uint32_t data; // 4 字节 uint16_t crc; // 2 字节 } Packet; // sizeof 12不是 7内存里它长这样编译器在id后面塞了 3 个字节填充在crc后面又塞了 2 个。为什么两条规则每个成员的起始地址必须是它自身大小的整数倍。data是 4 字节所以它的偏移必须是 4 的倍数。id只占了偏移 0data没法放在偏移 1得跳到偏移 4中间 1-3 就成了 padding。整个结构体的大小必须是最大成员大小的整数倍。这里最大成员 4 字节所以总大小得凑成 4 的倍数12 正好。这两条规则不是编译器闲得慌。CPU 访问内存很多架构上一次抓一个对齐的字32 位机一次 4 字节。如果data跨在偏移 3-6CPU 得抓两次再拼慢一倍在 Cortex-M0 这类不支持非对齐访问的核上直接抛异常。所以对齐是用空间换时间、换稳定性。但嵌入式工程师对空间敏感RAM 就那么大5 个字节乘上几千个包就是几十 KB 的浪费。省内存的笨办法把成员从大到小排最省事的优化是按成员大小从大到小排列。// 浪费sizeof 12 typedef struct { uint8_t id; uint32_t data; uint16_t crc; } Packet_Bad; // 紧凑sizeof 8 typedef struct { uint32_t data; // 偏移 0 uint16_t crc; // 偏移 4 uint8_t id; // 偏移 6尾部填充 1 字节 } Packet_Good;把data提到最前面它天然对齐在偏移 0crc跟在偏移 4也是 2 的倍数id在偏移 6。最后凑成 8 字节只浪费 1 个字节。省了三分之一。这个写法不需要任何编译器扩展可移植性最好是我推荐的首选。代价是字段顺序和逻辑顺序不一致。你定义协议时可能习惯先写帧头再写数据但为了省内存得反过来。这个代价我觉得值但要在注释里写清楚为什么这么排不然下一个接手的人会好心帮你调回去。当协议不能动__packed强制取消对齐有些场景你没法重排。比如通信协议帧格式是定死的对端按字节流解析你这边 struct 必须和线上格式一字节对一字节。这时候用__packedtypedef struct __attribute__((packed)) { uint8_t type; uint32_t seq; uint16_t length; } FrameHeader; // sizeof 7没有填充packed告诉编译器别塞 padding严格按定义的顺序紧凑排列。sizeof 变成 7和协议一致。但 packed 不是免费的午餐。取消对齐后CPU 访问seq这个 4 字节成员时它可能跨在偏移 1-4CPU 得拆成多次访问再拼性能下降。更狠的是在 Cortex-M0、M0 这些不支持非对齐访问的核上访问 packed 结构体的多字节成员会直接触发 HardFault。我见过一个真实事故同事在 M0 上用 packed struct 接收串口数据本地测试好好的上了产线偶发死机查了三天才发现是 packed 的非对齐访问在某些数据组合下触发了异常。所以 packed 要用但只用在你确定会跨字节边界、且确定平台能扛的场景比如协议帧头这种本来就是字节流的。在能重排的内部数据结构上老老实实从大到小排别图省事用 packed。位域用 struct 摁住每一个 bit寄存器是按 bit 算的。一个 GPIO 控制寄存器 32 位bit0 是使能、bit1 是方向、bit2 是中断使能、bit4-7 是模式。传统写法是位操作#define REG (*(volatile uint32_t *)0x40020000) REG | (1 0); // 使能 REG ~(1 1); // 清方向 REG (REG ~(0xF 4)) | (mode 4); // 设模式能跑但读起来像天书改起来容易漏一个取反。位域让 struct 直接操作 bittypedef struct { uint32_t enable : 1; // Bit 0 uint32_t dir : 1; // Bit 1 uint32_t irq_en : 1; // Bit 2 uint32_t mode : 4; // Bit 4-7 uint32_t padding : 24; // Bit 8-31 } GPIO_CtrlReg; volatile GPIO_CtrlReg *ctrl (GPIO_CtrlReg *)0x40020000; ctrl-enable 1; // 使能外设 ctrl-mode 5; // 设置模式可读性高了一个档次。但位域有个坑位域的内存排列顺序是编译器相关的。先放高位还是低位、是否跨存储单元C 标准没规定GCC 和 Keil 可能不一样。所以位域只适合在同一编译器、同一平台下用。一旦你的代码要跨编译器移植或者要和硬件寄存器的 bit 位置严格对应位域就靠不住了。这时候老老实实回位操作丑但确定。我的习惯寄存器映射用位域同平台内可读性优先跨平台协议解析绝不用位域。零拷贝struct 指针直接怼到缓冲区上到这里 struct 还只是装数据的容器。真正让它变成架构工具的是零拷贝这一步。接收一帧数据传统做法是逐字段拷贝解析void on_data_received(uint8_t *buf, uint16_t len) { uint8_t head buf[0]; uint8_t cmd buf[1]; uint16_t length buf[2] | (buf[3] 8); uint8_t *payload buf[4]; // ... 逐字段拷贝到本地变量 }每来一帧都拷一遍慢还容易写错偏移。用 struct 指针直接映射typedef struct __attribute__((packed)) { uint8_t head; // 帧头 0xAA uint8_t cmd; // 命令字 uint16_t length; // 数据长度 uint8_t payload[]; // 柔性数组变长数据 } Frame; void on_data_received(uint8_t *buf, uint16_t len) { Frame *frame (Frame *)buf; // 零拷贝直接映射 if (frame-head ! 0xAA) return; process_payload(frame-payload, frame-length); }把缓冲区指针直接 cast 成 struct 指针成员访问就是按偏移读内存一次拷贝都没有。变长数据用柔性数组payload[]挂在末尾长度由length字段决定。这个写法快但有两个前提必须满足。第一struct 必须 packed否则 padding 会让偏移和线上字节对不上。第二字节序要对得上length是大端还是小端得和发送方一致跨端设备用ntohs/htons转一下。还有个容易忘的别用零拷贝的 struct 指针去修改 buf。如果 buf 是 DMA 接收缓冲区改了可能和下一次接收撞车。零拷贝是 struct 从数据容器走向协议抽象的第一步。到这一步struct 不再被动装东西它开始主动定义数据长什么样的契约。struct 函数指针C 语言的面向对象最后一步也是架构设计的落点。当 struct 既能定义数据布局又能挂上操作这些数据的函数它就变成了一个对象。typedef struct { const char *name; int (*init)(void); int (*read)(uint32_t addr, uint8_t *buf, uint32_t len); int (*write)(uint32_t addr, const uint8_t *buf, uint32_t len); int (*erase)(uint32_t addr, uint32_t len); } StorageDevice; const StorageDevice spi_flash { .name W25Q128, .init spi_flash_init, .read spi_flash_read, .write spi_flash_write, .erase spi_flash_erase, }; void save_config(const StorageDevice *dev, Config *cfg) { dev-erase(CFG_ADDR, sizeof(Config)); dev-write(CFG_ADDR, (uint8_t *)cfg, sizeof(Config)); }save_config不关心底层是 SPI Flash 还是 SD 卡。它只认StorageDevice这个接口有 init、有 read、有 write、有 erase。换存储介质只需要换一个实例把函数指针指向新的实现上层代码一个字都不用改。这就是 C 语言的面向对象也是 Linux 驱动模型、RT-Thread 设备框架、HAL 层的核心套路。到这一步 struct 已经不只是内存布局了它成了一份接口契约数据怎么放、能做什么操作都封装在一起。上层依赖抽象不依赖具体实现。回过头看这条线padding 让你理解内存为什么有空洞从大到小排列让你主动去填那些空洞packed 让你在协议约束下妥协位域让你精细到每一个 bit零拷贝让 struct 开始定义数据的契约。最后函数指针这一步struct 连行为也一起封装了。每一步都是在用 struct 这一个工具把内存里的字节一步步抽象成系统里的架构。架构设计的本质我越来越觉得不是画那些花哨的分层图是把这种用数据结构封装变化的能力练成本能。一个 struct 定义得好硬件变了只换实例协议变了只改布局平台变了只调对齐。变化被关在 struct 里面外面风平浪静。这也是为什么我接手项目第一件事是 grep 所有的 struct 定义而不是先翻 main 函数。struct 长什么样这个项目的骨架就长什么样。写到这里你下次定义 struct 的时候大概会多想一秒这个字段顺序省内存吗这个结构体要不要 packed它能不能挂上函数指针变成接口多想这一秒你就从写功能往设计系统挪了一步。嵌入式这一行真正卡住人的不是语法是把底层细节一步步抽象成架构的能力。struct 是个特别好的练手场小到一个上午就能摸透深的地方能一路通到整个系统的设计。有用的话点个赞收藏让更多工程师看到。你项目里有没有那种改一个字段崩三处的祖传 struct评论区聊聊我猜不止我一个人遇到过。
C 语言 struct 内存对齐与面向对象：从 padding 到函数指针接口
你写typedef struct { uint8_t id; uint32_t data; uint16_t crc; } Packet;的时候大概率觉得这是 7 个字节。毕竟 142 嘛。sizeof(Packet)打印出来是 12。多出来的 5 个字节是编译器偷偷塞进去的。它没告诉你也没问你同不同意。这 5 个字节是嵌入式工程师和内存打交道的第一课。这一课的终点不是省几个字节是怎么用 struct 把整个系统的架构撑起来。我从业十几年接手过的祖传项目里struct 用得好的代码越改越顺struct 用得乱的改一个字段崩三处。这篇文章我想顺着内存的第一个字节这条线从 padding 一路讲到面向对象把中间那些踩过的坑都摆出来。sizeof 凭什么不是 7对齐和填充先把这个 12 字节的谜题拆开。typedef struct { uint8_t id; // 1 字节 uint32_t data; // 4 字节 uint16_t crc; // 2 字节 } Packet; // sizeof 12不是 7内存里它长这样编译器在id后面塞了 3 个字节填充在crc后面又塞了 2 个。为什么两条规则每个成员的起始地址必须是它自身大小的整数倍。data是 4 字节所以它的偏移必须是 4 的倍数。id只占了偏移 0data没法放在偏移 1得跳到偏移 4中间 1-3 就成了 padding。整个结构体的大小必须是最大成员大小的整数倍。这里最大成员 4 字节所以总大小得凑成 4 的倍数12 正好。这两条规则不是编译器闲得慌。CPU 访问内存很多架构上一次抓一个对齐的字32 位机一次 4 字节。如果data跨在偏移 3-6CPU 得抓两次再拼慢一倍在 Cortex-M0 这类不支持非对齐访问的核上直接抛异常。所以对齐是用空间换时间、换稳定性。但嵌入式工程师对空间敏感RAM 就那么大5 个字节乘上几千个包就是几十 KB 的浪费。省内存的笨办法把成员从大到小排最省事的优化是按成员大小从大到小排列。// 浪费sizeof 12 typedef struct { uint8_t id; uint32_t data; uint16_t crc; } Packet_Bad; // 紧凑sizeof 8 typedef struct { uint32_t data; // 偏移 0 uint16_t crc; // 偏移 4 uint8_t id; // 偏移 6尾部填充 1 字节 } Packet_Good;把data提到最前面它天然对齐在偏移 0crc跟在偏移 4也是 2 的倍数id在偏移 6。最后凑成 8 字节只浪费 1 个字节。省了三分之一。这个写法不需要任何编译器扩展可移植性最好是我推荐的首选。代价是字段顺序和逻辑顺序不一致。你定义协议时可能习惯先写帧头再写数据但为了省内存得反过来。这个代价我觉得值但要在注释里写清楚为什么这么排不然下一个接手的人会好心帮你调回去。当协议不能动__packed强制取消对齐有些场景你没法重排。比如通信协议帧格式是定死的对端按字节流解析你这边 struct 必须和线上格式一字节对一字节。这时候用__packedtypedef struct __attribute__((packed)) { uint8_t type; uint32_t seq; uint16_t length; } FrameHeader; // sizeof 7没有填充packed告诉编译器别塞 padding严格按定义的顺序紧凑排列。sizeof 变成 7和协议一致。但 packed 不是免费的午餐。取消对齐后CPU 访问seq这个 4 字节成员时它可能跨在偏移 1-4CPU 得拆成多次访问再拼性能下降。更狠的是在 Cortex-M0、M0 这些不支持非对齐访问的核上访问 packed 结构体的多字节成员会直接触发 HardFault。我见过一个真实事故同事在 M0 上用 packed struct 接收串口数据本地测试好好的上了产线偶发死机查了三天才发现是 packed 的非对齐访问在某些数据组合下触发了异常。所以 packed 要用但只用在你确定会跨字节边界、且确定平台能扛的场景比如协议帧头这种本来就是字节流的。在能重排的内部数据结构上老老实实从大到小排别图省事用 packed。位域用 struct 摁住每一个 bit寄存器是按 bit 算的。一个 GPIO 控制寄存器 32 位bit0 是使能、bit1 是方向、bit2 是中断使能、bit4-7 是模式。传统写法是位操作#define REG (*(volatile uint32_t *)0x40020000) REG | (1 0); // 使能 REG ~(1 1); // 清方向 REG (REG ~(0xF 4)) | (mode 4); // 设模式能跑但读起来像天书改起来容易漏一个取反。位域让 struct 直接操作 bittypedef struct { uint32_t enable : 1; // Bit 0 uint32_t dir : 1; // Bit 1 uint32_t irq_en : 1; // Bit 2 uint32_t mode : 4; // Bit 4-7 uint32_t padding : 24; // Bit 8-31 } GPIO_CtrlReg; volatile GPIO_CtrlReg *ctrl (GPIO_CtrlReg *)0x40020000; ctrl-enable 1; // 使能外设 ctrl-mode 5; // 设置模式可读性高了一个档次。但位域有个坑位域的内存排列顺序是编译器相关的。先放高位还是低位、是否跨存储单元C 标准没规定GCC 和 Keil 可能不一样。所以位域只适合在同一编译器、同一平台下用。一旦你的代码要跨编译器移植或者要和硬件寄存器的 bit 位置严格对应位域就靠不住了。这时候老老实实回位操作丑但确定。我的习惯寄存器映射用位域同平台内可读性优先跨平台协议解析绝不用位域。零拷贝struct 指针直接怼到缓冲区上到这里 struct 还只是装数据的容器。真正让它变成架构工具的是零拷贝这一步。接收一帧数据传统做法是逐字段拷贝解析void on_data_received(uint8_t *buf, uint16_t len) { uint8_t head buf[0]; uint8_t cmd buf[1]; uint16_t length buf[2] | (buf[3] 8); uint8_t *payload buf[4]; // ... 逐字段拷贝到本地变量 }每来一帧都拷一遍慢还容易写错偏移。用 struct 指针直接映射typedef struct __attribute__((packed)) { uint8_t head; // 帧头 0xAA uint8_t cmd; // 命令字 uint16_t length; // 数据长度 uint8_t payload[]; // 柔性数组变长数据 } Frame; void on_data_received(uint8_t *buf, uint16_t len) { Frame *frame (Frame *)buf; // 零拷贝直接映射 if (frame-head ! 0xAA) return; process_payload(frame-payload, frame-length); }把缓冲区指针直接 cast 成 struct 指针成员访问就是按偏移读内存一次拷贝都没有。变长数据用柔性数组payload[]挂在末尾长度由length字段决定。这个写法快但有两个前提必须满足。第一struct 必须 packed否则 padding 会让偏移和线上字节对不上。第二字节序要对得上length是大端还是小端得和发送方一致跨端设备用ntohs/htons转一下。还有个容易忘的别用零拷贝的 struct 指针去修改 buf。如果 buf 是 DMA 接收缓冲区改了可能和下一次接收撞车。零拷贝是 struct 从数据容器走向协议抽象的第一步。到这一步struct 不再被动装东西它开始主动定义数据长什么样的契约。struct 函数指针C 语言的面向对象最后一步也是架构设计的落点。当 struct 既能定义数据布局又能挂上操作这些数据的函数它就变成了一个对象。typedef struct { const char *name; int (*init)(void); int (*read)(uint32_t addr, uint8_t *buf, uint32_t len); int (*write)(uint32_t addr, const uint8_t *buf, uint32_t len); int (*erase)(uint32_t addr, uint32_t len); } StorageDevice; const StorageDevice spi_flash { .name W25Q128, .init spi_flash_init, .read spi_flash_read, .write spi_flash_write, .erase spi_flash_erase, }; void save_config(const StorageDevice *dev, Config *cfg) { dev-erase(CFG_ADDR, sizeof(Config)); dev-write(CFG_ADDR, (uint8_t *)cfg, sizeof(Config)); }save_config不关心底层是 SPI Flash 还是 SD 卡。它只认StorageDevice这个接口有 init、有 read、有 write、有 erase。换存储介质只需要换一个实例把函数指针指向新的实现上层代码一个字都不用改。这就是 C 语言的面向对象也是 Linux 驱动模型、RT-Thread 设备框架、HAL 层的核心套路。到这一步 struct 已经不只是内存布局了它成了一份接口契约数据怎么放、能做什么操作都封装在一起。上层依赖抽象不依赖具体实现。回过头看这条线padding 让你理解内存为什么有空洞从大到小排列让你主动去填那些空洞packed 让你在协议约束下妥协位域让你精细到每一个 bit零拷贝让 struct 开始定义数据的契约。最后函数指针这一步struct 连行为也一起封装了。每一步都是在用 struct 这一个工具把内存里的字节一步步抽象成系统里的架构。架构设计的本质我越来越觉得不是画那些花哨的分层图是把这种用数据结构封装变化的能力练成本能。一个 struct 定义得好硬件变了只换实例协议变了只改布局平台变了只调对齐。变化被关在 struct 里面外面风平浪静。这也是为什么我接手项目第一件事是 grep 所有的 struct 定义而不是先翻 main 函数。struct 长什么样这个项目的骨架就长什么样。写到这里你下次定义 struct 的时候大概会多想一秒这个字段顺序省内存吗这个结构体要不要 packed它能不能挂上函数指针变成接口多想这一秒你就从写功能往设计系统挪了一步。嵌入式这一行真正卡住人的不是语法是把底层细节一步步抽象成架构的能力。struct 是个特别好的练手场小到一个上午就能摸透深的地方能一路通到整个系统的设计。有用的话点个赞收藏让更多工程师看到。你项目里有没有那种改一个字段崩三处的祖传 struct评论区聊聊我猜不止我一个人遇到过。
