即时通讯利用（包含 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
长处：是一种风行的通用数据格式，扩大相当不便，序列化和反序列化相当不便（有相应库），错误处理不便（库反对）。即时通讯聊天软件 app 开发能够征询蔚可云。
3 文本化协定
比方 xml，json
长处：序列化，反序列化容易（库反对），调试不便，可视化强；
毛病：绝对于二进制存储占用体积大。
你会抉择哪种协定？
我会抉择 JSON（PS: 文中的“我”指原作者），因为他是“提供序列化和反序列化库的开源协定还是文本化的协定”，起因如下：
自定义二进制格局的复杂性：
自定义二进制格局进行传输的工作，整个过程在定义音讯，write，read 的过程过于简单，还很容易出错，对于很多数据交互的程序，会破费大量的工夫在下面；
自定义二进制格局的扩展性：
不便于扩大，但 json 能够很好地解决这种问题；
json 相比拟二进制的数据量也不是问题：
json 的占用空间稍大，然而咱们能够通过网络数据压缩来解决，况且 json 自身也是轻量级的，传输效率也很高；