深入Protobuf源码－编码实现

基本类型编码

在前文有提到消息是一系列的基本类型以及其他消息类型的组合，因而基本类型是probobuf编码实现的基础，这些基本类型有：

在Java种对不同类型的选择，其他的类型区别很明显，主要在与int32、uint32、sint32、fixed32中以及对应的64位版本的选择，因为在Java中这些类型都用int(long)来表达，但是protobuf内部使用ZigZag编码方式来处理多余的符号问题，但是在编译生成的代码中并没有验证逻辑，比如uint的字段不能传入负数之类的。而从编码效率上，对fixed32类型，如果字段值大于2^28，它的编码效率比int32更加有效；而在负数编码上sint32的效率比int32要高；uint32则用于字段值永远是正整数的情况。

在实现上，protobuf使用CodedOutputStream实现序列化逻辑、CodedInputStream实现反序列化逻辑，他们都包含write/read基本类型和Message类型的方法，write方法中同时包含fieldNumber和value参数，在写入时先写入由fieldNumber和WireType组成的tag值（添加这个WireType类型信息是为了在对无法识别的字段编码时可以通过这个类型信息判断使用那种方式解析这个未知字段，所以这几种类型值即可），这个tag值是一个可变长int类型，所谓的可变长类型就是一个字节的最高位（msb，most significant bit）用1表示后一个字节属于当前字段，而最高位0表示当前字段编码结束。在写入tag值后，再写入字段值value，对不同的字段类型采用不同的编码方式：
1. 对int32/int64类型，如果值大于等于0，直接采用可变长编码，否则，采用64位的可变长编码，因而其编码结果永远是10个字节，所有说它int32/int64类型在编码负数效率很低（然而这里我一直木有想明白对int32类型为什么需要做64位的符号扩展，不扩展，5个字节就可以了啊，而且对64位的负数也不需要用符号扩展，或者无法符号扩展，google上也没有找到具体原因）。

2. 对uint32/uint64类型，也采用变长编码，不对负数做验证。

3. 对sint32/sint64类型，首先对该值做ZigZag编码，以保留，然后将编码后的值采用变长编码。所谓ZigZag编码即将负数转换成正数，而所有正数都乘2，如0编码成0，-1编码成1，1编码成2，-2编码成3，以此类推，因而它对负数的编码依然保持比较高的效率。

4. 对fixed32/sfixed32/fixed64/sfixed64类型，直接将该值以小端模式的固定长度编码。

5. 对double类型，先将double转换成long类型，然后以8个字节固定长度小端模式写入。

6. 对float类型，先将float类型转换成int类型，然后以4个字节固定长度小端模式写入。

7. 对bool类型，写0或1的一个字节。

8. 对string类型，使用UTF-8编码获取字节数组，然后先用变长编码写入字节数组长度，然后写入所有的字节数组。

9. 对bytes类型（ByteString），先用变长编码写入长度，然后写入整个字节数组。

10. 对枚举类型（类型值WIRETYPE_VARINT），用int32编码方式写入定义枚举项时给定的值（因而在给枚举类型项赋值时不推荐使用负数，因为int32编码方式对负数编码效率太低）。

11. 对内嵌Message类型（类型值WIRETYPE_LENGTH_DELIMITED），先写入整个Message序列化后字节长度，然后写入整个Message。

注：ZigZag编码实现：(n << 1) ^ (n >> 31) / (n << 1) ^ (n >> 63)；在CodedOutputStream中还存在一些用于计算某个字段可能占用的字节数的compute静态方法，这里不再详述。

在protobuf的序列化中，所有的类型最终都会转换成一个可变长int/long类型、固定长度的int/long类型、byte类型以及byte数组。对byte类型的写只是简单的对内部buffer的赋值：

对32位可变长整形实现为：

