分析一下 Google Protocol Buffers 的序列化原理。介绍参考 Google Protocol Buffers 数据交换协议

说明

详细介绍参见官方文档

编写 proto 文件

定义了4个变量 a, b, c, d，其 Field 分别为 1~4。为了展示不同类型的序列化原理，将变量分别定义成 int32, int64, fixed64, string。

option java_outer_classname = "YanoTestProbuf";

message YanoTest{
    optional int32 a = 1;
    optional int64 b = 2; 
    optional fixed64 c = 3; 
    optional string d = 4; 
}

测试字节码

@Test
public void testProtoBuf() {
    // encode bytes
    byte[] bytes = YanoTest.newBuilder().setA(1).setB(2).setC(3).setD("java").build().toByteArray();
    System.out.println(Arrays.toString(bytes));
    
    // decode bytes
    for (byte b : bytes) {
        System.out.println(getBinString(b));
    }
}

private String getBinString(byte b) {
    return String.format("%8s", Integer.toBinaryString(b)).replace(' ', '0');
}

生成的字节码

[8, 1, 16, 2, 25, 3, 0, 0, 0, 0, 0, 0, 0, 34, 4, 106, 97, 118, 97]

每个字节转换成二进制为：

让我们分析下这些字节码~~~^_

分析字节码

首先要明确，Protocol Buffers 序列化的字节码是很紧凑的，而且是 key-value 的形式：

其中一个 key-value 就是一个 Field，就是定义的 abcd~

key 都是一个字节，以第一个 key 00001000 为例，key 有两个含义：

(field_number << 3) | wire_type

5 位 field_number + 3 位 wire_type，其中 wire_type 如下：

varint

Varint 是一种紧凑的表示数字的方法。它用一个或多个字节来表示一个数字，值越小的数字使用越少的字节数。这能减少用来表示数字的字节数。

比如对于 int32 类型的数字，一般需要 4 个 byte 来表示。但是采用 Varint，对于很小的 int32 类型的数字，则可以用 1 个 byte 来表示。当然凡事都有好的也有不好的一面，采用 Varint 表示法，大的数字则需要 5 个 byte 来表示。从统计的角度来说，一般不会所有的消息中的数字都是大数，因此大多数情况下，采用 Varint 后，可以用更少的字节数来表示数字信息。下面就详细介绍一下 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 的方式。

字段 a（int32）

第一个 key 00001000 的前 5 位是 1，表明是字段 a；后 3 位 wire_type 是 0，所以是 Varint（一种变长的数值类型，在表示小数值的数时更省空间）。

第一个 value 是 00000001，所以是 a = 1。

字段 b（int64）

key             00010000
field_number    2               b
wire_type       0               Varint
value           00000010        2

字段 c（fixed64，定长）

key             00011001
field_number    3               c
wire_type       1               64-bit
value           3               00000011
                                00000000
                                00000000
                                00000000
                                00000000
                                00000000
                                00000000
                                00000000

字段 d（string）

key             00100010
field_number    4               d
wire_type       2               Length-delimited
value           java            00000100(length:4)
                                01101010 j
                                01100001 a
                                01110110 v
                                01100001 a

与 JSON 和 XML 序列化对比

JSON

上面的代码，用 JSON 来表示是这样的：

{"a":"1","b":"2","c":"3","d":"java"}

代码测试长度：

@Test
public void testJSON() {
    String json = "{\"a\":\"1\",\"b\":\"2\",\"c\":\"3\",\"d\":\"java\"}";
    System.out.println(json.getBytes().length);
}

结果是 36 个字节，而 protobuf 生成的字节码仅有 18 个字节。

说明：本例中的 protobuf 字段 c 使用了 fixed64 类型，否则还能够省 5 个字节。protobuf 还有一个非常明显的好处就是：长度与字段的名字无关。如果字段 a 叫做 apple，那么 protobuf 序列化后仍然是 18 个字节，而 JSON 则要增加 4 个字节。

XML

XML 就不必说了，ε=(´ο｀*)))

Google Protocol Buffers 的一点思考

该协议开发过程确实有些繁琐，因为要编写 proto 文件，并生成对应语言的代码；同时因为是字节码，并不容易读取（需要将其转换成对象，打印对象）。如果要更改协议，需要频繁修改文件及代码。
但是正是因为这种约束，Protocol Buffers 具有非常强的版本兼容性。换做是 JSON，虽然很灵活，但是完全没有约束~~~
Protocol Buffers 序列化的字节码非常非常小，速度很快，是游戏开发的首选。

Google Protocol Buffers 序列化算法分析

说明