FlatBuffers（零拷贝序列化） ——一本不需要翻译就能直接阅读的外语书
引子：两种读书方式
想象你收到了一本日语原版小说。你不懂日语。
方式一：传统翻译（Protobuf / JSON 的做法） 1. 请一个翻译，把整本书从日语翻译成中文 2. 翻译过程中，需要一张白纸一张白纸地抄写 3. 翻译完成后，你拿到一本全新的中文书 4. 你开始阅读中文书 5. 原版日语书？扔了，不需要了 问题： ├── 翻译需要时间（反序列化耗时） ├── 需要额外的纸张（内存分配） ├── 翻译完才能开始读（必须完整解析） └── 如果你只想看第三章，也得把整本书翻译完 方式二：魔法眼镜（FlatBuffers 的做法） 1. 戴上一副魔法眼镜 2. 直接看日语原版书 3. 眼镜自动把你正在看的那个字翻译成中文 4. 你看哪里，哪里就变成中文 5. 不需要额外的纸张，不需要等待翻译 优势： ├── 零等待（零反序列化时间） ├── 零额外纸张（零内存分配） ├── 看哪翻哪（按需访问） └── 原版书就是你的书（零拷贝）FlatBuffers就是那副魔法眼镜。
它不把二进制数据"翻译"成对象，而是直接在二进制数据上读取。
数据在网络上是什么样，在内存里就是什么样。
不翻译。不拷贝。直接读。
第一章：先看看"传统翻译"有多痛
以Protobuf为例，反序列化一个怪物数据： 网络上收到的二进制数据（Protobuf编码）： [08 96 01 12 05 48 65 6C 6C 6F 1D 00 00 C8 42] 反序列化过程： ┌──────────────────────────────────────────────────┐ │ │ │ 步骤1：分配内存 │ │ Monster* monster = new Monster(); // 堆分配！ │ │ │ │ 步骤2：解析字段标签和类型 │ │ 读取 08 → 字段1，类型varint │ │ 读取 96 01 → 值=150 │ │ monster->hp = 150; // 拷贝！ │ │ │ │ 步骤3：解析字符串 │ │ 读取 12 → 字段2，类型length-delimited │ │ 读取 05 → 长度=5 │ │ 读取 48 65 6C 6C 6F → "Hello" │ │ monster->name = new string("Hello"); // 又分配！ │ │ │ │ 步骤4：解析浮点数 │ │ 读取 1D → 字段3，类型32bit │ │ 读取 00 00 C8 42 → 100.0f │ │ monster->speed = 100.0f; // 拷贝！ │ │ │ │ 总计： │ │ ├── 2次堆内存分配（Monster对象 + string） │ │ ├── 3次数据拷贝（hp, name, speed） │ │ ├── 多次条件判断（解析标签和类型） │ │ └── 如果Monster里有嵌套对象？更多分配和拷贝 │ │ │ └──────────────────────────────────────────────────┘ 这些开销在单次调用时微不足道。 但在游戏中： ├── 服务器每秒处理10万条消息 │ = 每秒20万次堆分配 │ = 每秒60万次数据拷贝 │ = GC压力山大（C#/Java/Go） │ ├── 客户端每帧处理50条消息 │ = 每帧100次堆分配 │ = 16.7ms的帧时间里，光反序列化就占了2-3ms │ └── 在Unity（C#）中尤其痛苦 每次new都会产生GC压力 GC触发时会造成帧率卡顿（GC Spike） 玩家感受：每隔几秒卡一下第二章：FlatBuffers的核心思想——不翻译，直接读
FlatBuffers的革命性思想： ┌──────────────────────────────────────────────────┐ │ │ │ 传统序列化： │ │ │ │ 发送端：对象 ──序列化──→ 字节流 ──网络──→ │ │ 接收端：字节流 ──反序列化──→ 新对象 │ │ │ │ 内存中有两份数据：字节流 + 对象 │ │ 反序列化 = 把字节流翻译成对象 │ │ │ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ │ │ │ FlatBuffers： │ │ │ │ 发送端：用Builder直接构建字节流 ──网络──→ │ │ 接收端：直接在字节流上读取，不创建新对象 │ │ │ │ 内存中只有一份数据：字节流 │ │ 没有反序列化！字节流本身就是"对象"！ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │ │ │ │ Protobuf： │ │ │ │ [网络缓冲区] ──拷贝+解析──→ [对象] │ │ │ │ 要两块内存 │ │ │ │ │ │ │ │ FlatBuffers： │ │ │ │ [网络缓冲区] ←──直接读取 │ │ │ │ 只要一块内存 │ │ │ │ │ │ │ └─────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────┘ 怎么做到的？ 秘密在于：FlatBuffers的二进制格式经过精心设计， 使得数据在缓冲区中的布局， 可以直接被当作结构化数据来访问。 不需要解析。不需要拷贝。 只需要知道"偏移量"——数据在缓冲区中的位置。 就像一本书有目录—— 你不需要从头读到尾， 翻到目录，找到页码，直接翻到那一页。第三章：FlatBuffers的二进制布局——拆开魔法眼镜
让我们用一个具体的例子来理解FlatBuffers的内存布局。 Schema定义（.fbs文件）： table Monster { hp: int = 100; name: string; speed: float = 1.0; pos: Vec3; inventory: [ubyte]; } table Vec3 { x: float; y: float; z: float; } 现在我们创建一个Monster： hp=150,, speed=2.5, pos=(1.0, 2.0, 3.0), inventory=[1,2,3] FlatBuffers在内存中的布局（从后往前构建）：┌──────────────────────────────────────────────────────────┐ │ │ │ 整个缓冲区的结构： │ │ │ │ 低地址 ──────────────────────────────────→ 高地址 │ │ │ │ ┌──────┬────────┬──────┬────────┬────────┬────────────┐ │ │ │root │vtable │table │string │vector │ 其他数据 │ │ │ │offset│ │ │"Orc" │[1,2,3] │ │ │ │ └──────┴────────┴──────┴────────┴────────┴────────────┘ │ │ ↑ │ │ 缓冲区起始位置 │ │ │ │ 让我们逐个拆解： │ │ │ │ ════════════════════════════════════════════════════════ │ │ │ │ 1. Root Offset（根偏移量）—— 4字节 │ │ │ │ ┌──────────┐ │ │ │ 20 │ ← "根table在缓冲区偏移20的位置" │ │ └──────────┘ │ │ │ │ 这是整个缓冲区的入口。 │ │ 读取这4字节，就知道Monster表在哪里。 │ │ │ │ ════════════════════════════════════════════════════════ │ │ │ │ 2. VTable（虚表）—— Monster的"目录" │ │ │ │ 这是FlatBuffers最精妙的设计。 │ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ vtable size │ table size │ hp偏移 │ name偏移 │ │ │ │ 2字节 │ 2字节 │ 2字节 │ 2字节 │ │ │ ├──────────────────────────────────────────────┤ │ │ │ speed偏移 │ pos偏移 │ inventory偏移 │ │ │ │ 2字节 │ 2字节 │ 2字节 │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ 具体值： │ │ ┌──────┬──────┬──────┬──────┬──────┬──────┬──────┐ │ │ │ 14 │ 24 │ 4 │ 8 │ 12 │ 16 │ 20 │ │ │ └──────┴──────┴──────┴──────┴──────┴──────┴──────┘ │ │ ↑ ↑ ↑ ↑ ↑ ↑ ↑ │ │ vtable table hp在 name在 speed在 pos在 inventory在│ │ 大小14 大小24 table table table table table │ │ 字节 字节 偏移4 偏移8 偏移12 偏移16 偏移20 │ │ │ │ VTable就像一本书的目录： │ │ "hp在第4页，name在第8页，speed在第12页..." │ │ │ │ 关键特性： │ │ ├── 如果某个字段没有设置（使用默认值）， │ │ │ 对应的偏移量为0 │ │ │ 读取时发现偏移为0 → 返回默认值 │ │ │ 不占用table中的空间！ │ │ ├── 相同结构的多个对象可以共享同一个VTable │ │ │ 100个相同类型的Monster只需要1个VTable │ │ └── 新版本增加字段 → VTable变长 │ │ 旧版本的VTable较短 → 新字段偏移不存在 → 返回默认值 │ │ 完美的前向/后向兼容！ │ │ │ │ ════════════════════════════════════════════════════════ │ │ │ │ 3. Table（表数据）—— Monster的实际数据 │ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ vtable偏移 │ hp值 │ name偏移│speed值│pos偏移│inv偏移│ │ │ │ 4字节 │ 4字节 │ 4字节 │4字节 │4字节 │4字节 │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ 具体值： │ │ ┌──────┬──────┬──────┬──────┬──────┬──────┐ │ │ │ -20 │ 150 │ 16 │ 2.5 │ 28 │ 40 │ │ │ └──────┴──────┴──────┴──────┴──────┴──────┘ │ │ ↑ ↑ ↑ ↑ ↑ ↑ │ │ vtable hp=150 name在 speed pos在 inventory在 │ │ 在前面 当前 =2.5 当前 当前 │ │ 20字节 位置+ 位置+ 位置+ │ │ 处 16字节 28字节 40字节