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

序列化库的选择(FlatBuffers,ProtoBuf,MessagePack,Json)"/>

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

如果是新项目:
选择Google FlatBuffers
它在GC Alloc & Time上均是最优的，毕竟是Google的技术产物。
.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平台是比较有优势的。

扩展阅读：
/
U Sparkle 客户端配置文件优化策略（具体JSON库性能的对比）
.html