在Android开发过程中，通常会有开发版、测试版、正式版，可能还会有灰度版、预上线版等，这里将灰度版、预上线版等都归类到正式版中，此为多版本；由于国内拥有庞大的Android APP Store，正式版还会分为不同渠道版本，例如360、华为、百度、应用宝、Vivo、小米等，此为多渠道。
多版本多渠道，不同版本API接口的Host会有不同、配置参数会有不同（例如使用极光推送就会涉及不同包名、不同AppKey）、会有不同的渠道号，为了满足这些需求，就需要配置不同参数来进行多版本多渠道打包，这里打包就使用最常用的Android Studio中自带的Gradle 3.5.3插件。
多版本
这里将多版本分为开发版（dev）、测试版(debug)、正式版(release)，不同的版本对应不同的API Host、不同的配置参数、甚至不同的applicationId等，这里以使用极光推送举例，极光推送要求不同的版本必须对应不同的applicationId，所以就需要在各版本中配置不同的applicationId，app.gradle中buildTypes加入release、debug、dev对应正式版、测试版、开发版，下面先展示Gradle配置，根据配置来说明。
buildTypes {
release {
minifyEnabled true
//是否zip对齐
zipAlignEnabled true
// 缩减resource文件
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
manifestPlaceholders = [
JPUSH_PKGNAME: defaultConfig.applicationId,
JPUSH_APPKEY : "xxx",
APP_NAME : "@string/app_name",
]
buildConfigField("String", "HOST", "\"xxx\"")
buildConfigField("int", "PORT", "443")
buildConfigField("String", "SCHEME", "\"https\"")
}
debug {
applicationIdSuffix ".debug"
minifyEnabled false
//是否zip对齐
zipAlignEnabled false
// 缩减resource文件
shrinkResources false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.debug
manifestPlaceholders = [
JPUSH_PKGNAME: defaultConfig.applicationId + applicationIdSuffix,
JPUSH_APPKEY : "xxx",
APP_NAME : "@string/app_name_debug",
]
buildConfigField("String", "HOST", "\"xxx\"")
buildConfigField("int", "PORT", "443")
buildConfigField("String", "SCHEME", "\"https\"")
}
dev {
applicationIdSuffix ".debug"
minifyEnabled false
//是否zip对齐
zipAlignEnabled false
// 缩减resource文件
shrinkResources false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.debug
manifestPlaceholders = [
HOST : rootProject.ext.net.dev.host,
JPUSH_PKGNAME: defaultConfig.applicationId + applicationIdSuffix,
JPUSH_APPKEY : "xxx",
APP_NAME : "@string/app_name_dev",
]
buildConfigField("String", "HOST", "\"xxx\"")
buildConfigField("int", "PORT", "8083")
buildConfigField("String", "SCHEME", "\"http\"")
}
}
参数配置：通常为了加快编译速度等只有release版才会混淆、资源缩减、优化等，所以只有release版中才将minifyEnabled、zipAlignEnabled、shrinkResources设置为true，其他一律设置为false；不同版本可能会有不同的签名，签名参数需要额统一配置，同样设置不同版本对应不同签名，通常开发中不同版本会使用同一个签名。
signingConfigs {
/*正式包*/
release {
storeFile file("${rootDir}/keystore/xxx")
keyAlias = 'xxx'
keyPassword 'xxx'
storePassword 'xxx'
}
/*测试包*/
debug {
storeFile file("${rootDir}/keystore/xxx")
keyAlias = 'xxx'
keyPassword 'xxx'
storePassword 'xxx'
}
/*开发包*/
dev {
storeFile file("${rootDir}/keystore/xxx")
keyAlias = 'xxx'
keyPassword 'xxx'
storePassword 'xxx'
}
}
版本区分：为了区分不同版本需设置不同的APP Name、APP Icon,例如xx、xx测试版、xx开发版，这样将不同版本安装到同一个设备就能很容易区分。【这里先说明一下manifestPlaceholders，manifestPlaceholders是一个占位符，以数组的形式可以定义不同的Key-Value，然后在AndroidManifest.xml中以${Key}形式直接调用，可以将manifestPlaceholders理解为AndroidManifest.xml和xxx.gradle的数据调用接口】。直接在manifestPlaceholders中定义不同的APP_NAME，APP_NAME定义后直接在AndroidManifest.xml中的label引用（如下）,这样不同的版本打包后就会有不同的APP Name，同样其他参数也可这样配置，这里只用APP_NAME举例。
<--xxx-->
ApplicationId区分：在开发中会遇到不同版本需要设置不同的applicationId的情况，例如使用极光推送时就要求一个applicationId对应一个AppKey，在开发中为了区分测试环境和正式环境至少使用两个AppKey，release版使用一个，debug版和dev版使用一个，这样release和debug、dev就必须使用不同的applicationId，那这个怎么设置呢？每打一个包手动更改一个applicationId，作为一个程序员这样做总感觉怪怪的，因为不符合程序员懒的风格呀！Gradle中提供了一种机制来满足这样的需求，那就是xxxxxSuffix，这个是啥意思呢？就是在默认xxx的基础上增加一个字符串作为xxx，例如默认applicationId是"cn.test.app",增加applicationIdSuffix ".debug"编译后就将此版本下的applicationId替换成了"cn.test.app.debug"，轻而易举的更换了applicationId，类似的还有versonName等。
这里要说明一下JPUSH_PKGNAME，JPush SDK使用此值来获取application，所以在非release版本需要这样设置：
manifestPlaceholders = [
JPUSH_PKGNAME: defaultConfig.applicationId + applicationIdSuffix,
]
需要注意的是这里不能直接写成applicationIdSuffix,直接写成applicationIdSuffix applicationId就只是applicationIdSuffix对应的值了(.debug)，而不是整体（cn.test.app.debug）。
Host区分：不知读者之前怎样管理API Host的呢？有人可能这样，定义一个HttpManager，然后在里边定义不同的值来代表不同环境，更换环境时更换current值，这也是一种办法，但是一是得来回换，二是着急时可能弄错，假如上线时不小心更换成debug版的Host，那就是开发事故，所以还是在Gradle中不同版本不同配置，这样打包时选择不同环境就行，再也不怕手一哆嗦弄错了。
接下来分析一下在Gradle中怎样定义，Gradle提供了一个buildConfigField("","","")用来定义变量，编译过后直接就会出现在我们熟悉的BuildConfig中，作为BuildConfig的成员变量，然后就可以直接BuildConfig.xxx调用，沿着“传统”思路，也可以定义一个HttpManager来管理Host，例如：
public class HttpManager {
private static final String SCHEME = BuildConfig.SCHEME;
private static final String HOST = BuildConfig.HOST;
public static final int PORT = BuildConfig.PORT;
private static final String DIR = "/";
public static String getBaseUrl() {
return SCHEME + "://" + HOST + ":" + PORT + DIR;
}
}
多渠道
开发完成后在国内通常需要上很多的APP Store,为了区分不同渠道就需要多渠道打包，这个与多版本类似，Gradle提供了productFlavors,在productFlavors中可以定义不同的渠道，在不同渠道中定义不同的渠道值以及其他变量，如下：
productFlavors {
channel_official {
flavorDimensions rootProject.ext.flavorDimensions.official
manifestPlaceholders = [
CHANNEL_VALUE: rootProject.ext.channel.official,
]
}
channel_yingyongbao {
flavorDimensions rootProject.ext.flavorDimensions.yingyongbao
manifestPlaceholders = [
CHANNEL_VALUE: rootProject.ext.channel.yingyongbao,
]
}
}
以上在productFlavors中定义了官方渠道版、应用宝渠道版，渠道下面在manifestPlaceholders中定义渠道值，然后在AndroidManifest.xml中引用如下：
然后就可以在Java中调用该值，例如将该值作为参数传入分析系统中，就可区分不同渠道APP的下载量等，获取CHANNEL值如下：
public static String getChannel(Context context) {
String channel;
try {
ApplicationInfo applicationInfo = context.getPackageManager()
.getApplicationInfo(context.getPackageName(), PackageManager.GET_META_DATA);
channel = applicationInfo.metaData.getString("CHANNEL");
} catch (PackageManager.NameNotFoundException e) {
channel = "";
LogUtils.d("getChannel exception");
}
return channel;
}
也可定义多版本中提到的applicationId等,可用来定义不同配置参数。
总结
多渠道多版本配置完毕编译过后，在Android Studio的Build Variants菜单中（如下）就会出现多版本和多渠道的混合，例如release版和官方渠道版结合为officialRelease，最终就会形成多版本*多渠道=版本。
Android Studio多版本多渠道打包到这里就结束了，读者有不同观点或疑惑请留言交流，觉得不错就点个赞呗，谢谢！！！