前言

在項目開發過程中，時常會碰到這種情況：

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}:

<applicationandroid: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套不同版本的代碼，不會代碼多了版本多了，人就蒙了。