云风的 BLOG

在这个具体问题上，我认为还是应该先简化数据结构，让核心数据结构变得易管理。显然、固定大小的数据结构是最容易被管理的。因为如果你的数据结构大小固定，就不再需要堆管理，而是一个固定数组滚动处理临时数据。

json 这样的弹性数据结构看起来不太好用固定大小的数据结构去描述，但稍微想点办法也不难做到。C 在这方面的库不少，我就不一一列举。核心想法一般是：用一个固定数据结构去引用编码数据中的切片。解码后的结构只保留元素的类型以及在原始数据中的位置。如果你能大致知道需要解码的数据元素的数量级，那么就可以用一个固定大小的结构去承载解码结果，不需要任何动态的内存分配。

只不过大多数库把目标都放在时间因素上，让解码更快；少放在空间因素上，让解码过程少使用内存；所以这样的解码方式并不常用。如果你的核心问题于此，你就得去考虑这样的方案。

protobufffer 会比 json 的结构更适合这样做。因为它已经把数据的 key 部分转换成数组 id ，且整体数据结构是明确的。但只是因为 protobuffer 编码更繁杂，不如json 那么简单，反而相关的库更少。

第二、如果你真的有这样的需求：要解码成千上万的数据结构类似的数据包。就应该考虑下列模式：

假设你要解码的数据块的类型是 X ，可以预先生成一个叫做 X 的 accessor 访问器。当你的业务逻辑需要访问 X.a.b 这个字段的时候，应该去调用 X.a.b(binary) ，此处的 binary 指编码过的 json/protobuffer 数据块，X.a.b() 是一个预生成好的访问器函数，它可以用最优化的方法从数据块中提取出需要的数据。

我们还可以进一步的为 X 做一个索引函数，可以预处理 binary ，制作一个固定内存大小的索引信息结构，为具体字段的访问加速。

这个 accessor 对象不太在乎多复杂，因为它可能在整个程序中只初始化一次。