3、SOME/IP序列化与反序列化：PDU格式、TLV编码、序列化规则、对齐与填充
好，咱们进入第三讲。序列化与反序列化，说白了就是解决一个问题：数据在内存里怎么摆，在线上怎么传，到了对端怎么还原。我刚开始接触SOME/IP时，觉得这玩意儿不就是把结构体塞进字节流吗？后来踩了几个坑才发现，里面的门道真不少。
3.1 PDU格式：协议数据单元长什么样？
先看PDU（Protocol Data Unit）。SOME/IP的PDU结构其实挺清晰的，我习惯把它分成三块：头部、Payload、可选的尾部。头部固定16字节，Payload长度可变。
头部结构我直接列出来：
| 字段 | 长度（字节） | 说明 |
|---|---|---|
| Message ID | 4 | 服务ID + 方法/事件ID |
| Length | 4 | 从Request ID之后到报文结束的长度 |
| Request ID | 4 | 客户端ID + 会话ID |
| Protocol Version | 1 | 当前是1 |
| Interface Version | 1 | 服务接口版本号 |
| Message Type | 1 | REQUEST=0x00, RESPONSE=0x80等 |
| Return Code | 1 | E_OK=0x00, E_NOT_OK=0x01等 |
这里有个细节——Length字段的计算方式。它不包含Message ID和Length自身那8个字节，只算从Request ID开始到末尾的长度。我在项目中见过有人把整个报文长度填进去，结果对端解析直接崩了。嗯，这个坑我替你们踩过了。
3.2 TLV编码：灵活但别滥用
TLV（Type-Length-Value）是SOME/IP序列化里的一种可选方式。说白了就是给每个数据字段加个标签：
- Type：1字节，标识数据类型
- Length：1字节，标识Value的长度
- Value：实际数据
举个例子，一个uint32的数值42，TLV编码后就是：
Type = 0x01 (假设uint32的Type码)
Length = 0x04
Value = 0x0000002A
我个人习惯在动态长度数组或可选字段的场景下用TLV。比如座舱里的座椅位置信息，有些车型有腰部支撑，有些没有，用TLV就能优雅地处理这种差异。
3.3 序列化规则：字节序与数据布局
SOME/IP序列化遵循几条硬规则：
- 网络字节序（大端）：所有多字节数据都用大端。我见过有人把x86的小端数据直接塞进去，结果对端读出来全是反的。
- 基本类型直接映射：uint8、int8、boolean这些单字节的，直接放。uint16、uint32、float32这些，按大端排好放。
- 字符串用UTF-8编码：长度前置，后面跟字符串内容。注意，长度是字节数，不是字符数。
- 数组和结构体递归序列化：先序列化长度（如果有），再逐个序列化元素。
看个实际例子，序列化一个结构体：
struct SeatPosition {
uint8 seat_id; // 1字节
uint32 position_x; // 4字节
uint32 position_y; // 4字节
uint8 lumbar_support; // 1字节，可选
};
序列化后的字节流（假设seat_id=1, position_x=100, position_y=200, lumbar_support=0）：
01 // seat_id
00 00 00 64 // position_x = 100
00 00 00 C8 // position_y = 200
00 // lumbar_support = 0
看着挺简单对吧？但这里有个陷阱——对齐。咱们接着聊。
3.4 对齐与填充：性能与空间的博弈
为什么要对齐？因为CPU读数据时，如果地址是4的倍数，效率最高。SOME/IP序列化里，每个基本类型都按自身长度对齐。比如uint32要4字节对齐，uint16要2字节对齐。
还是上面那个结构体，如果严格按SOME/IP对齐规则，实际序列化会变成这样：
01 // seat_id，地址0
FF FF FF // 填充3字节，让position_x对齐到4字节边界
00 00 00 64 // position_x，地址4
00 00 00 C8 // position_y，地址8
00 // lumbar_support，地址12
FF FF FF // 填充3字节？不一定，看下一个字段
这里有个关键点：填充只发生在字段之间，不强制在末尾填充。除非你明确知道后面还有数据需要对齐。
3.5 避坑指南：我踩过的几个坑
讲几个真实案例：
- 坑一：结构体嵌套时的对齐。我曾经在一个项目中，结构体A包含结构体B，B内部有uint32字段。我忘了B的起始地址也要按4字节对齐，结果A里B前面的字段长度不是4的倍数，导致B内部所有字段都错位了。排查了整整一下午。
- 坑二：TLV和固定格式混用时的长度计算。TLV的Length字段只包含Value的长度，不包含Type和Length自身。有人把整个TLV三元组的长度填进去了，对端解析时多读了2字节。
- 坑三：字符串的null终止符。SOME/IP序列化字符串时，不包含null终止符。长度字段就是字符串的实际字节数。如果你在C语言里用strlen，记得别把结尾的'\0'算进去。
3.6 序列化性能优化建议
最后给几个实战建议：
- 预计算缓冲区大小：不要每次序列化都动态分配内存。我习惯在初始化时算好最大报文长度，一次性分配好。
- 批量序列化：如果有一组传感器数据要发，尽量打包成一个PDU，而不是每个传感器发一个。减少头部开销。
- 避免频繁的字节序转换：如果发送端和接收端都是大端CPU（比如某些PowerPC），可以跳过字节序转换。但为了通用性，我建议还是按规范来。
- 使用内存拷贝代替逐字节赋值：对于大块数据，用memcpy比for循环快一个数量级。
好了，这一讲就到这里。序列化看似基础，但它是SOME/IP通信的基石。下一讲咱们聊聊服务发现，那才是真正体现SOME/IP灵活性的地方。