protocol buffer 字段过滤

客户端因视频信息结构过大导致数据包过重,选择让服务器根据客户端需求动态填充Protocol Buffer(PB)字段。讨论了两种解决方案:switch-case判断和反射填充。最终通过直接在编码层面过滤不需要的字段实现优化,保持协议兼容性并减少改动。测试了PB编码过滤的可行性。
摘要由CSDN通过智能技术生成

这几天遇到一个问题,客户端从服务器拉取一批视频信息,C/S之间使用protocol buffer格式协议,但是由于视频信息结构太大,有好几十个字段(包含字符串、repeated、嵌套……,后台为了对外部提供一个通用的接口,就填上了所有这些字段),导致客户端拉下去的包过大,8个原始视频信息就有6k+, 客户端测试压缩过后还有3k+, 考虑到app流量和接入层对包大小限制,并且客户端实际需要的字段只有少部分,在考虑和给app提供一个特有的协议和其他方案之间进行权衡,最后的方案是:由客户端决定需要哪些字段,客户端需要哪些字段,服务器就填上哪些字段返回给客户端。对应到这种方案就讨论出了两种做法:1.写一个大的switch-case,每个字段都判断要不要填;2.采用反射动态填充。第一种方案最简单,也最挫,以后每次需改协议这个接口的代码都要改动,而且需要关心协议内容;第二种方法通用,开发量大,以后每次协议改动只需要重新加载一次协议文件就可以了。

之前了解过pb的编解码原理,其实比较简单,当时就想到了可不可以直接从编码下手,服务器不需要关心协议变动,也不用实现反射等。具体方法是:还是设置协议中的所有的字段、序列化(pb编码),然后将序列化后的内容过滤,去掉那些不需要的字段对应的内容,只把那些需要的字段对应的二进制内容抠出来再拼接起来,即可。可行的原因是pb的编码方式比较简单(编解码参考protocol buffer 编解码),而且都是兼容老版本的。然后自己很快写了个demo,测试ok。

测试中使用的pb文件内容如下:

package test_protos;


message

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值