编者点评

即时通讯应用（包括IM聊天应用、实时消息推送应用等）开发的前期技术选型时，关于数据传输格式的选择，在即时通讯开发者同行的眼里，是个极富争议话题。

精略分析一下，大概的原因在于：

• 可选择的协议或封装格式多种多样：
  可选择的余地很大：XMPP、Protobuf、JSON、私有2进制、MQTT、定格化XML、Plain text等等；
• 同一种格式并不能适用于大多数的场景：
  不同的场景有同的考虑而协议的选择往 跟这是挂钩在一起的，比如：移动端IM或推送技术用XMPP这样的协议时，多数情况下都会被喷；
• 开发者对所选格式有各自的偏好：
  有的人或团队对某种或某几种格式有不一样的经验和技术积累，也促成了他们对某种或某几种协议的偏好。
  

其实总结以上原因就可以知道，之所以对于即时通讯应用的数据传输格式有不同的声音，根本原因还在于应具体事情具体分析，该选什么协议由场景决定、由团队的技术积累决定、甚至由项目的周期和成本决定，这里不存在唯一解，只有最适合的数据传输格式，不存在最好的格式一说。

当然，本文内容中对即时通讯传输格式的选择，是原作者的一家之言，可能存在很大争议，但如能为你的即时通讯应用开发的技术选型带来些许启发，我相信这才符合作者的本意。

数据格式的选择需要考虑的方面

1网络数据大小：占用带宽，传输效率

虽然对单个用户来说，数据量传输很小，但是对于服务器端要承受众多的高并发数据传输（尤其现时高并发、大用户量的IM聊天应用和实时推送服务端等场景），必须要考虑到数据占用带宽，尽量不要有冗余数据，这样才能够少占用带宽，少占用资源，少网络IO，提高传输效率。

2网络数据安全性：敏感数据的网络安全

对于相关业务的部分数据传输都是敏感数据，所以必须考虑对部分传输数据进行加密。这通常出现在银行等数据安全性要求很高的应用行业和场景里，当然传统的即时通讯应用里基于用户隐私考虑，数据加密也是同样是个必须考虑的问题。安全性是应用的基础条件，需求是一样的，只是加密程度、安全性级别要求有不同而已。

3编码复杂度

编码复杂度包括序列化和反序列化复杂度、效率、数据结构的可扩展性和可维护性。

对于平台相关业务的代码实现也需要考虑到数据发送方和数据接收方数据处理的复杂度和数据结构的可扩展性，可维护性，人力成本和实施复杂度也必须考虑在内。通常情况下，即时通讯应用（比如IM聊天应用）在开发的前期，为了方便调试，很多团队会用简单的文本协议、JSON等能直观查看的方式，但后期生产部署后，为了流量等考虑，可能会转用Protobuf等更省流量的协议。但总之，协议的定义不可能永远一成不变，但如果在实现的时候就有这些预见性，相性会大大减轻未来的运营风险。

4协议通用性、大众规范

数据类型必须是跨平台，数据格式是通用的，大家普遍能接受上手的。当然，现在已经迈入移动互联网时代，多端、多平台、异构平台的数据通讯是先决条件，而协议的选择，通用性也最多只是应用层有区别。当然，无论如何，异构平台的一致性，是毫无争议的必备条件。

不同类别的数据传输协议（格式）的比较

1自定义二进制

优点：信息体积小，对应以上”1“              
缺点：编码复杂度高（自己定义消息格式，自己编写序列化和反序列化方法，自己进行容错处理，可扩展性不强，比如添加个字段，就必须改两端的逻辑处理），对应以上”3“；

2提供序列化和反序列化库的开源协议

比如 谷歌的protocol buffers， json，  Thrift
优点：是一种流行的通用数据格式，扩展相当方便，序列化和反序列化相当方便（有相应库），错误处理方便（库支持）。

3文本化协议

比如xml，json
优点：序列化，反序列化容易（库支持），调试方便，可视化强；
缺点：相对于二进制存储占用体积大。

结语

文字看完了，原文作者选择JSON作为即时通讯应用的数据传输格式（协议），到底该怎么选，相信你也已经找到答案了。（