FlatBuffers vs Protocol Buffers

FlatBuffers去年发布，最近看了1下，与同是出自Google之手的Protocol Buffers非常类似。在官网上介绍，FlatBuffers（简称FB）主要针对game development和对性能有要求的利用。相对Protocol Buffers（简称PB），FB不需要解析，只通过序列化后的2进制buffer便可完成数据访问。

FB的主要特点有：

1）数据访问不需要解析

将数据序列化成2进制buffer，以后的数据访问直接读取这个buffer，所以读取的效力很高。

2）内存高效、速度快

- 数据访问只在序列化后的2进制buffer，不需额外的内存分配。

- 数据访问速度接近原生的struct，只多了1次解援用（根据起始地址和偏移量，然后取值）

3）弹性

都是可选字段，支持向前、向后兼容

4）生成的代码量小

只需依赖1个头文件

5）强类型

编译时检测毛病

6）易于使用

可以解析schema和json文本

7）跨平台

C++/Java/Go不需额外依赖

FB的实现原理：

通过FB序列化后的数据就是1个2进制buffer，内部包括各种objects（structs，tables，vectors），通过offset组织。所以数据可以in-place访问（起始地址+偏移量），就像数组或struct访问。

FB中table代表1个数据结构，这个table会对应1个vtable，用于唆使各个字段在buffer中的偏移量。接下来，在访问某个字段时，直接根据偏移量就能够找到该字段。 由于FB直接访问raw buffer，所以在数据破坏时，会得到脏数据。FB通过Verifier确保不可信buffer数据是正确的。

下面测试了PB和FB，做性能对照，测试场景很简单，构造N个对象，序列化，写入文件，然后再反序列化。测试的对象结构以下：

X  /  Y  /  Z3个数据，分别对应，序列化总时间  /  文件大小  /  反序列时间，其中包括读写文件的时间。可以看到，PB在序列化的时间和大小都要优于FB，序列化要快30%左右，序列化数据大小要小20%左右。而FB由于不需要解析，反序列化异常快。

虽然FB的反序列化超级快，但是数据大小还是蛮大的（可能的缘由是不需要解析，直接访问binary buffer，所以不能对数据进行紧缩），带来的传输或存储开消，可能会抵过1部份反序列化的时间。感觉上，FB的使用处景上还是很受限，在移动端多是1个利用场景。

测试代码为了简单，对每一个对象都会调用write或read，统计的时间也包括这些时间。由于要对PB和FB对照，此部份开消基本1致。具体代码见github