當你在開發一個app,通常你會有幾個版本。大多數情況是你需要一個開發版本，用來測試app和弄清它的質量，然後還需要一個生產版本。這些版本通常有不同的設定，例如不同的URL地址。更可能的是你可能需要一個免費版和收費版本。基於上述情況，你需要處理不同的版本：開發免費版，開發付費版本，生產免費版，生產付費版，而針對不同的版本不同的配置，這極大增加的管理難度。

Gradle有一些方便的方法來管理這些問題。我們很早之前談過debug和release版本，現在我們談到另外一個概念，不同的產品版本。構建版本和生產版本通常可以合併，構建版本和生產版本的合併版叫做構建變種。

這一章我們將學習構建版本，它能使得開發更有效率，並且學習如何使用它們。然後我們會討論構建版本和生產版本的不同，以及如何將其合併。我們會探討簽名機制，如何針對不同的變種簽名等。

構建版本 在Gradle的Android外掛中，一個構建版本意味著定義一個app或者依賴庫如何被構建。每個構建版本都要特殊的一面，比如是否需要debug，application id是什麼，是否不需要的資源被刪除等等。你可以定義一個構建版本通過buildTypes方法。例如：

android {
       buildTypes {
           release {
               minifyEnabled false
               proguardFiles getDefaultProguardFile
                 ('proguard-android.txt'
 
), 'proguard-rules.pro'
           }
        }
 }

這個檔案定義了該模組是release版本，然後定義了proguard的位置。該release版本不是唯一的構建版本，預設情況下，還有個debug版本。Android studio把它視為預設構建版本。

建立自己的構建版本 當預設的構建版本不夠用的時候，建立版本也是很容易的一件事，建立構建版本你只需要在buildTypes寫入自己的版本。如下所示：

android {
    buildTypes {
        staging {
            applicationIdSuffix ".staging"
 

            versionNameSuffix "-staging"
            buildConfigField "String", "API_URL",
            "\"http://staging.example.com/api\""
         }
    }
}

我們定義了一個staging版本，該版本定義了一個新的application id，這讓其與debug和release版本的applicationID不同。假設你使用了預設的配置，那麼applicationID將會是這樣的：

• Debug:com.package
• Release:com.package
• Staging:com.package.staging 這意味著你可以在你的裝置上安裝staging版本和release版本。staging版本也有自己的版本號。buildConfigField定義了一個新的URL地址。你不必事事都去建立，所以最可能的方式是去繼承已有的版本。

android {
       buildTypes {
           staging.initWith(buildTypes.debug)
           staging {
               applicationIdSuffix ".staging"
               versionNameSuffix "-staging"
               debuggable = false
           } 
        }
}

initWith()方法建立了一個新的版本的同時，複製所有存在的構建版本，類似繼承。我們也可以複寫該存在版本的所有屬性。