Protocol buffer序列化及其在微信蓝牙协议中的应用

最后更新于:2022-04-01 06:57:59

 Protocol buffer是Google出品的一种轻便高效的结构化数据存储格式,可对结构化数据进行序列化,并具有语言无关、平台无关等特点,在通信协议和数据存储等领域已经得到广泛的应用。目前其已经提供 C/C++、Java、Python 等语言的 API。 >一、Protocol buffer和XML 在数据通信传输时,一般需要将结构化的数据序列化成流进行传送,接收方再反序列化为原始格式数据进行处理。在Web通信领域,XML应用算是最通用的了。在时间性能上,虽然XML的序列化开销还可以,但是反序列化的效率是比较差,而Protocol buffer的反序列化效率是比较高的;在空间性能上,Protobuffer采用了可变长的数据编码格式,比XML的字符格式要高效得多。Google集群要处理PB级数据,Protocolbuffer能够在时间和空间性能上有所改进,在整体效益而言就是相当可观的。 正是基于以上原因,微信和蓝牙外设的通信协议采用了Protocol buffer对消息包体进行打包。本文的目标是讲述Protobuffer在蓝牙微信协议中的应用,有助于理解微信蓝牙协议,对微信发给蓝牙外设的消息数据流进行反序列化,得到原始的结构化格式数据。因此语法也是围绕微信蓝牙协议包展开。更加详细的语法请百度相关内容或者找笔者探讨。 >二、微信蓝牙外设协议通用格式 微信蓝牙使用流进行传输,在流上传输的是一个接着一个的业务逻辑的数据包。把设备发往厂商服务器或者微信服务器的请求包称为Req,回复包称为Resp,一个请求对应一个回包。把厂商服务器或者微信服务器主动发往设备的请求包称为PushReq。 包结构由定长包头和变长包体组成,其中包体即由Protocol buffer进行打包。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a158246.jpg) 其中,定长包头为8个字节,bMagicNumber为0xFE;bVer为版本01;nLength为包长,包括包头和包体的长度;nCmdId为命令编码,如登陆授权,初始化,发送数据,push推送等等;nSeq为序列号,PushReq包的序列号固定为0,其他请求和回复包的序列号务必保持一致,每次请求后序列号加1. 以厂商服务器主动发数据给设备的PushReq包为例来说明变长包体,其对应定长包头的nCmdId为ECI_push_recvData = 30001。包体包括以下三个部分: 1) Push包标识 2) 自定义数据,指的是业务层自己定义的数据格式形成的数据。 3)  数据类型,如厂商自定义的数据,还是微信客户端Html5的数据等 >三、Protobuffer的语法表述 Protobuffer对push_recvData包的表述如下: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a1700db.jpg) Message类似C语言的struct数据结构,是Protobuffer消息定义的关键字。RecvDataPush是消息的名称。 Required前缀表示该字段必须在序列化之前赋值,optional前缀表示可以不赋值。 BasePush BasePush是message的第一个字段field,前者代表数据类型,后者是名称,其中BashPush在协议中是这样定义的: Message BashPush{} 其意味着里面没有数据项,BashPush在打包过程中只会出现数据类型,其实也是代表着一种push标识。 Bytes Data是第二个字段field,为字符串,名称是Data。 EmDeviceDataType type是第三个字段field,为设备数据类型,其中EmDeviceDataType是一个enum类型,如下: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a18437b.jpg) 1,2,3代表字段在序列化后布局中的位置index,第一个位置是BashPush,接着是Data、type。 >四、Protobuffer打包 Protobuffer打包有以下要素和规则: 1.使用Varints算法表示数字。Varints是一种紧凑表示数字的方法。Varints中每一个字节的最高位是有特殊含义的,如果是1,则表示后续的字节也是该数字的一部分;如果是0,则结束。所以如果表示小于128的数值可以用一个字节,如果大于等于128的数字则要用更多的字节进行表示。 2\. Protobuffer有以下数据类型 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a1944ef.jpg) Type表示对应数据类型序号,其中Varint对应的数据类型包括int32,int64,enum等等,type序号为0,其都使用Varints进行表示。String,bytes,message类型对应的type序号为2. 3\. Protobuffer打包即是将message通过一系列的key-value对来表示。而key就是每个message中各字段的index(并做一定运算),value根据类型的不同会有不同的表现形式。 其中key = field 而value,在数据类型为Varint时,直接为字段的赋值,按照Varints算法进行编码;在其他类型时就是“长度+原始内容编码”。 >五、PushReq包分析 我们通过微信提供的AirSyncDebugger2.1.0.apk来分析Protobuffer对数据包的序列化。该APP用于微信和蓝牙外设的通信调试,其封装了微信蓝牙的协议,一般先用该APP调通蓝牙协议,再和后台服务器联调。假设我们自定义的消息内容为fe cf 00 01 00 0c 20 01 00 00 00 00,即对应第二个字段bytesData,该消息内容是上一篇文章中服务器控制亮灯所发的消息,后台服务器和蓝牙外设的消息协议是自定义的。AirSyncDebugger对PushReq包的序列化如下: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a1a46da.jpg) 序列化过程分析如下: 固定包头(不受Protobuffer控制): Magic : fe Version: 01 Length : 00 1A,即包体和包体的总长度为26字节。 Cmdid : 75 31,十进制就是30001,即ECI_push_recvData包 Seq : 00 00 push包的序列号都是00 00 变长包体(Protobuffer控制打包,十六进表示): 0A: BasePush的field是1, 值类型message的序号type为2,所以是0x1 00 : 即值长度为0,BasePush值为空,其实就是一种标识。 12:data的field是2,值类型bytes的序号为2,所以是0x2 0C:  data的长度是12 Fe cf 00 01 00 0c20 03 00 00 00 00 : data的内容,即我们自定义的消息。 18: Type的field是3,值类型enum的序号为0,所以是0x3 00:Type的值,因为enum属于Varint的一种,所以不需要长度,直接用值表示,0代表厂商自定义数据。 >六、基于微信硬件公众平台的智能控制方案开发专栏介绍        接下来嵌入式企鹅圈会将陆续公开基于微信硬件公众平台的智能控制开发技术细节,大致内容包括: 1\. 物联网架构和场景分析(已发) 2\. 基于微信硬件公众平台的智能控制开发流程(已发) 3\. 云服务器搭建和公众号配置 4\. 公众号菜单设置 5\. 微信消息传递过程和微信设备接入接口协议 6\. 微信硬件平台后台服务开发 7\. 微信蓝牙协议和授权、绑定过程 8.Protocol buffer序列化及其在微信蓝牙协议中的应用(已发) 9\. 蓝牙外设控制开发 …   谢谢支持嵌入式企鹅圈: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a0d9e17.jpg)
';