Protobuf 简介

在移动互联网时代，手机流量、电量是最为有限的资源，而移动端的即时通讯应用无疑必须得直面这两点

解决流量过大的基本方法就是使用高度压缩的通信协议，而数据压缩后流量减小带来的自然结果也就是省电：因为大数据量的传输必然需要更久的网络操作、数据序列化及反序列化操作，这些都是电量消耗过快的根源

当前即时通讯应用中最热门的通信协议无疑就是 Google 的 Protobuf 了。它和 xml、json 类似，定义了数据结构的存储格式，并且为 C++、java 等数十种语言提供了对应的 api，让该通信协议可以在不同语言的项目中相互通信

使用

Protobuf 的语法非常类似 c 语言，下面是一个例子。首先我们需要编写一个 proto 文件，定义我们程序中需要处理的结构化数据，在 protobuf 的术语中，结构化数据被称为 Message

package lm;
message helloworld
{required int32     id = 1;  // IDrequired string    str = 2;  // stroptional int32     opt = 3;  //optional field
}

写好 proto 文件之后就可以用 Protobuf 编译器将该文件编译成目标语言了。我们可以使用 maven 的 install 功能直接将 proto 文件编译为 java 语言，这次我们选择将该文件编译为 c++

protoc -I=$SRC_DIR --cpp_out=$DST_DIR $SRC_DIR/addressbook.proto

命令将生成两个文件：

• lm.helloworld.pb.h ， 定义了 C++ 类的头文件
• http://lm.helloworld.pb.cc ， C++ 类的实现文件

在生成的头文件中，定义了一个 C++ 类 helloworld，一般来说我们还需要添加诸如对消息的成员进行赋值，将消息序列化等等都有相应的方法

Protobuf 的主要优点就是：简单，快。这有测试为证，项目 thrift-protobuf-compare 比较了这些类似的技术，显示了该项目的一项测试结果

技术内幕

有两项技术保证了采用 Protobuf 的程序能获得相对于 XML 极大的性能提高：

• Protobuf 封解包的过程比 XML 更加优秀
• 我们可以考察 Protobuf 序列化后的信息内容。Protocol Buffer 信息的表示非常紧凑，这意味着消息的体积减少，自然需要更少的资源。比如网络上传输的字节数更少，需要的 IO 更少等，从而提高性能

首先我们来了解一下 XML 的封解包过程。XML 需要从文件中读取出字符串，再转换为 XML 文档对象结构模型。之后，再从 XML 文档对象结构模型中读取指定节点的字符串，最后再将这个字符串转换成指定类型的变量。这个过程非常复杂，其中将 XML 文件转换为文档对象结构模型的过程通常需要完成词法文法分析等大量消耗 CPU 的复杂计算

反观 Protobuf，它只需要简单地将一个二进制序列，按照指定的格式读取到 C++ 对应的结构类型中就可以了。从上一节的描述可以看到消息的 decoding 过程也可以通过几个位移操作组成的表达式计算即可完成。速度非常快

第二点，Protobuf 序列化后所生成的二进制消息非常紧凑，这得益于 Protobuf 采用的非常巧妙的 Encoding 方法比如对于 int32 类型的数字，一般需要 4 个 byte 来表示。但是采用 Varint，对于很小的 int32 类型的数字，则可以用 1 个 byte 来表示。当然凡事都有好的也有不好的一面，采用 Varint 表示法，大的数字则需要 5 个 byte 来表示。从统计的角度来说，一般不会所有的消息中的数字都是大数，因此大多数情况下，采用 Varint 后，可以用更少的字节数来表示数字信息

Varint 中的每个 byte 的最高位 bit 有特殊的含义，如果该位为 1，表示后续的 byte 也是该数字的一部分，如果该位为 0，则结束。其他的 7 个 bit 都用来表示数字。因此小于 128 的数字都可以用一个 byte 表示。大于 128 的数字，比如 300，会用两个字节来表示：1010 1100 0000 0010。下图演示了 Google Protocol Buffer 如何解析两个 bytes。注意到最终计算前将两个 byte 的位置相互交换过一次，这是因为 Google Protocol Buffer 字节序采用 little-endian 的方式

消息经过序列化后会成为一个二进制数据流，该流中的数据为一系列的 Key-Value 对