对byte数组，可以简单理解为依次调用writeRawByte()方法，只是CodedOutputStream在实现时做了部分性能优化。这里不详细介绍。
对CodedInputStream则是根据CodedOutputStream的编码方式进行解码，因而也不详述，其中关于ZigZag的解码：(n >>> 1) ^ -(n & 1)

repeated字段编码

对于repeated字段，一般有两种编码方式：

1.     每个项都先写入tag，然后写入具体数据。如对基本类型：

而对message类型：

2.     先写入tag，后count，再写入count个项，每个项包含length|data数据。即：

从编码效率的角度来看，个人感觉第二中情况更加有效，然而不知道处于什么原因考虑，protobuf采用了第一种方式来编码，个人能想到的一个理由是第一种情况下，每个消息项都是相对独立的，因而在传输过程中接收端每接收到一个消息项就可以进行解析，而不需要等待整个repeated字段的消息包。对于基本类型，protobuf也采用了第一种编码方式，后来发现这种编码方式效率太低，因而可以添加[packed = true]的描述将其转换成第三种编码方式（第二种方式的变种，对基本数据类型，比第二种方式更加有效）：
3. 先写入tag，后写入字段的总字节数，再写入每个项数据。即：

目前protobuf只支持基本类型的packed修饰，因而如果将packed添加到非repeated字段或非基本类型的repeated字段，编译器在编译.proto文件时会报错。

未识别字段编码

在protobuf中，将所有未识别字段保存在UnknownFieldSet中，并且在每个由protobuf编译生成的Message类以及GeneratedMessage.Builder中保存了UnknownFieldSet字段unknownFields；该字段可以从CodedInputStream中初始化（调用UnknownFieldSet.Builder的mergeFieldFrom()方法）或从用户自己通过Builder设置；在序列化时，调用UnknownFieldSet的writeTo()方法将自身内容序列化到CodedOutputStream中。

UnknownFieldSet顾名思义是未知字段的集合，其内部数据结构是一个FieldNumber到Field的Map，而一个Field用于表达一个未知字段，它可以是任何值，因而它包含了所有5中类型的List字段，这里并没有对一个Field验证，因而允许多个相同FieldNumber的未知字段，并且他们可以是任意类型值。UnknownFieldSet采用MessageLite编程模式，因而它实现了MessageLite接口，并且定义了一个Builder类实现MessageLite.Builder接口用于手动或从CodedInputStream中构建UnknownFieldSet。虽然Field本身没有实现MessageLite接口，它依然实现了该接口的部分方法，如writeTo()、getSerializedSize()用于实现向CodedOutputStream中序列化自身，并且定义了Field.Builder类用于构建Field实例。

在一个Message序列化时(writeTo()方法实现)，在写完所有可识别的字段以及扩展字段，这个定义在Message中的UnknownFieldSet也会被写入CodedOutputStream中；而在从CodedInputStream中解析时，对任何未知字段也都会被写入这个UnknownFieldSet中。

扩展字段编码

在写框架代码时，经常由扩展性的需求，在Java中，只需要简单的定义一个父类或接口即可解决，如果框架本身还负责构建实例本身，可以使用反射或暴露Factory类也可以顺利实现，然而对序列化来说，就很难提供这种动态plugin机制了。然而protobuf还是提出来一个相对可以接受的机制（语法有点怪异，但是至少可以用）：在一个message中定义它支持的可扩展字段值的范围，然后用户可以使用extend关键字扩展该message定义（具体参考相关章节）。在实现中，所有这些支持字段扩展的message类型继承自ExtendableMessage类（它本身继承自GeneratedMessage类）并实现ExtendableMessageOrBuilder接口，而它们的Builder类则继承自ExtendableBuilder类并且同时也实现了ExtendableMessageOrBuilder接口。

public  static  final GeneratedExtension<Foo, Integer> bar = Generated-Message.newFileScopedGeneratedExtension( Integer. class,  null );

bar.internalInit(descriptor.getExtensions().get(0));

Base base = Base.newBuilder().setExtension(SearchRequestProtos.bar, 11).build();