关于android多渠道打包的总结

公司有40个渠道包的需要，我用了一台主机专门打包，最快也要40分钟才能打完，一般都是50分钟，当在发布前发现问题的时候，重新打包导致开发人员噩梦开始，并且推广人员跟着加班，效率很低。

1、gradle参数提速
org.gradle.daemon=true 开启daemon守护进程
gradle assembleDebug –dry-run –no-daemon 11.374 secs
gradle assembleDebug –dry-run –daemon 2.565 secs

org.gradle.parallel=true 并行化编译，模块化项目提升比较多

2、将不常改动的类封装成稳定的底层类，甚至可以建公司的maven仓库等；
jar或者aar
结果：可以抽取的类不多，提速的效果不是很明显 。

3、减少方法数，将方法数降到65535，不使用multidex，可以提升编译速度，也可以提高app启动速度

目前必须引入的第三方类库加起来已经超过65535，目前v3.22.0的方法数是91001，远超65535，实现难度比较大

4、剔除不需要和重复的库
使用gradle :app:dependencies –configuration compile可以分析出该项目的所有第三方包的依赖，
使用 debugCompile和exclude来减少不需要和重复的库
compile(‘com.android.support:support-fragment:25.3.1’) {
exclude group: ‘com.android.support’, module: ‘support-media-compat’
exclude group: ‘com.android.support’, module: ‘support-annotations’
}

5、开发阶段将minSdk设置为21，发布或者调试兼容性的时候将minSdk设置回14
minSdk 14 ———— 1m16s
minSdk 21 ———— 24s

风险：设置后IDE会认为项目默认是支持最低21，导致一些兼容性友好的提示消失了，开发完必须要做低版本的测试。

6、去掉lint步骤
tasks.whenTaskAdded { task ->
if (task.name.equals(“lint”) || (task.name.contains(“lintVital”) && task.name.contains(“Release”))) {
task.enabled = false
}
}

在考拉项目里省去了5*n秒的lint时间(n为Flavors数量)

7、采用可商用的多渠道打包方案
VasDolly 腾讯
Walle 美团 （考拉接入）

原理都差不多，都是找到不被app签名校验的地方（某个文件空间，某个文件），用来记录一些信息，而不破坏之前app的签名，不能重新打包，所以，可以认为这部分信息是不需要被保护的，比如渠道标识。

旧打包方式是采用productFlavors，每打一个渠道包都要重新编译一次，简单计算时间
n * t (60s < t < 90s, n为渠道包数量)

walle采用的是在打包完成后加渠道，简单计算就是打包一个apk的时间，
t + n * t1 (60s < t < 90s, 0s < t1 < 0.2s, n为渠道包数量)
特点：需求是所有的渠道包除了“渠道”这种标识性信息外，其他的信息都必须一致，比如app名字都必须一致。

采用Walle需要解决的问题
1)、解决个性apk名字的问题
区分普通渠道包和定制渠道包，定义n个productFlavors，一个叫genenal，其他的是渠道名，比如oppo等，时间变成
t * m + n * t1 (60s < t < 90s, 0s < t1 < 0.2s, n为渠道包数量，m为需要定制的渠道包数量+1)
2)、360应用宝加固channel失效的问题
先加固再重新使用walle加渠道标识

walle与jenkins结合
release流程：（发包）
->打包（productFlavors）
->walle写入渠道
->360加固，应用宝加固（应用宝加固需要手动）
->360，应用宝walle写入渠道
->渠道包上传七牛
->把渠道包和mapping文件传到共享盘

整个过程大约需要15分钟

debug 流程 ：（给内部人员提供测试版本下载）
-> 打包
->上传蒲公英
->展示二维码

整个过程大约需要4分钟