Gradle 之構建變體（BuildVariant）

zly394發表於2017-03-29
GradleUI

一、構建變體

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中有同名的類，則會編譯不通過

相關文章