1.第一种是 Android Gradle Plugin
Gradle plugin本身提供了多渠道的打包策略
首先在AndroidManifest.xml中添加渠道信息占位符：
<meta-data android:name=“InstallChannel’ android:value=“${InstallChannel}” />
然后，通过Gradle Plugin 提供的productFlavors标签，添加渠道信息：
productFlavors {
“YingYongBao”{ manifestPlaceholders = [InstallChannel : “YingYongBao”] }
“360” { manifestPlaceholders = [ InstallChannel : “360”]
}
}
这样，Gradle编译生成多渠道包时，会用不同的渠道信息替换AndroidManifest.xml 中占位符。
我们在代码中，也就可以直接读取AndroidManifest.xml中的渠道信息了。
但是，这种方式存在一些缺点：
1.每生成一个渠道包，都要重新执行一遍构建流程，效率太低，只适用于渠道比较少的场景。
2.Gradle会为每个渠道包生成一个不同的BiuldConfig.java 类，记录渠道信息，导致每个渠道包的DEX的CRC值都不同。一般情况下，这是没有影响的。但是如果你使用了微信的Tinker热补丁方案，那么久需要为不同的渠道包打不同的补丁，这完全是不可以接受的。（因为TInker是通过对比基础包APK和新包APK生成差分补丁，然后再把补丁和基础包APK一起合成新包APK。这就要求用于生成差分补丁的基础包DEX和用于合成新包的基础包Dex是完全一致的，即：每一个基础渠道包的Dex文件是完全一致的，不然就会合成失败。）
2.ApkTool
ApkTool是一个逆向分析工具，可以把APK解开，添加代码后，重新打包成APK。因此，基于ApkTool的多渠道打包方案分为以下几步：
- 复制一份新的APK
- 通过ApkTool工具，解压APK（apktool d origin.apk）
- 删除已有签名信息
- 添加渠道信息（可以在APK的任何文件添加渠道信息）
- 通过ApkTool工具，重新打包生成新APK（apktool b newApkDir）
- 重新签名
经过测试，这种方案完全是可行的。
优点：
不需要重新构建新渠道包，仅需要复制修改就可以了。并且因为是重新签名，所以同时支持V1和V2签名。
缺点： - ApkTool工具不稳定，曾经遇到过升级Gradle Plugin版本后，低版本ApkTool解压APK失败的情况。
- 生成新渠道包时，需要重新解包、打包和签名，而这几步操作又是相对比较耗时的。经过测试：生成企鹅电竞10个渠道包需要16分钟左右，虽然比Gradle Plugin方案减少很多耗时。但是若需要同时生成上百个渠道包，则需要几个小时，显然不适合渠道非常多的业务场景。
