前言
在项目开发过程中，时常会碰到这种情况：
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资源文件中添加：
<resources> <string name="app_name">LIFE TOOL</string> <string name="app_name_dev">LT 开发版</string> </resources>
然后是你的清单文件Manifest.xml添加占位符${APP_NAME}:
<application
android:icon="@mipmap/ic_app_icon"
android:label="${APP_NAME}"//app名称，根据不同变种版本名字也不同
android:supportsRtl="true"
android:theme="@style/AppTheme">
然后我们切换到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套不同版本的代码，不会代码多了版本多了，人就蒙了。
