# 多定制的變種版本 某些情況下，應用可能需要基于多個標準來創建多個版本。 例如，Google Play 中的 multi-apk 支持 4 種過濾器。根據每個過濾器來創建不同的 APK 需要使用 *Product Flavor* 分組。 假如有個游戲有免費版和付費版，并且需要在 multi-apk 支持中使用 ABI 過濾器（譯注：ABI，應用二進制接口，優點是不需要改動應用的任何代碼就能夠將應用遷移到任何支持相同 ABI 的平臺上）。該游戲應用需要 3 個 ABI 和兩個特定版本，因此就需要生成 6 個 APK（忽略不同 *Build Types* 生成的 variant 版本）。 然而，3 個 ABI 付費版的源代碼都是相同的，因此創建 6 個 flavor 來實現并不是一個好辦法。 相反的，可以使用兩個 flavor 分組，并且讓它自動構建所有可能的 variant 組合。 對應的功能實現需要使用 Flavor Dimensions（譯注：`Flavor Dimensions` 對應舊版中的 `Flavor Groups`），并將 flavor 分配到一個指定的 Group 中。 ~~~ android { ... flavorDimensions "abi", "version" productFlavors { freeapp { flavorDimension "version" ... } x86 { flavorDimension "abi" ... } } } ~~~ **andorid.flavorDimensions** 數組按照先后排序定義了可能用到的分組。（示例中）每個 *Product Flavor* 都被分配到一個分組中。 示例中將 *Product Flavor* 分為兩組，為別為 abi [x86,arm,mips] 和 version [freeapp,paidapp]，再加上默認的 *Build Type* [debug,release]，最后會生成以下的 Build Variant： - `x86-freeapp-debug` - `x86-freeapp-release` - `arm-freeapp-debug` - `arm-freeapp-release` - `mips-freeapp-debug` - `mips-freeapp-release` - `x86-paidapp-debug` - `x86-paidapp-release` - `arm-paidapp-debug` - `arm-paidapp-release` - `mips-paidapp-debug` - `mips-paidapp-release` **andorid.flavorDimensions** 中元素的順序非常重要（variant 命名和優先級等）。 每個 variant 版本的配置由幾個 *Product Flavor* 對象決定： - **android.defaultConfig** - 一個來自 abi 組中的對象 - 一個來自 version 組中的對象 flavorDimensions 中的順序決定了 flavor 的優先級，這對于資源來說非常重要，因為 flavor 中的值會替換定義在低優先級的 flavor 中的值。 flavor dimensions 使用最高的優先級定義，因此前面例子中的優先級為： ~~~ abi > version > defaultConfig ~~~ Multi-flavors 項目同樣擁有額外的 sourceSet，類似于 variant 的 sourceSet，只是少了 Build Type： - **android.sourceSets.x86Freeapp**位于 `src/x86Freeapp/` - **android.sourceSets.armPaidapp**位于 `src/armPaidapp/` - 等等... 這允許在 flavor-combination（組合 flavor）的層次上進行定制。它們擁有比最基本的 flavor 的 sourceSet 更高的優先級，但是優先級低于 Build Type 的 sourceSet。