AndroidBuildVariants为项目设置变种版本的方法

前言

在项目开发过程中，时常会碰到这种情况：

1.同一个Project的同一个API,有几个不同的接口，比如内部测试用的Server,和当前版本暴露给用户使用的Server；

2.同一个Project有免费版和收费版

3.同一个Project不同环境下有不同的Constants常量

当然我们可以简单的通过这种方式处理不同情况下的API:

// GET 电影信息
String douban_movie_info = "/v2/movie/test/subject";
//String douban_movie_info = "/v2/movie/production/subject";

或者这种情况：

long waitTime = 10000; //正式版本某个操作，会耗时10秒
//long watTime = 1000; //开发环境我们只想1秒就足够了

在不同的环境下我们通过注释，切换使用对应的API,比如说开发时我们使用内网Server的“test/subject”接口，正式发布版本切换为“production/subject”接口;

同理：

不同的环境下我们通过注释，平时开发打开1000，注释掉10000；版本发布时注释掉1000，打开10000……

但是这种操作太繁琐太麻烦了，我们可以使用big更高一些的方式，比如AndroidStudio为开发人员配置的一个功能：Build Variants(直译：Build 口味)。

1.Module中 Build.Gradle配置：

buildTypes {
 release {
  minifyEnabled true //是否代码混淆
  multiDexEnabled true //防止方法数量超过65536导致错误
 }
 debug {
  minifyEnabled false 
  multiDexEnabled true
 }
}
// If you need to add more flavors, consider using flavor dimensions.
// 构建变种版本
productFlavors { 
 production { //正式发布版本
 }
 dev {   //开发测试版本
 }
}

ok,基本配置结束，我们点击sync同步项目之后，打开AndroidStudio左下角的Build Variants菜单：

我们先不考虑右边的代码，我们看到了我们Module的“productionDebug”按钮，这意味着我们当前的环境是正式发布版本的Debug模式。我们有哪几种模式呢？

所有Build Variant 
- productionDebug //正式版本的debug包 
- productionRelease //正式版本的Release包 
- devDebug //开发版本的debug包 
- devRelease //开发版本的Release包

可以看到，我们拥有的四种变种版本，数量正好是「Build.gradle」文件中「buildTypes」*「productFlavors」的结果，我们便完全可以据此开发出不同的变种版本。

2.Build Variant牛刀小试：

现在我们可以在build.gradle文件中加一些小「佐料」：

productFlavors {
 production {
  manifestPlaceholders = [
    APP_NAME   : "@string/app_name"]
 }
 dev {
  manifestPlaceholders = [
    APP_NAME   : "@string/app_name_dev"]
 }
}

在你的string资源文件中添加：

LIFE TOOL
LT 开发版

然后是你的清单文件Manifest.xml添加占位符${APP_NAME}:

然后我们切换到productionDebug版本，点击运行：

模拟器中，我们获得的App:

然后我们切换到devDebug版本，点击运行：

模拟器中，我们获得的App:

是不是很方便！其实我们仔细点还可以观察到，在我们切换不同变种版本的时候，同时gradle也在进行编译，与其说我们是在切换变种版本，更准确的是我们在切换两种不同版本的代码！

3.Build Variant深入学习：

如果说单单只能改个app名字啥的实际上并没有什么用，我们在工程的对应目录下创建2个不同的文件夹：

如图，我们创建了「production」和「dev」两个文件夹，这两个文件夹什么用呢，在我们切换不同的变种版本时，我们app使用的代码就从对应的文件夹下去找！

比如：

public interface ConstantsApi {
long waitTime = 10000; //正式版本某个操作，会耗时10秒
}
public interface ConstantsApi {
long watTime = 1000; //开发环境我们只想1秒就足够了
}

假如创建两个ConstantsApi文件，显然我们想将第二个「ConstantsApi」文件放入「开发环境」对应的dev版本中使用，我们就可以这样：

创建和src/main同样目录的文件夹（这样最好，不容易乱）

比如我的工程src/main下面结构可能是这样： 
- /MyProject/MyApplication/app/src/main/java/com/mei_husky/lifemanager 
那么src/dev文件夹下的目录结构最好也是： 
- /MyProject/MyApplication/app/src/dev/java/com/mei_husky/lifemanager

这时，我们切换到我们的dev变种版本，打开我们的Android视图，我们可以看到：

同理，我们在同样的方式在production目录下创建同样的文件夹，将另外一个10s的ConstantsApi文件放在该目录下，切换到productionDebug变种，我们又会看到:

我们可以看到，不同变种的文件夹只有我们在切换到该变种时，该文件夹才会显示，比如dev变种只显示dev文件夹不显示production文件夹，当我们切换到production变种时，dev同样消失了。

更神奇的是，我们此时使用这些变量，运行代码，所得的结果也因为版本的不同而不同，我们使用dev变种版本，我们只需要等1s,切换到production版本，我们直接就可以打包发布。

4.总结

这样的好处是很明显的，「首先」我们不管有多少不同环境的配置，我们只需要配置一次，以后想切换到哪种环境，我们只需要切换到该变种就可以了；「其次」，这样的结构非常清晰，等同于我们有N套不同版本的代码，不会代码多了版本多了，人就蒙了。