google protocol buffer 源码简析

protocol buffer(以下简称PB)作为一种效率和兼容性都很优秀的二进制数据传输格式，可以用于诸如
网络传输，配置文件，数据存储等诸多领域。本文的分析基于google发布的源码2.0.1版本
PB的源码结构大致如下:

PB源码
{
PB基础库
{
Message抽象层
Descriptor抽象层
IO子系统
}
PB编译器----源码生成器
}

IO子系统最为简单，不依赖于系统其他部分，实现统一的输入输出接口

Message抽象层主要由一个抽象的Message类和从Message类里面单独分离出来的Reflection类构成.
GeneratedMessageReflection是Reflection的派生类，实现了抽象的Message方法。这里的关键在于
一个静态的offsets_数组，里面存储了任何Message派生类对象里面各个字段相对于对象本身的偏移量。
利用这个偏移量，GeneratedMessageReflection可以在不知道确切字段名字和类型的情况下实现
Reflection里面定义的Message方法

Descriptor抽象层是系统的核心。由平行的两组解释器构成。一组是一系列递归下降的Descriptor类群，
另一组是一系列递归下降的DescriptorProto类群。Descriptor类群描述的是抽象的任意的消息。
DescriptorProto类型是对消息格式本身进行描述的消息。其中FileDescriptorProto类群描述了.proto
文件的结构，任何.proto文件都可以映射到一个FileDescriptorProto对象上。FileDescriptorProto对象
和FileDescriptor之间可以相互转换.

PB编译器实际上是一组递归下降的CodeGenerator类群。Generator的输入是Descriptor类群，输出是
具体的派生消息类

整个编译器的运作过程如下
1 从.proto文件生成FileDescriptorProto对象
2 从FileDescriptorProto对象生成FileDescriptor对象
3 CodeGenerator从FileDescriptor对象生成代码
这里的关键是第一步，相当于常规编译的词法和语法分析，构造解释器的过程。但是看代码我们并没有
发现词法和语法分析过程。google是怎么做到的呢。原来，在Generator里面通过把FileDescriptor转化为
FileDescritorProto，然后SerializeToString序列化后把二进制直接输出到代码中。于是
FileDescriptorProto对象就可以直接从这个二进制通过ParseFromArray构造出来。这里有一个问题，
FileDescriptorProto类本身就是Generator生成的，依赖于Generator,Generator依赖于FileDescriptor,
FileDescriptor依赖于FileDescriptorProto对象，FileDescriptorProto对象又依赖于
FileDescriptorProto类。这就构成了一个循环依赖。这是一个鸡生蛋还是蛋生鸡的问题。其实我们可以
想像，最初的FileDescriptorProto类可以手工构造，然后用这个手工构造的类生成其他派生消息类包括
现在的FileDescriptorProto类。这样，google就把词法和语法分析纳入到了已有的序列化和反序列化
过程中，而不需要单独的其他逻辑。