我们先看看官方文档给出的定义和描述
protocol buffers 是一种语言无关、平台无关、可扩展的序列化结构数据的方法,它可用于(数据)通信协议、数据存储等。
Protocol Buffers 是一种灵活,高效,自动化机制的结构数据序列化方法-可类比 XML,但是比 XML 更小(3 ~ 10倍)、更快(20 ~ 100倍)、更为简单。
你可以定义数据的结构,然后使用特殊生成的源代码轻松的在各种数据流中使用各种语言进行编写和读取结构数据。你甚至可以更新数据结构,而不破坏由旧数据结构编译的已部署程序。
简单来讲, ProtoBuf 是结构数据序列化方法,可简单类比于,其具有以下特点:
在protobuf中,协议是由一系列的消息组成的。因此最重要的就是定义通信时使用到的消息格式。一个Protobuf 消息(对应JAVA类),由至少一个字段(对应Java类属性)组合而成。
消息的定义很简单,就是message关键字加上消息的名字
message xxx{
}
字段定义格式:
限定修饰符 | 数据类型 | 字段名称 | = | 字段编码
required string room_id = 1; // 直播间id
限定修饰符(包含required、optional、Repeated)
required:
表示是一个必须字段,必须相对于发送方,在发送消息之前必须设置该字段的值,对于接收方,必须能够识别该字段的意思。发送之前没有设置required字段或者无法识别required字段都会引发编解码异常,导致消息被丢弃。
optional:
表示是一个可选字段,可选对于发送方,在发送消息时,可以有选择性的设置或者不设置该字段的值。对于接收方,如果能够识别可选字段就进行相应的处理,如果无法识别,则忽略该字段,消息中的其它字段正常处理。---因为optional字段的特性,很多接口在升级版本中都把后来添加的字段都统一的设置为optional字段,这样老的版本无需升级程序也可以正常的与新的软件进行通信,只不过新的字段无法识别而已,因为并不是每个节点都需要新的功能,因此可以做到按需升级和平滑过渡。
repeated:
表示该字段可以包含0~N个元素。其特性和optional一样,但是每一次可以包含多个值。可以看作是在传递一个数组的值。类比于Java这边的List
数据类型
protobuf定义了一套基本的数据类型,几乎都映射了Java语言的基础数据类型(主要以Java为例)
详见下面表格
protobuf.jpg
字段的默认值
字段名称
字段的命名方式与Java的命名方式大致一致
字段编码值
字段编码是一个序列化和反序列化的标记值,有了该值,通信双方才能互相识别对方的字段。当然相同的编码值,其限定修饰符和数据类型必须相同。编码值的取值范围为 1~2^32(4294967296)
其中 1~15的编码时间和空间效率都是最高的,编码值越大,其编码的时间和空间效率就越低(相对于1-15),当然一般情况下相邻的2个值编码效率的是相同的,除非2个值恰好实在4字节,12字节,20字节等的临界区。比如15和16
1900~2000编码值为Google protobuf 系统内部保留值,建议不要在自己的项目中使用。protobuf 还建议把经常要传递的值把其字段编码设置为1-15之间的值
完整的消息定义示例
message CSSendLiveRoomMsgReq
{
required string room_id = 1; // 直播间id
required uint32 local_msgid = 2; // 发送客户端本地的消息id,用以处理回执消息
required ImMsgBody im_message_body = 3; // 消息内容
optional string from_username = 4;
optional uint32 priority = 5; // 消息优先级别
}
枚举的定义和Java 相同,使用enum
关键字,但是有一些限制。
枚举值必须大于等于0的整数。
使用分号;
分隔枚举变量而不是Java 语言中的逗号,
示例:
enum ACCOUNT_TYPE
{
ACCOUNT_TYPE_IM_ACCOUNT = 1;
ACCOUNT_TYPE_VIVO_OPENID = 2;
ACCOUNT_TYPE_ANONYMOUS_ACCOUNT = 3;
}
你可以将其他消息类型用作字段类型。已我们现在IM的为例,在每一个CSSendLiveRoomMsgReq消息中包含ImMsgBody消息,此时可以在相同的.proto文件中定义一个ImMsgBody消息类型,然后在CSSendLiveRoomMsgReq消息中指定一个ImMsgBody类型的字段
示例:
// 直播间消息下发
message CSNotifyLiveRoomMsg
{
required string room_id = 1; // 直播间id
required uint64 msg_id = 2; //消息ID
required uint64 timestamp = 3; //消息生成的时间戳
required ImMsgBody im_message_body = 4;
optional string from_username = 5;
}
message ImMsgBody
{
required int32 message_type = 1;
optional uint32 message_flag = 2; //消息标志位,留待后续试用,可以用来做一些特殊处理的标志,比如要不要做离线缓存等
oneof real_message
{
ImTextMessage text_message = 3;
ImVoiceMessage voice_message = 4;
ImAppMessage app_message = 5;
ImImageMessage image_message = 6;
ImVideoMessage video_message = 7;
ImFileMessage file_message = 8;
ImLocateMessage locate_message = 9;
ImH5Message h5_message = 10;
}
}
如果你的消息中有很多可选字段, 并且同时至多一个字段会被设置, 你可以加强这个行为,使用oneof特性节省内存,Oneof字段就像可选字段, 除了它们会共享内存, 至多一个字段会被设置。 设置其中一个字段会清除其它字段。
为了在.proto定义Oneof字段, 你需要在名字前面加上oneof关键字, 比如下面例子的ImMsgBody:
message ImMsgBody
{
required int32 message_type = 1;
optional uint32 message_flag = 2;
oneof real_message
{
ImTextMessage text_message = 3;
ImVoiceMessage voice_message = 4;
ImAppMessage app_message = 5;
ImImageMessage image_message = 6;
ImVideoMessage video_message = 7;
ImFileMessage file_message = 8;
ImLocateMessage locate_message = 9;
ImH5Message h5_message = 10;
}
}
oneof的特性
作者:Fizzzzer
链接:https://www.jianshu.com/p/1787d0a64fae
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。