Build Variants 认识

基础

构建变体(Build Variants)有两部分内容构成 :

buildTypes（构建类型） +  productFlavors（产品风味）

通过 android { } 配置变量进行部署：

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

    productFlavors {
        flavorDimensions "api","flavor"
        flavor1 {
            dimension "flavor"
        }

        flavor2 {
            dimension "flavor"

        }
        
        api1 {
            dimension "api"
        }

        api2 {
            dimension "api"

        }
    }
    
    ...
}

buildTypes

在一般情况下，项目创建时，项目默认创建了两种构建类型 debug 和 release。

debug是在项目调试阶段的构建类型，而release则是面向发布。

这两个构建类型方便开发者对两种不同环境进行不同的构建配置。

比如签名信息、so支持类型、debug信息等。

buildTypes DSL

属性/方法	作用	备注
applicationIdSuffix	为计算后的 applicationId 添加该属性指定的后缀
consumerProguardFiles	将混淆规则文件添加到构建好的AAR中
crunchPngs	是否压缩PNG文件
debuggable	是否生成一个可调试的APk文件
embedMicroApp
javaCompileOptions	可以添加Java编译参数
jniDebuggable	是否生成一个可调试Native的APK文件
manifestPlaceholders	manifest文件占位符配置
matchingFallbacks	指定构建匹配失败时降级的构建类型
minifyEnabled	是否移除无用的代码
multiDexEnabled	Multi-Dex 是否支持
multiDexKeepFile	指定在需要主Dex File 存在的内容的声名文件
multiDexKeepProguard	指定一个文件，用于在编译时对主Dex classes 的额外混淆规则
name	当前构建类型的名字
postprocessing
proguardFiles	指定混淆规则文件
pseudoLocalesEnabled	是否生成仿冒资源，通过 resValue 生成
renderscriptDebuggable	生成一个用于调试 RenderScript 代码的apk
renderscriptOptimLevel	指定 RenderScript的编译优化等级
shrinkResources	是否优化未使用的资源
signingConfig	签名定义
testCoverageEnabled	是否启动覆盖测试
useProguard	是否总是启动代码混淆和资源优化
versionNameSuffix	添加版本后缀
zipAlignEnabled	是否启动zip对其
buildConfigField(type, name, value)	添加一个字段到 BuildConfig Class文件中
consumerProguardFile(proguardFile)	添加一个需要打包进AAR的混淆文件
consumerProguardFiles(proguardFiles)	添加些需要打包进AAR的混淆文件
externalNativeBuild(action)	定义native构建参数
initWith(that)	复制指定build type的所有属性信息
proguardFile(proguardFile)	添加一个混淆定义文件
proguardFiles(files)	添加混淆定义文件
resValue(type, name, value)	添加一个资源信息
setProguardFiles(proguardFileIterable)	设置混淆定义文件

仅仅对buildTypes的配置并不能满足我们差异化构建的要求，因此插件中为我们提供了另外的构建配置 productFlavors。

productFlavors

productFlavors 和 defaultConfig 同属于 ProductFlavor类。两者的配置内容基本没什么差异，但是在不同变体的构造任务中，对应的变体配置将覆盖默认配置内容。

productFlavors 需要通过 flavorDimensions 创建“模式”名，以用来对 多个flavor进行组织分组。

在上面的 productFlavors {...} 例子中，我们声名了两组模式的productFlavor，api和flavor，同时每个模式下，都有两个flavor。

根据构建的组合规则，Android Plugin 会根据这些分组进行组合关系。以上的例子为例。会产生以下几个 productFalvor组合构建任务：

1. api1Flavor1Debug
2. api1Flavor1Release
3. api2Flavor1Debug
4. api2Flavor1Release 
5. api1Flavor2Debug
6. api1Flavor2Release
7. api2Flavor2Debug
8. api2Flavor2Release

Gralde产生的变体数量等同于每个flavor模式的组合数量和构建类型数量的乘积。

falvor每个分组数量 * falvor每个分组数量... * BuildType子项数量

同时产生是名字也是根据 flavorDimensions所声名的模式名顺序进行拼接。

比如例子中在 flavorDimensions "api","flavor"声名后，产生的编译名为api*+flavor*+debug/release的组合关系。

productFlavor DSL

过滤变体

变体是Gradle根据配合内容进行组合增加的，往往会比我们所需求的变体要多，因此为了处理掉不不需要的变体。我们可以通过 variantFilter {}进行过滤。

   variantFilter {
        if(it.name.contains("flavor2")){
            it.setIgnore(true)
        }
    }

这样对于变体名中包含 flavor2 的构建变体都将不会出现在 Build Variant 中。

变体源

变体提供了对构建源的隔离，在不同的变体下，可以配置不同的 sourceSet信息。

默认情况下，main/ 的构建源是默认存在的，无论通过任何变体进行构建都将纳入构建范围，因此这里在 main/下存储的都是哥哥变体都共享的资源，而如果需要根据变体信息进行特殊构建的内容，则需要放到对应的变体目录下。

比如对于 api1Flavor1Debug 变体。对于以下几个源都将纳入构建范围：

1. api1/
2. flavor1/
3. debug/
4. api1Flavor1/
5. flavor1Debug/
6. api1Flavor1Debug/

所以如果在这些目录下如果存在同名文件将导致编译冲突。

如果需要考虑其他的构建源，则可以考虑通过 sourceSets {}进行设置，因为 sourceSet 也支持变体设置因此可以通过以下设置，对单独构建变体进行设置:

android {
    sourceSets {
        api2Flavor2 {
            java.srcDirs = [ project.getProjectDir().getAbsolutePath() + '/src/api2Flavor2/temp']
        }
    }
}

这样就在 api2Flavor2 变体构建时，将 '/src/api2Flavor2/temp' 纳入构建范围

注意点

• 一起编译 java/ 目录中的所有源代码以生成单一的输出。

注：对于给定的构建变体，如果找到两个或两个以上定义同一 Java 类的源集目录，Gradle 就会引发一个构建错误。例如，在构建调试 APK 时，您不能同时定义 src/debug/Utility.java 和 src/main/Utility.java。这是因为 Gradle 会在构建过程中检查这两个目录并引发“duplicate class”错误。如果针对不同的构建类型需要不同版本的 Utility.java，您可以让每个构建类型定义其自己的文件版本，而不将其包含在 main/ 源集中。

• 所有清单合并为单个清单。将按照上述列表中的相同顺序指定优先级。也就是说，某个构建类型的清单设置会替换某个产品风味的清单设置，依此类推。如需了解更多信息，请阅读合并清单。

• 同样，values/ 目录中的文件也会合并在一起。如果两个文件同名，例如存在两个 strings.xml 文件，将按照上述列表中的相同顺序指定优先级。也就是说，在构建类型源集中的文件中定义的值将会替换产品风味中同一文件中定义的值，依此类推。

• res/ 和 asset/ 目录中的资源将打包到一起。如果两个或两个以上的源集中定义有同名资源，将按照上述列表中的相同顺序指定优先级。

• 最后，在构建 APK 时，Gradle 会为随库模块依赖项包含的资源和清单分配最低的优先级。

变体依赖

正如源设置一样，依赖也支持变体依赖

可以通过添加变体+依赖方式进行设置。

dependencies {
    api2Flavor2Compile 'junit:junit:4.12'
}