构建Variant（2）

构建variant是构建类型和product flavor结合的结果，不论什么时候创建一个构建类型或prodect flavor，新的variant都会被创建。
查看：

任务

Gradle的Android插件将会为你配置的每个构建variant创建任务。一个新的Android应用默认有debug和release两种构建类型，所以你可以用assembleDebug和assembleRelease来分别构建两个APKs，即用单个命令assemble来创建两个APKs。当添加一个新的构建类型时，新的任务也将被创建。一旦你开始添加flavor，那么整个全新的任务系列将会被创建，因为每个构建类型的任务会和每个product flavor相结合。这意味着，仅用一个构建类型和flavor做一个简单的设置，你就会有三个任务用于构建全部variant：

• assembleBlue：使用blue flavor配置和组装BlueRelease及BlueDebug。
• assembleDebug：使用debug构建配置类型，并为每个product flavor组装一个debug版本。
• assembleBlueDebug：应构建配置类型结合flavor配置，并且flavor设置将会覆盖构建类型设置。

源集

构建variant，是一个构建类型和一个或多个product flavor的集合体，其可以有自己的源集文件夹。例如，有debug构建类型blue flavor和free flavor创建variant可以有自己的源集src/blueFreeDebug/java/。其可以通过使用soruceSets代码块来覆盖文件夹的位置。

源集合并资源和manifest

源集的引入额外增加了构建进程的复杂性。Gradle的Android插件在打包应用之前将main源集和构建类型源集合并在一起。此外，library项目也可以提供额外的资源，这些也需要被合并。这同样适用于manifest文件。例如在你应用的debug variant中可能需要额外的Android权限来存储log文件。你并不向在main源集中声明该权限，因为这会吓跑潜在客户。相反，你可以在debug构建类型的源集中额外添加一个manifest文件来申明额外的权限。
顺序：build type > flavor > main > dependencies

如果资源在flavor和main源集中都有声明，那么flavor中的资源将会被赋予更高的优先级。在这种情况下，flavor源集中的资源将会被打包。在library项目中声明的资源通常具有最低优先级。

variant过滤器

在你的构建中，可以完全忽略某些variant。通过这种方式，你就可以通过assemble命令来加快构建所有variant的进程，并且你的任务列表不会被任何无需执行的任务污染。variant过滤器也可确保在Android studio的构建variant切换器中不会出现过滤的构建variant：

android.variantFilter { variant ->
        if (variant.buildType.name.equals('release')) {
            variant.getFlavors().each() { flavor ->
                if (flavor.name.equals('blue')) {
                    variant.setIgnore(true);
                }
            }
        }
    }

在本例中，我们首先检查了variant的构建类型中是否含有release，然后我们去除了搜友含有该名称的Product flavor。当不适用flavor维度时，在flavor数组中将只会含有一个product flavor。一旦你开始使用flavor维度，那么flavor数组及将会持有和维度一样多的flavor。

签名配置

在你发布应用到Google Play或任何其他应用商店之前，都需要用密钥给他签名。如果你有一个付费版和免费版或针对不同用户的不同应用，那么你需要为每个flavor使用不同的私钥签名。这就是签名配置出现的原因。

signingConfigs{
release {
storeFile file(“release.keystore”)
storePassword “secretpassword”
keyAlias “gradleforandroid”
keyPassword “secretpassword”
}
}
Android 插件使用了一个通用keystore和一个一直密码自动创建了debug配置，所以就没有必要为该创建类型在创建一个签名配置了。release配置使用storeFile来指定keystore文件路径，之后定义了密钥别名和两个密码。

在定义签名配置之后，你需要将他们应用到你的构建类型或flavor中。构建类型和flavor都有一个交signingVConfig的属性，如下所示：

buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }

如果你想为每个你所创建的flavor使用不同的凭证，那么你就需要船舰不同的签名配置，不过你可以以相同的方式来定义他们：

productFlavors{
        blue{
            signingConfig signingConfigs.release
        }
    }

使用签名配置这种方式会造成很多问题。当为flavor分配一个配置时，实际上他是覆盖了构建类型的签名配置。如果你不想这样，那么在使用flavor时，就应该为每个构建类型的每个flavor分配不同的密钥：

buildTypes {
        release {
            productFlavors.red.signingConfig signingConfigs.red
            productFlavors.blue.signingConfig signingConfigs.blue
        }
    }