初识ProtocolBuf
对于ProtocolBuf的一些情况:“google公司发布的一套开源编码规则,基于二进制流的序列化传输,可以转换成多种编程语言,几乎涵盖了市面上所有的主流编程语言。”
枚举类型数据定义:
//操作类型
enum e_MsgOper_PRO
{
E_ADD_PRO= 0;
E_DEL_PRO= 1;
E_MOD_PRO= 2;
}
//用户角色
enum e_RoomRoles_PRO
{
E_HOST_PRO= 0; //群主
E_MANGER_PRO= 1; //管理员
E_NORMAL_PRO= 2; //普通成员
}
通过枚举类型的数据定义来看,有点想C的枚举定义,但是,每个枚举值都是以’;’结束的,并且也不支持typedef而,有点遗憾的是不像C/C++一样,它的枚举值只能大于等于0;为了尽量避免和你的语言内部使用的数据结构发生冲突,最好在Pro文件上加上比较容易识别的后缀,我添加的后缀就是_PRO;
消息类型数据定义:
message HsUserOrderListInfo_Pro //用户订单基本信息
{
requireduint32 uOrderID= 1; //订单查询标示;
optionale_HsOrderState_Pro iOrderState= 2; //订单状态ID
optionalstring szOrderState= 3; //订单状态
optionalstring szOrderType= 4; //订单类型标示;
optionalstring szOrderTime= 5; //订单生成日期;
}
message HsUserOrderList_Resp_Pro
{
requirede_HsOperResult_Pro eOperResult = 1[default = E_HSOPER_SUCCESS_PRO];
repeatedHsUserOrderListInfo_Pro Value =2;
}
1、数据类型
Protocol支持的基本数据类型还是比较多的如下表所示:
N 表示打包的字节并不是固定。而是根据数据的大小或者长度。
例如int32,如果数值比较小,在0~127时,使用一个字节打包。
关于枚举的打包方式和uint32相同。
关于message,类似于C语言中的结构包含另外一个结构作为数据成员一样。
关于 fixed32 和int32的区别。fixed32的打包效率比int32的效率高,但是使用的空间一般比int32多。因此一个属于时间效率高,一个属于空间效率高。根据项目的实际情况,一般选择fixed32,如果遇到对传输数据量要求比较苛刻的环境,可以选择int32.
2、字段名称
字段名称的命名与C、C++、Java等语言的变量命名方式几乎是相同的。
protobuf建议字段的命名采用以下划线分割的驼峰式。例如 first_name而不是firstName.
3、字段编码值
有了该值,通信双方才能互相识别对方的字段。当然相同的编码值,其限定修饰符和数据类型必须相同。
编码值的取值范围为 1~2^32(4294967296)。
其中 1~15的编码时间和空间效率都是最高的,编码值越大,其编码的时间和空间效率就越低(相对于1-15),当然一般情况下相邻的2个值编码效率的是相同的,除非2个值恰好实在4字节,12字节,20字节等的临界区。比如15和16.
1900~2000编码值为Google protobuf系统内部保留值,建议不要在自己的项目中使用。
protobuf 还建议把经常要传递的值把其字段编码设置为1-15之间的值。
消息中的字段的编码值无需连续,只要是合法的,并且不能在同一个消息中有字段包含相同的编码值。
建议:项目投入运营以后涉及到版本升级时的新增消息字段全部使用optional或者repeated,尽量不实用required。如果使用了required,需要全网统一升级,如果使用optional或者repeated可以平滑升级。
4、默认值
当在传递数据时,对于required数据类型,如果用户没有设置值,则使用默认值传递到对端。当接受数据是,对于optional字段,如果没有接收到optional字段,则设置为默认值。
编程语言转换
ProtocolBuf支持针对多种语言的数据类型转换,当然还是以Java语言的转换最到位,悲催的C++数据转换竟然抹掉了所有的注释说明,因此,使用ProtocolBuf转换后的C++代码,需要你对着.pro文件去细看,还有就是针对C++语言的支持的一个缺陷是,如果数据内容完全相同,只是消息名称不一样的话,也不支持。转换之后,只需把.h和.cc文件加入到工程中,再引入Protocol的动态库即可。关于ProtocolBuf的转换工具也是开源的,虽然不太好用,但也是可以的,如果实在忍受不了,则自己写一个呗。
ProtocolBuf的缺陷;
ProtcolBuf的出现,优点:免费、开源、短小、传输效率高,然而,它也有其自身的缺点:那就是还不够成熟,且数据易读性很差,但ProtocolBuf是谷歌自己使用和编写出来的,协议尚未纳入到国际表中中去,仅靠抓包和码流分析,难以发现问题,不过,好在其是开源的,可以根据自己的业务数据,写出一套专门的数据拆分工具来,也可以使用网上已有的数据解析工具;另外一点就是调试比较难,发现有问题,调试起来并不能得心应手,因为转换后的语言信息可读性太差。
有时间做个性能对比,pb,xml,fb