Android学习之模块化过程多渠道编译详解

本文和大家分享的主要是android开发中，模块化多渠道编译相关内容，一起来看看吧，希望对大家有所帮助。

　　有赞微商城APP小组在搞模块化过程中需要把POS机相关的业务全部抽离出来，但是POS机的适配代码会散落在多个业务module 中，这才让我接触到了模块化过程中真正的多渠道编译。

　　闲话少说，开始步入正题，把解决方案分享给大家，希望小伙伴能少走弯路。

　　那么什么时候小伙伴会遇到我所遇到的问题呢？

　　1. 你的项目在模块化，业务代码抽到了独立的library中

　　2. 你的library代码中需要通过 BuildConfig.FLAVOR 区分业务，例如：

　　if (BuildConfig.FLAVOR.equals("weipos")) {

　　// weipos related source

　　} else {

　　//

　　}

　　3.

　　首先，我先把目前的解决方案放出来。

　　目前项目中，我们有很多渠道，这里主要关注一下项目中接入的POS机渠道 - iboxpay、sunmi、weipos，在我们的业务代码中，需要根据不同的flavor去区分实现不同的功能。

　　在主工程的 build.gradle 文件中，我们定义了如下几种flavor：

　　productFlavors {

　　def customFlavors = getCustomFlavors()

　　if (customFlavors instanceof List) {

　　customFlavors.each {

　　flavor ->

　　"$flavor"{

　　}

　　}

　　}

　　full {

　　buildConfigField"boolean","POS","false"

　　buildConfigField"String","DEVICE_TYPE","\"android\""

　　}

　　iboxpay {

　　buildConfigField"boolean","POS","true"

　　buildConfigField"String","DEVICE_TYPE","\"android-iboxpay\""

　　}

　　sunmi {

　　buildConfigField"boolean","POS","true"

　　buildConfigField"String","DEVICE_TYPE","\"android-sunmi\""

　　}

　　weipos {

　　buildConfigField"boolean","POS","true"

　　buildConfigField"String","DEVICE_TYPE","\"android-weipos\""

　　}

　　}

　　为了区分POS机业务和普通业务，需要在编译时根据具体的 task name 去区分，例如task是 assembleSumiDebug ，则groupPosPrefix 的值是Sunmi，buildTypePrefix 的值是Debug, 只要groupPosPrefix 的值是我定义的flavor里的Iboxpay,Sunmi,Weipos,那么groupPos的值就是”pos”，否则就是空字符串。

　　注意：这里要注意大小写的问题，Sunmi不能用sunmi去替代。

　　// global variables

　　ext{

　　buildType = ""

　　groupPos=""

　　}

　　//start parametersprintln "Start parameters:tasks=" + gradle.startParameter.getTaskNames();

　　gradle.startParameter.getTaskNames().each { task->

　　def taskParts = splitCamelCase(task.split(":").last());

　　def groupPosPrefix = taskParts[taskParts.size() - 2];

　　def buildTypePrefix = taskParts[taskParts.size() - 1];

　　if ("Debug".startsWith(buildTypePrefix)) {

　　buildType = 'debug';

　　} else if ("Release".startsWith(buildTypePrefix)) {

　　buildType = 'release';

　　} else {

　　return; // do not process tasks that are not ending with proper build type.

　　}

　　if ("Iboxpay".startsWith(groupPosPrefix)) {

　　groupPos = 'pos';

　　} else if ("Sunmi".startsWith(groupPosPrefix)) {

　　groupPos = 'pos';

　　} else if ("Weipos".startsWith(groupPosPrefix)) {

　　groupPos = "pos"

　　} else {

　　groupPos = ""

　　}

　　}

　　def splitCamelCase(String word) {

　　def result = []

　　int nextStart = 0;

　　for (int i = 1; i < word.length(); i++) {

　　if(word.charAt(i).isUpperCase()) {

　　result.add(word.substring(nextStart, i));

　　nextStart = i;

　　}

　　}

　　result.add(word.substring(nextStart));

　　return result;

　　}

　　dependencies {

　　if (groupPos =="pos") {

　　iboxpayCompile project(':pos_iboxpay')

　　iboxpayCompile project(path:':wsc_goods',configuration:'iboxpayRelease')

　　sunmiCompile project(':pos_sunmi')

　　sunmiCompile project(path:':wsc_goods',configuration:'sunmiRelease')

　　weiposCompile project(':pos_wei')

　　weiposCompile project(path:':wsc_goods',configuration:'weiposRelease')

　　} else {

　　compile project(path:':wsc_goods',configuration:'fullRelease')

　　}

　　这样通过 groupPos 这个变量，就能很自由的去控制普通业务和POS业务跟其他module的依赖关系，很容易实现普通业务和POS机业务在编译上的分离。

　　举个栗子

　　这个例子是商品module，在这个library中，它的build.gradle里也需要定义跟app的gradle中一样的ProductFlavor：

　　productFlavors {

　　full {

　　buildConfigField"boolean","POS","false"

　　buildConfigField"String","DEVICE_TYPE","\"android\""

　　}

　　iboxpay {

　　buildConfigField"boolean","POS","true"

　　buildConfigField"String","DEVICE_TYPE","\"android-iboxpay\""

　　}

　　sunmi {

　　buildConfigField"boolean","POS","true"

　　buildConfigField"String","DEVICE_TYPE","\"android-sunmi\""

　　}

　　weipos {

　　buildConfigField"boolean","POS","true"

　　buildConfigField"String","DEVICE_TYPE","\"android-weipos\""

　　}

　　}

　　写完这些flavor了，不要忘记加上 publishNonDefault true 这么一句话哦，否则会找不到对应的configuration。

　　android {

　　publicNonDefault true

　　}

　　可能有小伙伴问我为什么没有customFlavor了，这里说明一下：baidu，wandoujia等自定义的渠道使用的业务代码跟full这个flavor是一样的，所以不需要再次在module的build.gradle里去定义了。

　　当app的build.gradle和商品library的build.gradle都配置如上的时候，在terminal里执行./gradlew assembleDebug,就能顺利的打包出full、sunmi、iboxpay、weipos这四个渠道的apk。

　　总结

　　整个解决方案到此算是讲解完了，这里放几个小知识点：

　　如何知道自己的项目中有哪些task？

　　在AS中打开terminal，输入./gradlew tasks，build成功后会打印出所有的task

　　Build Variant 是什么？

　　· Build Type + Product Flavor = Build Variant

　　· flavor 是sunmi,build type是debug ，则build variant是sunmiDebug

　　当项目中有了flavor后，会有更多的task被创建？

　　yes,

　　如下几种会被创建

　　assemble<Variant Name>

　　assemble<Build Type Name>

　　assemble<Product Flavor Name>

　　library publish 是什么？

　　例如下面的依赖

　　dependencies {

　　flavor1Compile project(path: ':lib1', configuration: 'flavor1Release')

　　}

在编译 lib1 的时候，默认打包 flavor1Release 版本

 

来源：简书