移动端通信协议选择：json、flatbuf、protobuf、MessagePack

• JSON:

 1、JSON是纯文本。
 2、JSON具有良好的自我描述性，便于阅读。

优点

1 简单易用开发成本低
2 跨语言
3 轻量级数据交换
4 非冗长性（对比xml标签简单括号闭环）

缺点

1 体积大，影响高并发
2 无版本检查，自己做兼容
3 片段的创建和验证过程比一般的XML复杂
4 缺乏命名空间导致信息混合

总结：最简单最通用的应用协议，使用广泛，开发效率高，性能相对较低，维护成本较高。

如果对性能要求不高，传输数据少，优先选择这个，现在大部分使用的是这个；

• protobuf:

  Protobuf是一种以有效并可扩展的格式编码结构化数据的方式。

• 语言无关、平台无关。即 ProtoBuf 支持 Java、C++、Python 等多种语言，支持多个平台
• 高效。即比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更为简单
• 扩展性、兼容性好。你可以更新数据结构，而不影响和破坏原有的旧程序

 比较强大，如果是大数据，建议使用 protobuf 性比较好，并支持数据流；

缺点：不便于阅读，库相对较大，移动端可以使用 protobuf-lite;

 

1 二进制格式，可读性差（抓包dump后的数据很难看懂）
2 对象冗余，字段很多，生成的类较大，占用空间。
3 默认不具备动态特性（可以通过动态定义生成消息类型或者动态编译支持）

总结：简单快速上手，高效兼容性强，维护成本较高；不便于阅读，库相对较大，移动端可以使用 protobuf-lite;

• flatbuf

FlatBuffers是Google专门为游戏开发而创建的跨平台序列化库

1. 对序列化数据的访问不需要打包和拆包——它将序列化数据存储在缓存中，这些数据既可以存储在文件中，又可以通过网络原样传输，而没有任何解析开销；
2. 内存效率和速度——访问数据时的唯一内存需求就是缓冲区，不需要额外的内存分配；
3. 扩展性、灵活性——它支持的可选字段意味着不仅能获得很好的前向/后向兼容性（对于长生命周期的游戏来说尤其重要，因为不需要每个新版本都更新所有数据）；
4. 最小代码依赖——仅仅需要自动生成的少量代码和一个单一的头文件依赖，很容易集成到现有系统中。
5. 强类型设计——尽可能使错误出现在编译期，而不是等到运行期才手动检查和修正；
6. 使用简单——生成的C++代码提供了简单的访问和构造接口；而且如果需要，通过一个可选功能可以用来在运行时高效解析Schema和类JSON格式的文本；
7. 跨平台——支持C++11、Java，而不需要任何依赖库；在最新的gcc、clang、vs2010等编译器上工作良好。

编码性能对比 (S)

Person个数	Protobuf	JSON	FlatBuffers
10	6.000	8.952	12.464
50	26.847	45.782	56.752
100	50.602	73.688	108.426

编码性能Protobuf相对于JSON有较大幅度的提高，而FlatBuffers则有较大幅度的降低。

解码性能对比 (S)

Person个数	Protobuf	JSON	FlatBuffers
10	0.255	10.766	0.014
50	0.245	51.134	0.014
100	0.323	101.070	0.006

解码性能方面，Protobuf相对于JSON，有着惊人的提升。Protobuf的解码时间几乎不随着数据长度的增长而有太大的增长，而JSON则随着数据长度的增加，解码所需要的时间也越来越长。而FlatBuffers则由于无需解码，在性能方面相对于前两者更有着非常大的提升。

 移动端，可以使用flatbuffers,相对protobuffer  要好一些。

• MessagePack

It's like JSON.but fast and small.

msgpack不是软件，是一个标准，可以先把它看成二进制的json，“二进制json”容易让人联想到一个更流行一点的标准：BSON。如果你不知道bson是啥可以去查一下，总之msgpack和bson是同类型的竞争产品，但是msgpack无论从速度还是体积上都秒杀bson，至少在网络传输上是这样的。

MessagePack 在移动端表现并不是太好，可能优势在PC。