突然间，好像对ProtoBuf有点陌生的感觉，特此复习一下。
背景知识
Protocol Buffers可以理解为更快、更简单、更小的JSON或者XML，区别在于Protocol Buffers是二进制格式，而JSON和XML是文本格式。
Protobuf经序列化后以二进制数据流形式存储，这个数据流是一系列key-Value对。Key用来标识具体的Field，在解包的时候，Protobuf根据 Key 就可以知道相应的 Value 应该对应于消息中的哪一个 Field。
Key 的定义如下：
(field_number << 3) | wire_type
Key由两部分组成。第一部分是 field_number，比如消息 tutorial .Person中 field name 的 field_number 为 1。第二部分为 wire_type。表示 Value 的传输类型。Wire Type 可能的类型如下表所示：
| Type | Meaning | Used For |
|---|---|---|
| 0 | Varint | int32, int64, uint32, uint64, sint32, sint64, bool, enum |
| 1 | 64-bit | fixed64, sfixed64, double |
| 2 | Length-delimi | string, bytes, embedded messages, packed repeated fields |
| 3 | Start group | Groups (deprecated) |
| 4 | End group | Groups (deprecated) |
| 5 | 32-bit | fixed32, sfixed32, float |
Protobuf的二进制使用Varint编码。Varint 是一种紧凑的表示数字的方法。它用一个或多个字节来表示一个数字，值越小的数字使用越少的字节数。这能减少用来表示数字的字节数。
Varint 中的每个 byte 的最高位 bit 有特殊的含义，如果该位为 1，表示后续的 byte 也是该数字的一部分，如果该位为 0，则结束。其他的 7 个 bit 都用来表示数字。因此小于 128 的数字都可以用一个 byte 表示。大于 128 的数字，比如下面demo中的2000 就是用两个字节来表示。
Demo Code
Demo Code 主要对比了一下，用Gzip 压缩序列化的Json数据与Protobuf 数据的速度和大小对比。可以看到，Protobuf 最大的一个优点果然是在数据压缩方面。那么数据是如何存取的呢？
手工解析pb数据
下面是一段Json数据：
NSDictionary *userInfoDic = @{@"userName":@"vedon",
@"age":@(2000),
@"mobileNumber":@"1501849235x",
@"address":@"广州市平云广场",
@"numberOfFriends":@(2000),
};
它对应的的pb 数据为：
<0a057665 646f6e10 1b1a0b31 35303138 34393233 35782215 e5b9bfe5 b79ee5b8 82e5b9b3 e4ba91e5 b9bfe59c ba2802>
解析userName
Key :
0a = 0000 1010
=> 0001 010
=> field_num = 0001 ,type = 010
=> field_num = 1,type = 2
Value:
05 = 0000 0101
=> 000 0101 (去掉最高位)
=> 5
读取5个字符：
userName = 76 65 64 6f 6e => v e d o n
解析age
Key :
10 = 0001 0000
=> 001 0000 (去掉最高位)
=> field_num = 0010 ,type = 000
=> field_num = 2 ,type = 0
Value
1b = 0001 1011
=> 27
age = 27 .
如果age = 2000 ,2000超过一个字节表示的大小了，它会怎么表示呢？
改一下代码，把年龄改成2000 ，发现除了key是不变外，value 从1b变成d00f
d00f = 1101 0000 | 0000 1111
=> 101 0000 | 000 1111 (little-endian)
=> 0111 1101 0000 = 2000
age = 2000
解析mobileNumber
Key:
1a = 0001 1010
=> 001 1010 (去掉最高位)
=> field_num = 0011 ,type = 010
=> field_num = 3 ,type = 2
Value:
0b = 0000 1011
=> 11
读取11个字符:
31 35 30 31 38 34 39 32 33 35 78 => 1 5 0 1 8 4 9 2 3 5 x
优点
- 序列化速度快
- 体积小
- 兼容性好
- Protocol Buffers的编译器，可以生成更容易在编程中使用的数据访问代码
缺点
- 缺乏自描述，可读性差
- 适用于内部服务和存储
JSON and Protobuf
Protobuf 相比 JSON 的优势在于它本身带有严格的 schema validation，一份 .proto 文件既作为 input/output 的入口，又作为规定数据格式的文档。例如：后端给一份.proto 文件，通过官方提供的工具，生成对应的oc 类，在跨语言多人协作的项目上用起来不能更爽。
Protobuf 是 schema + data format，schema 是我们可以看见的 proto 文件里的定义，data format 是它序列化成二进制数据的格式。
最终选择的时候还有个很关键的因素，就是公司整个大环境的技术选型，如果你所依赖的其他组件用 JSON 的较多，那么也不要刻意用 Protobuf 。如果一个大型项目在一开始就用了 Protobuf 作为数据格式的约定，后期在数据一致性上可能出现很多麻烦就可以避免掉呢。
详细的性能分析，网上已经有很详细的了。这里推荐一篇文章：Beating JSON performance with Protobuf
