FlatBuffers vs protobuf

FlatBuffers 更多用在游戏上
数据大小 protobuf 优
序列化 protobuf优
反序列化 faltbuffer优

https://juzii.gitee.io/2020/03/02/protobuf-vs-flatbuffer/

总结
FlatBuffers序列化后不需要转换/解包的操作就可以获得原数据，反序列化消耗的时间极短，短到远小于1ms而可以忽略；基本没有对数据进行压缩，因为有偏移量的关系，数据量比原数据有所增加；生成的代码量较少，运行比较轻量，CPU占用较低，内存占用较少。
Protobuf采用”Base 128 Varints”算法对整型数据进行压缩，压缩比例最高能达到50%；序列化与反序列化都比较重度，生成的代码量较大，CPU占用较高，内存占用较多。
Protobuf 3.x中移除了required和optional字段描述，相当于除repeated以外的所有字段都是optional，提高了Protobuf的消息兼容性。
Protobuf使用技巧：
为了使数据压缩率更高，每个消息的字段数量最好不要超过15个。
尽量不要使用int32与int64，如果是正数使用uint，如果是负数则使用sint。
如果业务中能够控制int32或int64型数据的取值范围，尽量控制在0-127。
通过以上技巧都能够提高Protobuf的数据压缩能力。
Flatbuffers使用技巧：
uint类型只是为了扩大int的取值范围（兼容c/c++与c#等有unsigned int类型的语言），而如果是java等没有unsigned int等类型的语言，会在赋值与取值时扩展为long来处理，所以若非有实际需要，尽量不要使用uint。
如果业务中能够控制bool、int8、int16、int32、int64的取值是0与非0的概率，尽量让取值为0的情况多一些，可以使Flatbuffers具备一定的压缩能力。
若项目需求对数据处理延时有严苛的要求（例如FPS、Moba、动作RPG等），可以考虑使用Flatbuffers，并配合UDP/KCP等传输层协议，能够比传统的TCP+Protobuf方案有更好的降低延时的效果。