v2打包+walle多渠道+加固+tinker热更新的实践过程

v2打包+walle多渠道+加固+tinker热更新的实践过程

基于公司的多渠道需求，整合tinker热更新和360加固

由于公司的应用要发布到各个应用市场（大概有二十个左右），如果一个个打包的话，是一个巨大的工作量；特别是打完包之后发现有一个测试toast忘记注释掉了。。。

多渠道打包的方式我看了一些，最终选择了walle，说下他的好处：

1：好管理（只需要在配置文件中配置上渠道就行）；
2：操作简单（只需要依赖walle的插件即可）；
3：打包速度快；

具体的walle说明请进入walle。

v2打包是android7.0引入的新的打包方式，优点是apk速度快，更安全，而walle打包是基于v2打包的：只有v2打的apk才可以使用walle进行多渠道分发。

去年热更新技术比较火，阿里美团腾讯都有各自的热更新技术，最终我们选择的微信的热更新方案tinker。
我是采用的bugly集成的tinker服务，bugly热更新官网文档
抠一张图说明下：

先说下之前的发包方式：由于应用需要加固，我们选用的360加固的方式，刚开始360加固和tinker冲突，使用了360加固之后，无法合并补丁包，这个问题bugly已经做了支持，在tinker配置中设置：

// 是否使用加固模式，默认为false
     isProtectedApp = true

整体流程：使用walle命令在gradle中打基准包和多渠道包：在Terminal中：

./gradlew clean assembleReleaseChannels

渠道包生成之后会按照你的配置的路径输出，我的在/outputs/channels中，同时，tinker的基准包也已经生成，tinker基准包生成地址在tinker配置文件中配置，我的在${buildDir}/bakApk/。然后对这些生成的渠道包进行加固、重新签名，最后发布市场。这个流程使用测试环境测过好几次，可以修复所有渠道的包。

结果两天后数据分析的人员找过来了，为什么统计数据android所有的渠道都是空，，，mdzz，这是又踩坑了吗，又过了一遍流程：
多渠道包没问题，加固前获取渠道的方法还好用，加固后失效了，看来是加固的问题。

查了下资料，360加固后的重新签名会破坏掉渠道信息，那就只加固不签名，加固所有渠道包之后，对所有的加固后的apk进行命令签名。
这一套流程也太麻烦了，而且时间也相当长，对二十个apk进行加固太耗时间了，只能写脚本串联上所有的操作了

先理一下需求：

1：首先要有tinker的基准包；
2：加固只需要加固这一个基准包apk就行，之后针对加固后的包做签名+渠道；
3：能把所有的流程整合起来，通过一个批处理来处理；

思路理清了，就开始走流程了：

1：在android studio中还是使用tinker的生成基准包的方式生成一个基准包
2：对此基准包进行加固，可以使用360加固包的客户端，但是不要勾选签名选项，只加固不签名；
3：对此已经加固但是没有签名的apk进行处理，结果是生成已经签名的多渠道包。

其中1，2步骤只能手动操作，3步骤可以生成一个脚本文件：

此脚本文件中先对加固后apk进行检查、优化、签名，然后联合walle命令生成多渠道包，
下面是已经做好的window的脚本：

其中：
1：可编辑渠道：改成自己要发布的渠道
2：可编辑配置：签名信息，改成自己的签名信息
3：签名文件：换成自己的签名文件
将上述三个文件更改为自己的需要的就可以了，其他不用动。
使用方式：
将自己的已经加固（未签名）之后的包拖到上面那两个exe文件之一就行，
两个文件的区别就是：一个有打包步骤展示，需要按键继续，
一个是直接运行到最后打出渠道包出来。用哪个都行。

脚本下载地址：[https://github.com/zhoubo07/mytools]
(https://github.com/zhoubo07/mytools)