标签：通过 ring 基础 存在 png 打包 span man images
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中的渠道信息了。
这样会打包时会生成多个渠道的安装包，
但是，这种方式存在一些缺点：
每生成一个渠道包，都要重新执行一遍构建流程，效率太低，只适用于渠道较少的场景。
Gradle会为每个渠道包生成一个不同的BuildConfig.java类，记录渠道信息，导致每个渠道包的DEX的CRC值都不同。一般情况下，这是没有影响的。但是如果你使用了微信的Tinker热补丁方案，那么就需要为不同的渠道包打不同的补丁，这完全是不可以接受的。（因为Tinker是通过对比基础包APK和新包APK生成差分补丁，然后再把补丁和基础包APK一起合成新包APK。这就要求用于生成差分补丁的基础包DEX和用于合成新包的基础包DEX是完全一致的，即：每一个基础渠道包的DEX文件是完全一致的，不然就会合成失败）
标签：通过 ring 基础 存在 png 打包 span man images
原文地址：http://www.cnblogs.com/snowalwaysboy/p/6924167.html
