此文属于finddreams的原创博客,转载请注明出处:http://blog.csdn.net/finddreams/article/details/78773687
由于Android应用市场的多样性,运营人员为了统计App在各应用市场的下载量,通常会要求Android的APP包要能够根据不同的应用市场打出对应的带这个渠道的apk,这就成了Android团队打包发布的任务之一——打渠道包。
记得一年以前,我们项目中的打包方式是使用Gradle中的productFlavors配置来打渠道包,配置不同渠道的flavors信息
productFlavors {
xiaomi {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "xiaomi"]
}
_360 {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "360"]
}
test {
packageName "com.example.test"
}
然后通过不同的flavor配置来动态的替换掉AndroidManifest.xml中预定义的参数UMENG_CHANNEL_VALUE,来实现友盟的多渠道统计功能。
<meta-data
android:name="UMENG_CHANNEL"
android:value="${UMENG_CHANNEL_VALUE}"/>
使用 productFlavors 来实现多渠道的方式的
优点是可以定制不同的风格,比如不同包名,版本号,不同的appname,不同的ic_launcher等,可以打出两个不同环境的apk安装到手机上。
缺点就是如果只是用在打渠道包这个功能上,那就是牛刀杀鸡大材小用了,因为每打出一个渠道包就要重新的编译运行一遍,如果是一两个到无所谓,到要是十个以上就有罪可受了。
当时我们的apk大小是十几兆,用这种方式打五个渠道包,要花上半个小时以上的时间,真心的低效,不够优雅。
另外使用productFlavors来打包出渠道apk,使用Tinker这种热修复框架也不友好,因为productFlavors打出来的apk其实已经是两个不同的apk了,发布补丁的时候,可以会出现不同的结果,所以这种方式也不是微信Tinker 官方