protocolbuffer(以下简称PB)是google 的一种数据交换的格式，它独立于语言，独立于平台。google 提供了三种语言的实现：java、c++ 和 python，每一种实现都包含了相应语言的编译器以及库文件。由于它是一种二进制的格式，比使用 xml 进行数据交换快许多。可以把它用于分布式应用之间的数据通信或者异构环境下的数据交换。作为一种效率和兼容性都很优秀的二进制数据传输格式，可以用于诸如网络传输，配置文件，数据存储等诸多领域。本文的分析基于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就把词法和语法分析纳入到了已有的序列化和反序列化
过程中，而不需要单独的其他逻辑。
