【优化】序列化库的选择(FlatBuffers,ProtoBuf,MessagePack,Json)

先贴结论：

如果是新项目:

选择Google FlatBuffers

它在GC Alloc & Time上均是最优的，毕竟是Google的技术产物。

http://google.github.io/flatbuffers/md__benchmarks.html

如果因为某些原因，要使用Json:

newtonsoft(Json.Net)是最优的。

LitJson
FastJson
Rapid Json
System.Net.Json
......
都要差一些。

（JsonUtility功能太少，不支持字典的序列化，一些简单的需求倒没问题。）

1.NewtonJson库的GC量以及耗时最低，最差是System.Net.Json。
2.其中GC量大的原因是：System.Text.Encoding.UTF8.GetString函数，以及Json库内部字符串处理，本身IO读取产生的GC量相对比较小。

二进制的优化策略：
1.常用小配置文件可以采用一次性将KEY和VALUE全部读取；
2.数据列不是很多但数据量中等的配置，可以采用只读取KEY，用到取VALUE再读取策略；
3.数据列很多并且数据量很大的配置，可以采用全部异步，预加载的方式优化；
4.采用预加载的方式，可以将配置文件IO部分和解析部分执行分开，先IO异步预加载完，再执行解析，尽量将内存峰值降低，防止因为配置文件导致堆内存过高。
--
这是直接引用文章里的一段，但这种优化方式的思想是通用的：
文件小：KEY和VALUE一次性读取
文件中等：可以先只读KEY，用到VALUE时再读
文件很大：可以采用异步（预加载）+分段，异步可以避免阻塞主线程，分段可以避免内存峰值瞬间过高，造成卡顿严重或是内存溢出。

===========下面是详细的废话==============

最近开了新的项目，因为要重新搭建一套框架，所以在涉及到大量配置表需要解析的时候，就要考虑选择哪一种序列化库了，其实有大量的项目，现在还是在使用json库来来做为数据交换的格式，足够的稳定，成熟，明文，方便阅读。

在我接手的上一个项目里，也是使用的json来做为序列化库，当时对newtonsoft Json狠狠的吐槽了一把，它的性能有多么多么的差，尤其是在一些低端机上，GC Alloc和调用耗时都很大，当然， 这也与当时加载的云控的数据量有关。

加载一万多个字节的数据（如果没有记错的话），但之前去参加UWA大会的时候，听到关于序列化库的分享，在json里,newtonsoft算是综合性能最好的一个......

今天就把UWA的视频给挖出来，将精华部分的内容分享出来，虽然我们最后可能还是会采用json

目前常用的库列化库有以下几种：

1.ProtoBuf-大明鼎鼎Google的技术产物，think XML, but smaller, faster, and simpler，二进制格式，效率是肯定高于json的

2.FlatBuffers-还是Google的技术产物，综合性能上肯定是要超越ProtoBuf的，不然没必要gmfrym出来这么一套，在整体的GC Alloc以及耗时上，都要优于ProtoBuf，简单看了一眼，说是不需要parsing/unpacking,这样文件的大小会不会相对更大一些？

这是目前序列化库里，最优解！

3.MessagePack-It's like JSON.but fast and small.(这好像ProtoBuf说过的:)

4.Json-hmmmmm.......

直接上传对比截图：




可以看到，FlatBuffers秒杀一众，MessagePack在移动端真的是蛮尴尬
的存在,但所UWA说，MessagePack在PC平台是比较有优势的。

扩展阅读：

https://code.fb.com/android/improving-facebook-s-performance-on-android-with-flatbuffers/

U Sparkle 客户端配置文件优化策略（具体JSON库性能的对比）
https://blog.uwa4d.com/archives/2045.html

感谢您的阅读， 如文中有误，欢迎指正，共同提高

作者：Ken
来源：GAD
地址：https://gameinstitute.qq.com/community/detail/132988