首页 > 代码库 > 普通的多渠道打包方案
普通的多渠道打包方案
Android Gradle Plugin
Gradle Plugin本身提供了多渠道的打包策略:
首先,在AndroidManifest.xml中添加渠道信息占位符:
<meta-data android:name="InstallChannel" android:value=http://www.mamicode.com/"${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文件是完全一致的,不然就会合成失败)
普通的多渠道打包方案
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。