参考资料：
https://blog.csdn.net/zxhoo/article/details/53228303
https://blog.csdn.net/carson_ho/article/details/70568606
1、什么是Protobuf
Protobuf是一个网络通信协议，提供了高效率的序列化和反序列化机制，序列化就是把对象转换成二进制数据发送给服务端，反序列化就是将收到的二进制数据转换成对应的对象。
2、Protobuf消息结构
image.png
使用以Java为例：
byte[] data = Test.newBuilder()
.setA(3).setB(2).setC(1)
.build().toByteArray();
上面对Protobuf的定义，比如：
int32 a = 1;
这个定义不是赋值，它只是定义了a字段的tag，tag包含了数据类型(int32)和字段序号(1)，真正的赋值的在使用的时候，比如上面的Java代码。
序列化之后的数据相当于Key-Value形式，T-V：
image.png
其中，tag有三个作用，一个保证字段不重复，二是保证它是数据流中的位置，三是标记了数据类型。所以，tag是由fieldNumber和wireType组成，fieldNumber保证了字段不重复和它是数据流中的位置，wireType标记了数据类型。
3、Protobuf优点
体积小、效率高；
使用简单、兼容性好、维护简单；
加密性好；
跨平台。
兼容性好
使用Json的时候，有这么一种情况，某个字段值为null或者某个key为null时，Android或IOS相应的Json解析库可能会报错，而Protobuf很好的解决了这问题。
比如，Json序列化的时候，二进制信息如下：
image.png
这种定义，可以对数据顺序写入，然后再顺序读取，这样带来一个问题就是，某些字段没有赋值的情况下，不得不传一个默认值，假如field2没有赋值，那么整个解析包偏移量都会出错，最终整个包的数据读不出。
而Protobuf引入了Tag，解决了这个问题：
image.png
每个field都是由tag和value组成，解析的时候，先读tag，然后通过tag知道value的数据类型，再获取value，写的时候也是一样，先写入tag再写入value。
因为每个field都定义了tag，如果field没有赋值，编码的时候tag不会被写入流中，相应的也不会有它的Value，相对应的解析的时候，如果数据中没有这个field的tag，可以直接无视，读取其他field。
比如上述的常规定义的的二进制信息,在field2没有赋值的情况下，protobuf可以这样：
image.png
还有另外一种兼容的情况，比如：message需要增加一个字段，如果客户端没有升级，服务端升级了，这个时候客户端是旧的message，服务端用的是新的message。
image.png
服务端的新的message：
image.png
这样子，客户端接收到服务端发送过来的数据流是这样的：
image.png
而当客户端解析这数据的时候，发现数据流里面有个tag为3，但是在客户端的协议里找不到对应的tag，然后通过数据流这个tag，这点了它是数据类型是int64，所以知道了这个tag的值占了8个字节，于是Protobuf就会跳过这8个字节，继续解析后面的数据。
效率高、体积小
Protobuf之所以效率比Json、XML高，是因为内部采用了很巧妙的编码方式，来达到数据压缩的目的，比如：
对于 int32类型的数字，一般需要4个字节表示，比如1和300：
00000000 00000000 00000000 00000001 //1
00000000 00000000 00000001 00101100 //300
而通过Protobuf压缩之后是这样的：
00000001 //1
10101100 00000010 //300
Varint编码
原理：值越小的数字，使用越少的字节数表示
作用：通过减少表示数字的字节数从而进行数据压缩
Varint编码高位有特殊含义：如果是1，表示后续的字节也是该数字的一部分，如果是0，表示这是最后一个字节，且剩余7位都用来表示数字。
举例下Varint编码和解码过程：
客户端发送300给服务端，通过Protobuf编码过程：
首先300的源数据是：
00000000 00000000 00000001 00101100
前面两个字节没有意义，Varint会丢掉前面两字节，这里标记为字节0变成：
00000001 00101100
然后从字节0的尾部开始，取7位，变成新字节1，并在最高位补1，最高位补1还是0，取决于后面还有没有字节，字节1为：
10101100
然后继续在字节0中取7位，标记为字节2，由于这次取完后面已经没有字节了，所以字节2高位为0：
00000010
最后，最终编码后的数据变成字节1+字节2：
10101100 00000010
以上就完成了Varint对300编码，接下来看下服务端接收到编码后的数据怎么解析：
首先，接收到的数据是：
10101100 00000010
首先分析下这段数据，有两个字节，每个字节的最高位只是标记的作用，1代表后面的字节是数字的一部分，0表示这个字节是最后一个字节了，所以去掉各自的最高位，变成：
0101100 0000010
然后Varint会将字节调转，变成：
0000010 0101100
对比300的源数据：
0000010 0101100
00000000 00000000 00000001 00101100
调转后的数据：256+32+8+4 = 300
4、实际例子
定义Protobuf：
message person
{
int32 id = 1;
// wire type = 0，field_number =1
string name = 2;
// wire type = 2，field_number =2
}
person.setId(1);
person.setName("testing");
image.png
首先分析字段 int32 id = 1：
由于是int32类型，所以数据是tag-value形式：
tag：
表达式：Tag = (field_number << 3) | wire_type
字段int32 id = 1的field_number为1，左移三位变成：
00001000
然后数据类型是int32，所以 wire_type为0，则最终得出的tag为：
00001000
value:
根据Varint编码，变成1字节：
00000001
最终
字段 int32 id = 1变成：
00001000 00000001 //即8 和 1
然后分析字段 string name = 2：
由于是string类型，所以是tag-length-value形式，value采用UTF编码
tag:
field_number为2，左移3位：
00010000
string类型wire type为2，最终tag为：
00010010
Value:
上面的例子是字符串testing，经过UTF8编码后，变成：
116，101，115，116，105，110，103
Length
value的长度，所以是7，即00000111
最终
数据为：
00010010 00000111 116，101，115，116，105，110，103
5、总结
序列化、反序列化简单、速度快的原因是：
编码 / 解码 方式简单（只需要简单的数学运算 = 位移等等）
数据压缩效果好（即序列化后的数据量体积小）的原因是：
采用了独特的编码方式，如Varint、Zigzag编码方式等等
兼容性高的原因：
采用T - L - V 的数据存储方式
网友评论