前言
我们app经常有这样的需求,就是app经常需要投放到不同渠道。这就需要我们给每个app包中添加一些渠道信息,用数据分析统计、业务功能需求等等。
传统打入渠道信息的弊端
有几种打渠道包信息的方法,如
利用 Android Studio 自带 productFlavors 方式,配合第三方平台打包,自动打出一堆渠道包。
解压拆包,放入渠道信息。
这几种打包方式都有一个共同缺点,重签名,这样在每个渠道打包生成的效率上大打折扣。想象下如果遇到即时的生成,下载包这样的业务场景,肯定是实现不了的。
秒速打出渠道包
由于项目业务原因,事实上我们需要打的渠道包的量是非常大的,几百上千都有,且这些渠道包可能需要即时生成下载。那上面的打包方式明显满足不了我们的需求。
V1 签名方式打包
这种方式明显契合需求,有什么优势
快速打包,只做在包尾写入渠道信息操作。
不需要重签名。
我们的秒速读取渠道信息就是由V1签名方式实现的,因此需要在文件禁用V2签名方式
写入渠道信息
写入渠道信息具体步骤如下:
复制
找到数据块
添加渠道信息
添加渠道信息长度
添加魔数
下面以代码为例
这里说明下,里面是反序列化输入,写入的字节是反过来的。
由于我的apk包本身没有注释,的长度是字节
读取渠道信息
实际就是在 Apk 文件的注释字段里,添加我们自己的渠道信息,绕过了重签名。读取步骤如下
定位到魔数
向前读两个字节,并确定渠道信息长度 len
继续向前读 len 个字节,读取len 长度信息,就是渠道信息了
这样就完成了读取渠道信息
具体生成渠道信息包的后apk尾部信息
大家可以下载个16进制查看器,查看包尾信息
这里提供个分享链接给大家下载,windows系统的 exe 文件。https://pan.baidu.com/s/1RzV5F-wtzl9SqO4AjAoUFg
最后4个字节是我们自己定义的魔数。
这种打包方式的一些缺点。
首先这是基于 V1 打包方式的,并不支持 V2.
使用这种方式打包,在 apk 安装耗时相比优化过更严格的 V2 打包方式 2倍以上
但我们app 非常小, 所以这些缺点并不明显。所以我们采用了这种相对简单,快速的打包方式。
其实我们需要做的是,根据自己实际项目需求,找到合适的渠道打包方式,这是我要给大家的思考。
最后
以上就是我们项目实际运用的生成渠道信息的方式。
我发现前人早已造好了轮子了, 并且支持 V1 和 V2 打包方式,有兴趣可以去看下,有3000+ star,https://github.com/mcxiaoke/packer-ng-plugin
关于作者
领取专属 10元无门槛券
私享最新 技术干货