百度
背景：目前项目在打渠道包的时候，采用的是AndroidManifest.xml配置渠道号，上线前一个个构建出来，全部构建完成耗时长达一个小时，这对于追求高效的工程师来讲是无法忍受的。当前有很多公司开源了多渠道打包的方案，如美团的walle，腾讯的VasDolly，还有技术达人个人研究的packer-ng-plugin，今天就来探索下多渠道打包的奥秘。
在了解多渠道打包之前，需要先了解下android的签名方式，这样才能知己知彼百战不殆！
APK签名方案
Android支持两种应用签名方案，一种是基于JAR签名的方案（v1方案），另一种是AndroidNougat(Android7.0)中引入的APK签名方案v2（v2方案）。
为了最大限度地提高兼容性，应同时采用v1和v2这两种方案对应用进行签名。与只通过v1方案签名的应用相比，通过v2方案签名的应用能够更快速地安装到AndroidNougat及更高版本的设备上。更低版本的Android平台会忽略v2签名，这就需要应用包含v1签名。
JAR签名（v1方案）
从一开始，APK签名就是Android的一个有机部分。该方案基于签名的JAR。
v1签名不保护APK的某些部分，例如ZIP元数据。APK验证程序需要处理大量不可信（尚未经过验证）的数据结构，然后会舍弃不受签名保护的数据。这会导致相当大的受攻击面。此外，APK验证程序必须解压所有已压缩的条目，而这需要花费更多时间和内存。为了解决这些问题，Android7.0中引入了APK签名方案v2。
APK签名方案v2（v2方案）
Android7.0中引入了APK签名方案v2（v2方案）。该方案会对APK的内容进行哈希处理和签名，然后将生成的“APK签名分块”插入到APK中。
多渠道打包方案
Gradle插件模式
在AndroidManifest.xml中添加渠道信息：
meta-dataandroid:name="UMENG_CHANNEL"android:value="{UMENG_CHANNEL_VALUE}"/meta-data
2.通过GradlePlugin提供的productFlavors标签，添加渠道信息：
productFlavors.all{flavor-flavor.manifestPlaceholders=[UMENG_CHANNEL_VALUE:name]}flavorDimensionschannelproductFlavors{"yingyongbao"{dimension"channel"}"_"{dimension}
Gradle编译生成多渠道包时，会用不同的渠道信息替换AndroidManifest.xml中的占位符。在代码中，也就可以直接读取AndroidManifest.xml中的渠道信息了。
ApplicationInfoappInfo=context.getPackageManager().getApplicationInfo(context.getPackageName(),PackageManager.GET_META_DATA);intchannelId=appInfo.metaData.getInt();
当前方案存在的问题，在开头也说了，现在总结一下（引用VasDolly原文）
1.每生成一个渠道包，都要重新执行一遍构建流程，效率太低，浪费时间，不太适合多渠道包的场景。
2.Gradle会为每个渠道包生成一个不同的BuildConfig.java类，记录渠道信息，导致每个渠道包的DEX的CRC值都不同。一般情况下，这是没有影响的。但是如果你使用了
