Android Gradle构建学习（三）：Build Variants

Gradle通过配置Build Vaiants允许为同一个应用创建不同的版本。这里有两个主要的使用情景：

同一个应用的不同版本。例如一个免费的版本和一个收费的专业版本。
同一个应用需要打包成不同的apk以发布Google Play Store。
综合1和2两种情景。

gradle让在同一个项目里生成不同的APK成为可能，以取代以前需要使用一个库项目和两个及两个以上的应用项目分别生成不同APK的做法。

Product flavors

一个product flavor定义了从项目中构建了一个应用的自定义版本。一个单一的项目可以同时定义多个不同的flavor来改变应用的输出。

这个新的设计概念是为了解决不同的版本之间的差异非常小的情况。虽然最项目终生成了多个定制的版本，但是它们本质上都是同一个应用，那么这种做法可能是比使用库项目更好的实现方式。

Product flavor需要在productFlavors这个DSL容器中声明：

android {
    ....

    productFlavors {
        flavor1 {
            ...
        }

        flavor2 {
            ...
        }
    }
}

这里创建了两个flavor，名为flavor1和flavor2。

注意：flavor的命名不能与已存在的Build Type或者androidTest这个sourceSet有冲突。

Build Type + Product Flavor = Build Variant

正如前面章节所提到的，每一个Build Type都会生成一个新的APK。Product Flavor同样也会做这些事情：项目的输出将会拼接所有可能的Build Type和Product Flavor（如果有Flavor定义存在的话）的组合。每一种组合（包含Build Type和Product Flavor）就是一个Build Variant（构建变种版本）。

例如，在上面的Flavor声明例子中与默认的debug和release两个Build Type将会生成4个Build Variant：

Flavor1 - debug
Flavor1 - release
Flavor2 - debug
Flavor2 - release

项目中如果没有定义flavor同样也会有Build Variant，只是使用的是默认的flavor和配置。default(默认)的flavor/config是没有名字的，所以生成的Build Variant列表看起来就跟Build Type列表一样。

Product Flavor Configuration

每一个flavor都是通过闭包来配置的：

android {
    ...

    defaultConfig {
        minSdkVersion 8
        versionCode 10
    }

    productFlavors {
        flavor1 {
            packageName "com.example.flavor1"
            versionCode 20
        }

        flavor2 {
            packageName "com.example.flavor2"
            minSdkVersion 14
        }
    }
}

注意ProductFlavor类型的android.productFlavors.对象与android.defaultConfig对象的类型是相同的。这意味着它们共享相同的属性*。

defaultConfig为所有的flavor提供基本的配置，每一个flavor都可以重设这些配置的值。在上面的例子中，最终的配置结果将会是：

* `flavor1`
    * `packageName`: com.example.flavor1
    * `minSdkVersion`: 8
    * `versionCode`: 20
* `flavor2`
    * `packageName`: com.example.flavor2
    * `minSdkVersion`: 14
    * `versionCode`: 10

通常情况下，Build Type的配置会覆盖其它的配置。例如，Build Type的packageNameSuffix会被追加到Product Flavor的packageName上面。

也有一些情况是一些设置可以同时在Build Type和Product Flavor中设置。在这种情况下，按照个别为主的原则决定。

例如，signingConfig就这种属性的一个例子。 signingConfig允许通过设置android.buildTypes.release.signingConfig来为所有的release包共享相同的SigningConfig。也可以通过设置android.productFlavors.*.signingConfig来为每一个release包指定它们自己的SigningConfig。

Building and Tasks

我们前面提到每一个Build Type会创建自己的assemble< name >task，但是Build Variant是Build Type和Product Flavor的组合。

当使用Product Flavor的时候，将会创建更多的assemble-type task。分别是：

assemble< Variant Name > 允许直接构建一个Variant版本，例如assembleFlavor1Debug。
assemble< Build Type Name > 允许构建指定Build Type的所有APK，例如assembleDebug将会构建Flavor1Debug和Flavor2Debug两个Variant版本。
assemble< Product Flavor Name > 允许构建指定flavor的所有APK，例如assembleFlavor1将会构建Flavor1Debug和Flavor1Release两个Variant版本。

另外assemble task会构建所有可能组合的Variant版本。

开源软件的开发模式：使用Git做版本控制，采用gradle + android Studio的分布式构建思想，采用多个分支并行开发。公共组件通过maven在不同的开发团队中共享并随时使用。

编译依赖

1、compile依赖。编译时依赖，最终打包在内。
2、provided依赖。编译时依赖，但最终不打包在内。

repositories{
    flatDir{
        dirs 'libs'
    }
    ...
}
dependencies {
    compile(name:'文件名', ext:'aar')
    compile project(‘:模块名’)
    compile '远程repository路径'
    compile files('文件名.jar')
    compile fileTree(dir: 'libs', include: '*.jar')  //将libs目录下所有jar文件进行编译并打包。
    ...
}