构建 Variants（变种）版本 - 多定制的变种版本

优质

小牛编辑

124浏览

2023-12-01

某些情况下，应用可能需要基于多个标准来创建多个版本。
例如，Google Play 中的 multi-apk 支持 4 种过滤器。根据每个过滤器来创建不同的 APK 需要用到 Product Flavor。

假如一个游戏有免费版和付费版，并且需要在 multi-apk 支持中使用 ABI 过滤器。该游戏应用需要 3 个 ABI 和两个特定版本，因此就需要生成 6 个 APK（忽略不同 Build Types 生成的 variant 版本）。
然而，3 个 ABI 付费版的源代码都是相同的，因此创建 6 个 flavor 来实现并不是一个好办法。
作为代替，可以使用两个 Flavor Dimensions，并且让它自动构建所有可能的 variant 组合。

对应的功能实现需要使用 Flavor Dimensions（译注： Flavor Dimensions 对应旧版中的 Flavor Groups），并将 flavor 分配到一个指定的 dimension 中。

android {
    ...
    flavorDimensions "abi", "version"
    productFlavors {
        freeapp {
            dimension "version"
            ...
        }
        paidapp {
            dimension "version"
            ...
        }
        arm {
            dimension "abi"
            ...
        }
        mips {
            dimension "abi"
            ...
        }
        x86 {
            dimension "abi"
            ...
        }
    }
}

andorid.flavorDimensions 数组按照先后排序定义了可能用到的 dimensions。（示例中）每个 Product Flavor 都被分配到一个 dimension 中。

依据 Product Flavors [freeapp, paidapp] 和 abi [x86, arm, mips] 以及 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 dimension 中的对象
一个来自 version dimension 中的对象

flavorDimensions 中的顺序决定了 flavor 的优先级，这对于资源来说非常重要，因为高优先级 flavor 的值会覆盖低优先级 flavor 的值。
flavor dimension 使用最高的优先级定义，因此前面例子中的优先级为：

abi > version > defaultConfig

Multi-flavors 项目同样拥有额外的 sourceSet，类似于 variant 的 sourceSet，只是少了 Build Type：

android.sourceSets.x86Freeapp
位于 src/x86Freeapp/
android.sourceSets.armPaidapp
位于 src/armPaidapp/
等等…

这允许在 flavor-combination 的层次上进行定制。它们拥有比最基本的 flavor 的 sourceSet 更高的优先级，但是优先级低于 Build Type 的 sourceSet。