前言
即时通讯应用（包括IM聊天应用、实时消息推送应用等）开发的前期技术选型时，关于数据传输格式的选择，在即时通讯开发者同行的眼里，是个极富争议话题。
精略分析一下，大概的原因在于：
[1] 可选择的协议或封装格式多种多样：
可选择的余地很大：XMPP、Protobuf、JSON、私有2进制、MQTT、定格化XML、Plain text等等；
[2] 同一种格式并不能适用于大多数的场景：
不同的场景有同的考虑而协议的选择往 跟这是挂钩在一起的，比如：移动端IM或推送技术用XMPP这样的协议时，多数情况下都会被喷；
[3] 开发者对所选格式有各自的偏好：
有的人或团队对某种或某几种格式有不一样的经验和技术积累，也促成了他们对某种或某几种协议的偏好。
其实总结以上原因就可以知道，之所以对于即时通讯应用的数据传输格式有不同的声音，根本原因还在于应具体事情具体分析，该选什么协议由场景决定、由团队的技术积累决定、甚至由项目的周期和成本决定，这里不存在唯一解，只有最适合的数据传输格式，不存在最好的格式一说。
当然，本文内容中对即时通讯传输格式的选择，是原作者的一家之言，可能存在很大争议，但如能为你的即时通讯应用开发的技术选型带来些许启发，我相信这才符合作者的本意。（本文同步发布于：http://www.52im.net/thread-276-1-1.html）
学习交流
– 即时通讯开发交流群：215891622 [推荐]
更多资料
移动端IM开发，推荐阅读：《新手入门一篇就够：从零开发移动端IM》。
数据格式的选型需要考虑的方面
[1] 网络数据大小：占用带宽，传输效率
虽然对单个用户来说，数据量传输很小，但是对于服务器端要承受众多的高并发数据传输（尤其现时高并发、大用户量的IM聊天应用和实时推送服务端等场景），必须要考虑到数据占用带宽，尽量不要有冗余数据，这样才能够少占用带宽，少占用资源，少网络IO，提高传输效率。
[2] 网络数据安全性：敏感数据的网络安全
对于相关业务的部分数据传输都是敏感数据，所以必须考虑对部分传输数据进行加密。这通常出现在银行等数据安全性要求很高的应用行业和场景里，当然传统的即时通讯应用里基于用户隐私考虑，数据加密也是同样是个必须考虑的问题。安全性是应用的基础条件，需求是一样的，只是加密程度、安全性级别要求有不同而已。
[3] 编码复杂度
编码复杂度包括序列化和反序列化复杂度、效率、数据结构的可扩展性和可维护性。
对于平台相关业务的代码实现也需要考虑到数据发送方和数据接收方数据处理的复杂度和数据结构的可扩展性，可维护性，人力成本和实施复杂度也必须考虑在内。通常情况下，即时通讯应用（比如IM聊天应用）在开发的前期，为了方便调试，很多团队会用简单的文本协议、JSON等能直观查看的方式，但后期生产部署后，为了流量等考虑，可能会转用Protobuf等更省流量的协议。但总之，协议的定义不可能永远一成不变，但如果在实现的时候就有这些预见性，相性会大大减轻未来的运营风险。
[4] 协议通用性、大众规范
数据类型必须是跨平台，数据格式是通用的，大家普遍能接受上手的。当然，现在已经迈入移动互联网时代，多端、多平台、异构平台的数据通讯是先决条件，而协议的选择，通用性也最多只是应用层有区别。当然，无论如何，异构平台的一致性，是毫无争议的必备条件。
不同类别的数据传输协议（格式）的比较
[1] 自定义二进制
优点：信息体积小，对应以上”1“
缺点：编码复杂度高（自己定义消息格式，自己编写序列化和反序列化方法，自己进行容错处理，可扩展性不强，比如添加个字段，就必须改两端的逻辑处理），对应以上”3“；
[2] 提供序列化和反序列化库的开源协议
比如谷歌的protocol buffers，json，Thrift
优点：是一种流行的通用数据格式，扩展相当方便，序列化和反序列化相当方便（有相应库），错误处理方便（库支持）。
[3] 文本化协议
比如xml，json
优点：序列化，反序列化容易（库支持），调试方便，可视化强；
缺点：相对于二进制存储占用体积大。
你会选择哪种格式？
我会选择JSON（PS: 文中的“我”指原作者），因为他是“提供序列化和反序列化库的开源协议还是文本化的协议”，原因如下：
[1] 自定义二进制格式的复杂性：
自定义二进制格式进行传输的工作，整个过程在定义消息，write，read的过程过于复杂，还很容易出错，对于很多数据交互的程序，会花费大量的时间在上面；
[2] 自定义二进制格式的扩展性：
不便于扩展，但json可以很好地解决这种问题；
[3] json相比较二进制的数据量也不是问题：
json的占用空间稍大，但是我们可以通过网络数据压缩来解决，况且json本身也是轻量级的，传输效率也很高；
[4] 去看《unix编程艺术》吧：
《第5章–文本化，好协议产生好实践》、《第6章–透明性：来点儿光》会告诉你使用文本化协议的好处。
结语
文字看完了，原文作者选择JSON作为即时通讯应用的数据传输格式（协议），到底该怎么选，相信你也已经找到答案了。（推荐看看另一篇《移动端IM开发需要面对的技术问题》）
相关技术资料分类
[1] 网络编程基础资料：
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
[2] 有关IM/推送的通信格式、协议的选择：
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
[3] 有关IM/推送的心跳保活处理：
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
[4] 有关WEB端即时通讯开发：
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
[5] 有关IM架构设计：
[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
[7] 有关实时音视频开发：
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除�概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除�技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
[8] IM开发综合文章：
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
[11] 更多即时通讯技术好文分类：
（本文同步发布于：http://www.52im.net/thread-276-1-1.html）
作者：Jack Jiang(点击作者姓名进入Github)
出处：http://www.52im.net/space-uid-1.html
交流：�欢迎加入即时通讯开发交流群215891622
Jack Jiang同时是【原创Java Swing外观工程BeautyEye】和【轻量级移动端即时通讯框架MobileIMSDK】的作者，可前往下载交流。
