Gradle 之構建變體（BuildVariant）

1、構建變體

1. BuildType

1.1 默認BuildType

默認狀況下，Android plugin會自動的構建release和debug兩個版本

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
    debug {
        minifyEnabled false
    }
}
// release版本中設置了開啓混淆，而且定義了混淆文件的位置複製代碼

release和debug的差別主要在因而否能夠在設備上調試應用以及APK如何簽名。

• debug 版本會被使用已知的名稱/密碼自動生成的密鑰/證書籤名。
• release 版本在構建過程當中不會被簽名，須要構建後再簽名。

1.2 自定義BuildType

Android plugin容許自定義這兩個示例，而且能夠建立其餘的buildType，以下：

buildTypes {
    debug {
        minifyEnabled false
        applicationIdSuffix ".debug"
    }
    custom.initWith(buildTypes.debug)
    custom {
        applicationIdSuffix ".custom"
        versionNameSuffix "-customs"
    }
}複製代碼

• 上述配置進行了一下設置

  1. 對默認的debug構建類型進行了修改，關閉了混淆配置，添加applicationId後綴
  2. 以debug爲基礎建立一個叫custom的構建類型（至關於繼承了debug版本），在custom的構建類型中修改applicationId後綴，並添加了versionName的後綴

• 建立一個新的BuildType的步驟爲：

  1. 在buildTypes容器下添加一個自定義名稱的元素
  2. 調用initWith或者使用閉包進行配置點擊查看BuildType的可配置屬性

• 對於每個BuildType，Android plugin都會建立對應的「assembleBuildTypeName」任務

• 對於每個BuildType，均可以在dependencies容器中添加名爲BuildTypeNameCompile的依賴配置

• 對於每個BuildType，Android plugin都會建立一個對應的sourceSet，默認位置爲：src/BuildTypeName
  因此新建BuildType的名字不能是main、androidTest和test這三個已經被用的名字
  BuildType的代碼/資源會以如下方式進行合併

  1. manifest會被合併到app的manifest文件中
  2. res目錄下的資源文件會替換main裏的資源文件
  3. java目錄下的文件會被添加到main裏的java目錄中，因此不能和main裏的類重名（含包名）

2. ProductFlavor

2.1 單維度的ProductFlavor

ProductFlavor定義了經過工程構建應用的自定義版本。一個獨立的工程能夠定義不一樣的flavor改變生成的應用。
建立方式：

productFlavors {
    flavor1 {
        minSdkVersion 10
        versionCode 1
    }
    flavor2 {
        minSdkVersion 14
        versionCode 2
    }
}複製代碼

• 上述配置進行了如下設置

  1. 新建了兩個ProductFlavors，名字分別爲flavor1和flavor2
  2. 從新設置了minSdkVersion和versionCode

• 建立一個新的ProductFlavor的步驟爲：

  1. 在productFlavors容器下添加一個自定義名稱的元素
  2. 使用閉包進行配置

2.2 多維度的ProductFlavor

某些狀況下，咱們須要從多個維度來區分app的版本，好比渠道和是否付費，只是咱們就須要建立多維度的ProductFlavor來生成不一樣的apk。
建立方式：

flavorDimensions "channle", "version"

productFlavors {
    huawei {
        dimension "channle"
    }

    xiaomi {
        dimension "channle"
    }

    free {
        dimension "version"
    }

    paid {
        dimension "version"
    }
}複製代碼

• 上述配置進行了如下設置

  1. flavorDimensions定義了可能用到的維度和順序
  2. 新建了四個ProductFlavor，每個ProductFlavor都指定了一個維度

• 建立多維度的ProductFlavor的步驟爲：

  1. 使用flavorDimensions定義維度和順序
  2. 在productFlavors容器下添加一個自定義名稱的元素
  3. 使用閉包進行配置，必須指定ProductFlavor的維度點擊查看ProductFlavor的可配置項

• 對於每個ProductFlavor，Android plugin都會建立對應的「assembleProductFlavorNameDebug」和「assembleProductFlavorNameRelease」任務

• 對於每個ProductFlavor，均可以在dependencies容器中添加名爲ProductFlavorNameCompile的依賴配置

• 相似BuildType，Android plugin也會爲ProductFlavor建立對應的sourceSet，默認的位置爲：src/ProductFlavorName
  因此ProductFlavor的名字不能和已存在的BuildType的名字衝突
  ProductFlavor的代碼/資源會以如下方式進行合併

  1. manifest會被合併到app的manifest文件中
  2. res目錄下的資源文件會替換main裏的資源文件
  3. java目錄下的文件會被添加到main裏的java目錄中，因此不能和main裏的類重名（含包名）

3. BuildVariant

BuildType和ProductFlavor相結合，組成了構建變體。每建立一個buildType或productFlavor，都會同時建立相應的變體。

3.1 單維度ProductFlavor時產生的BuildVariant

例如：

buildTypes {
    debug {
        minifyEnabled false
        applicationIdSuffix ".debug"
    }
    custom.initWith(buildTypes.debug)
    custom {
        applicationIdSuffix ".custom"
        versionNameSuffix "-customs"
    }
}

productFlavors {
    flavor1 {
        minSdkVersion 10
        versionCode 1
    }
    flavor2 {
        minSdkVersion 14
        versionCode 2
    }
}複製代碼

上述配置的狀況下會產生6個BuildVariant:

• flavor1Debug
• flavor1Release
• flavor1Custom
• flavor2Debug
• flavor2Release
• flavor2Custom

3.2 多維度ProductFlavor時產生的BuildVariant

若是是多維度的ProductFlavor，例如：

buildTypes {
    debug {
        minifyEnabled false
        applicationIdSuffix ".debug"
    }
    custom.initWith(buildTypes.debug)
    custom {
        applicationIdSuffix ".custom"
        versionNameSuffix "-customs"
    }
}

flavorDimensions "channle", "version"

productFlavors {
    huawei {
        dimension "channle"
    }

    xiaomi {
        dimension "channle"
    }

    free {
        dimension "version"
    }

    paid {
        dimension "version"
    }
}複製代碼

上述配置的狀況下會產生12個BuildVariant:

• huaweiFreeDebug
• huaweiFreeRelease
• huaweiFreeCustom
• huaweiPaidDebug
• huaweiPaidRelease
• huaweiPaidCustom
• xiaomiFreeDebug
• xiaomiFreeRelease
• xiaomiFreeCustom
• xiaomiPaidDebug
• xiaomiPaidRelease
• xiaomiPaidCustom

3.3 BuildVariant的使用

• 對於每個BuildVariant，Android plugin都會建立對應的「assembleBuildVariantName」任務

• BuildVariant的sourceSet合併規則：

  1. 全部的manifest會被合併到一個manifest文件中
  2. res目錄下的資源文件會遵循優先級覆蓋的原則：
     • BuildType會覆蓋ProductFlavor
     • flavorDimensions中定義維度是的順序，決定了ProductFlavor之間資源覆蓋的順序，順序在在前的優先級越高，高優先級會覆蓋低優先級的資源
     • ProductFlavor會覆蓋main的資源文件
  3. java目錄下的文件會被添加到main裏的java目錄中，若是所選的BuildVariant中BuildType和ProductFlavor對應的sourceSet中有同名的類，則會編譯不經過