产品经理提出的需求经常需要终端，后台之间相互协作才能完成，而在功能开发的过程中经常会听到“定协议”这样的词，对这个词大致的印象就是“两个开发之间商量好怎么发数据，然后就可以开始调试，逐渐完成功能了”。

对于逻辑上的协议，产品经理可能并不陌生（甚至有些协议直接出自产品经理之手），对协议内容的描述类似于“0表示关闭功能，1表示开启功能，用个type标识来源...”。一旦逻辑上的协议确定了，不同的开发和产品之间相当于在思想上达成了一致，然后围绕协议来书写各自的业务逻辑。

这一切似乎很自然，就如我们走路一般。正因为太自然，所以我们经常会忽略一些基础设施，就如我们脚下的路一般。仔细想想，虽然逻辑上的协议确定了，终端和后台之间还需要跨越网络，甚至还需要跨越平台的进行协议的传输和解析，那么逻辑上制定的那些协议又要如何在复杂的环境中正确的传输和解析呢？

先来了解一下基本数据类型。各种编程语言中都有自己的基本数据类型（大同小异），比如bool(布尔型），int（整形），float（浮点型），String（字符串）等等，这些数据都是可以在内存中存储，计算的，对计算机来说都是一种二进制的数据表示（计算机只懂二级制）。我们把这些基本数据类型按照业务的需要组合起来形成更大的数据结构体。像制定的协议，也是数据结构体的一种，所以协议经常是这个样子：

Protocol

{

boolean isEnable;

int from;

String message;

...

}

虽然这里的数据结构体比基本数据类型复杂了一些，但是对计算机来说只是把几个二进制数据表示拼接到一起了而已。使用基本数据类型或基本数据类型的组合的好处就是计算机可以方便的读写（因为都是二进制），这里强调基本数据类型是为了引入一个概念————序列化。

序列化就是将数据对象转成二进制串，反序列化就是将二进制串还原成数据对象，能够被序列化是数据对象能够持久化（保存到硬盘）或是在网络中，不同平台间互相传输的先决条件。当然，不仅仅是基本数据类型，只要能够被表示成二进制的对象都是可以序列化的，比如一张图片，在计算机中图片是用bitmap表示的，同样也是二进制串。你可能会问，那什么是不能够被序列化的呢？比如按钮（Button）这种对象就不能被序列化，你没听说要把一个按钮保存到文件里面，或者把一个按钮传到服务器吧。

能够被序列化仅仅解决了协议传输的问题，但是为了协议的收发双方能够方便的解析协议，还需要遵循一些通用的协议表示的规范。基本数据类型里扩展性最好的就是字符串，管你什么bool，int，float，字符串都能间接表示，比如1->"1",true->"true",3.14->"3.14"酱紫，所以在此基础上，出现了一些用字符串来表示数据结构对象的协议，比如XML，JSON（一步一步写爬虫之JSON解析）等，使用这种协议的收发双方在语义上都是使用的可理解的字符串传输，通过一些特殊的标记、分隔符来模块化数据表示。

所以协议的收发过程变成了，发送方将协议制定的字段写成XML或者JSON格式的字符串，序列化之后传输，接收方反序列化还原出字符串，然后按照XML或者JSON格式取出传过来的各个协议字段。如果要求苛刻一点就会发现这两种协议序列化后大部分情况下有空间浪费，比如协议中的数据都是可以通过byte来表示的，即用1，2，3这种简单的数字形式来表示，这时用字符串表示显然有些空间浪费了，所以很多公司在序列化反序列化的理论基础上做了自己的解析协议，尽可能的减少协议存储和传输的大小，那么在协议多，用户量大的情况下，传输数据量的节省就非常可观了。