龙空技术网

Android 模块化过程中的多渠道编译

鸿蒙之始 144

前言:

现在我们对“apachecamelsplit”大体比较关怀,同学们都需要分析一些“apachecamelsplit”的相关内容。那么小编在网上收集了一些关于“apachecamelsplit””的相关资讯,希望各位老铁们能喜欢,朋友们一起来了解一下吧!

你的项目在模块化,业务代码抽到了独立的library中你的library代码中需要通过BuildConfig.FLAVOR区分业务,例如: if (BuildConfig.FLAVOR.equals("weipos")) { // weipos related source } else { // }

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

目前项目中,我们有很多渠道,这里主要关注一下项目中接入的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 variablesext{    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 Variantflavor 是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 版本

标签: #apachecamelsplit