Gradle For Android(4)--构建不同的版本

介绍

当构建App的时候，通常都会有不同的版本。比如说测试版本，正式版本，Debug版本等等。而这些版本通常有不同的配置，比如说服务器的域名，Log开关，付费开关等等特性。

之前我们看到了Release以及Debug版本的概念，而接下来会介绍product flavors的概念。而这也可以帮助我们管理不同的版本。Build Type和Product Flavors总是联合在一起的，它两结合的结果就称之为Build Variant。

Build Types

在Gradle的Android Plugin中，Build Type用于定义App以及Library如何构建。每一个Build Type都会指明是否为Debug，Application Id，是否无用的资源应该被删除掉等等。你也可以在buildTypes的代码块中定义多种Build Types。Android Studio默认生成的标准的build Types代码块如下:

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

一个新的Module默认的build.gradle文件中会配置一个release的Build Type。这个build type通过设置minifyEnabled为false禁用删除无用的Resources，以及定义了默认的ProGuard配置文件。

创建Project的时候不仅仅只有Release的构建类型，默认每个Module都有一个Debug的构建类型。我们可以在里面改改里面的值。

创建Build Type

当默认的配置不满足需求时，我们可以创建我们自定义的Build Type。我们需要做的就是在buildTypes代码块中创建一个新的对象即可，如下所示，创建一个名为staging的Build Type：

android {
    buildTypes {
        staging {
            applicationIdSuffix ".staging"
            versionNameSuffix "-staging"
            buildConfigField "String", "API_URL","\"http://staging.example.com/api\""
        }
    }
}

staging的Build Type定义了一些Application Id的后缀，使得Application的ID与Debug/Release版本不一样。假设你已经有了默认的Build配置，这些版本的ApplicationId会如下：

• Debug: com.package
• Release: com.package
• Staging: com.package.staging

这也就意味着我们能够在同一台设备上安装多个版本的。也可以使用buildConfigField属性定义了不同的URL。

我们也可以通过Copy其他Build Type中的属性，来初始化一个新的BuildType，通过initWith来初始化该BuildType对象。代码如下所示：

android {
       buildTypes {
           staging.initWith(buildTypes.debug)
           staging {
               applicationIdSuffix ".staging"
               versionNameSuffix "-staging"
               debuggable = false
            } 
      }
}

initWith方法创建了一个新的Build Type，并且从一个已经存在的build type中复制这些属性。它也可以重写这些属性，或者定义其他的新的属性。

Source sets

当创建了一个新的build type之后，Gradle也会创建一个新的source set。默认的source set目录会放在相同的Build Type的目录下。当你创建一个新的build type时，该目录不会自动创建，你必须在你使用代码与资源前自己为每一个build type创建source set目录。

这是标准的目录结构，包含了三种Build Type：

app
└── src
├── debug
│ ├── java
│ │   └── com.package
│ ├── res
│ │ └── layout
│ │       └── activity_main.xml
│ └── AndroidManifest.xml
├── main
│ ├── java
│ │   └── com.package
│ ├── res
└── MainActivity.java
└── Constants.java
│ └── AndroidManifest.xml
├── staging
│ ├── java
│ │   └── com.package
├── drawable
└── layout
└── activity_main.xml
│ ├── res
│ │ └── layout
│ │       └── activity_main.xml
│ └── AndroidManifest.xml
└── release
    ├── java
    │   └── com.package
    │       └── Constants.java
    └── AndroidManifest.xml

比如，如果希望在某个build type下替换一些属性，添加一些代码，或者添加一些layouts、strings的话，都是可以做到的。

当使用不同的source sets的时候，Resources会比较特殊。Drawables和layout文件都会被在Main Source Set中的相同名字的资源所重写，但是在values文件夹下面的，如strings、colors、dimens等则不会。Gradle会用main resources来merge各个build type的资源。

例如，如果有一个strings.xml文件在main source set中:

<resources>
       <string name="app_name">TypesAndFlavors</string>
       <string name="hello_world">Hello world!</string>
</resources>

如果在staging的build type中也存在一个strings.xml:

<resources>
       <string name="app_name">TypesAndFlavors STAGING</string>
</resources>

那么最后merge完的strings.xml会如下:

<resources>
       <string name="app_name">TypesAndFlavors STAGING</string>
       <string name="hello_world">Hello world!</string>
</resources>

同样AndroidManifest.xml也是同样的，特定的build type的包会把main source set中的AndroidManifest.xml覆盖。

Product flavors

Build Type可以对于相同的App配置生成不同类型的构建，与Build Type相反，product flavors用来创建相同的App，但是不同的版本。典型的例子就是App有免费和付费版本。另外一个常用就是为只有一个品牌但是有很多客户端，比如说滴滴，外卖，银行等都有司机端和用户端。他们只想修改Logo，Color，Url等等。Product Flavors可以很简单的处理相同的代码生产出不同的版本。

如果你不确定是否需要一个新的build type，或者新的product flavor，那么则需要看一下是否真的需要构建一个新的APP发布到应用市场上。

创建Product Flavors

我们可以通过添加productFlavor代码块来添加一个新的Product Flavor：

android {
       productFlavors {
           red {
               applicationId 'com.gradleforandroid.red'
               versionCode 3
            }
          blue {
            applicationId 'com.gradleforandroid.blue'
            minSdkVersion 14
            versionCode 4
           } 
     }
}

Product Flavors拥有和Build Type不同的属性。因为Product Flavors是一个ProductFlavor类，就像defaultConfig对象一样。这也就意味着，defaultConfig和所有的Product flavors共享相同的Properties。

Source Set

就像Build Types一样，Product Flavors能够拥有他们自己的Source Sets目录。创建一个与Product Flavors名字相同的文件夹。而这个目录的明哲，需要联合它的Build Type以及Flavors，这样用来覆盖那些属性。

比如，你想有一个不同的App Icon在blue flavors中生成一个Release版本的包，那么这个目录应该叫做blueRelease。然后这个组件所关联的目录将会比其他Build Type以及Product Flavors的组件目录优先级会更高。

Multiflavor variants

在某些情况下，你可能希望创建一些联合的Product Flavors。比如说，Client A和Client B都基于相同的代码需要一个免费和付费的版本。创建四个不同的Flavors单独的Settings是不可行的。所以，Combining Flavors可以更高效的使用flavor dimensions：

 android {
       flavorDimensions "color", "price"
       productFlavors {
           red {
               flavorDimension "color"
           }
            blue {
               flavorDimension "color"
           }
          free {
               flavorDimension "price"
           }
           paid {
               flavorDimension "price"
          } 
     }
}

当添加了flavor dimensions之后，Gradle希望你为每个Flavor都指定一个flavor dimension。如果你忘记了，则编译时会报错。flavorDimensions数组定义了这些Dimensions，而这些Dimensions的顺序是非常重要的。当需要联合两个Flavors的时候，你可能已经定义了相同的Properties或者Resources。在这种情况下，flavors dimensions数组的顺序决定了哪个flavor配置会覆盖另外的。在之前的例子中，Color Dimension会覆盖Price Dimension 。并且这个顺序，也决定了构建的名字。

假设默认的构建配置有Debug和Release两种Build Type，就像之前的Example中定义的flavors就会生成以下这些版本：

• blueFreeDebug and blueFreeRelease
• bluePaidDebug and bluePaidRelease
• redFreeDebug and redFreeRelease
• redPaidDebug and redPaidRelease

Build variants

Build Variants仅仅只是Build Types以及Product Flavors的联合。一旦创建了一个新的Build Type或者Product Flavor的话，那么一个新的Variants就会被创建。

例如，如果有一个标准的Debug和Release构建类型，并且你创建了一个Red和Blue的Product Flavor，那么下面的Build Variant就会生成：

Build Variants

这是Android Studio中的一个窗口。可以在tool window的左下角找到它，或者从View->Tool Windows->Build Variants中打开。我们也可以选择其中的Variant来执行任务。如果没有定义任何的Build Types的话，Android Plugin会默认创建一个Debug的Build Type。

Tasks

Android Plugin会为每一个配置的Build Variant创建Tasks。一个新的Android App拥有Debug和Release两种Build Types，所以默认的就会有两个Task，一个是assembleDebug一个是assembleRelease来构建不同的APK。当添加一个新的Build Type的时候，一个新的Task也就会被创建，一旦你开始添加Flavors，一整套Tasks就会被创建，因为每一个BuildType的Tasks都会为每个Product Flavor联合。也就是，一个简单的Build Type和Flavor设置后，就会有三个任务去构建所有的Variants。

• assembleBlue：使用blue flavor配置并且assemble BlueRelease和BlueDebug
• assembleDebug：使用Debug Build Type的配置，并且为每一个Product Flavor assemble一个Debug的版本
• assembleBlueDebug：combines特定的Flavor以及BuildType配置，并且Flavor的设置会覆盖BuildType的设置

每一个BuildType和Product Flavor都会创建新的Tasks。

Source Set

Build Variants是一个联合了BuildType和ProductFlavors并且使用它们自己SourceSet目录的版本。

例如：Variant创建从Debug Build Type以及Blue、Free Flavor的版本，它可以拥有src/blueFreeDebug/java/的Source Set。我们可以在sourceSets代码块中重写它的location。

Resource and manifest merging

Android Plugin需要在打包前对Main的SourceSet以及BuildType的SourceSet进行一次Merge。而且Library工程也会提供额外的资源，它们也会被Merge，例如Manifest.xml等等。也会在其中声明一些权限等。

Resource和Manifest.xml的优先级顺序如下：

Order.png

如果一个Resource声明在Flavor和Main source set中的话，那么Flavor中的值优先级会更高。在这种情况下，Flavor的SourceSet中的资源会被打包到APK中。而Library工程的资源优先级会是最低的。

Creating build variants

Gradle可以很容易的处理复杂的多种构建。甚至当创建两种BuildType和两种Product Flavors的时候。例如：

android {
       buildTypes {
           debug {
               buildConfigField "String", "API_URL","\"http://test.example.com/api\""
           }
           staging.initWith(android.buildTypes.debug)
           staging {
               buildConfigField "String", "API_URL","\"http://staging.example.com/api\""
               applicationIdSuffix ".staging"
           }
       }
       productFlavors {
           red {
               applicationId "com.gradleforandroid.red"
               resValue "color", "flavor_color", "#ff0000"
           }
           blue {
               applicationId "com.gradleforandroid.blue"
               resValue "color", "flavor_color", "#0000ff"
            } 
      }
}

在这个例子中，我们会创建出来四个不同版本的Variants： blueDebug，blueStaging，redDebug，redStaging 每一个都有API_URL以及flavor_color的属性。

以下为blueDebug的样式：

blueDebug

而以下为redStaging的样式：

redStaging

Variant filters

通过Variant fileters的方式，可以完全忽略某种Variant的构建，从而达到使用assemble命令的时候提升构建的速度。并且不会执行的Task也不会打印的Tasks列表中出现。这样也同样会确保build variant不会在Android Studio中显示。

我们可以通过在App或者Library的Root-Level的build.gradle文件中添加以下代码：

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

在这个例子中，首先检查BuildType是否为Release，然后检查Flavors的名字，如果flavors为blue则忽略。其中variant.getFlovors会获取到flavor dimensions中所有的flavor。

variant filter

可以看到blueFreeRelease和bluePaidRelease已经不在列表中。如果直接执行gradlew tasks的话，就会注意到所有和这个variants相关的tasks都不存在了。

Signing configurations

在发布App到Google Play或者其他的商店的时候，我们需要使用一个Private Key对APK进行签名。如果有一个付费和免费的版本，或者不同的客户端版本时，你需要为不同的Flavor版本APK进行不同的签名。

android {
       signingConfigs {
           staging.initWith(signingConfigs.debug)
           release {
               storeFile file("release.keystore")
               storePassword"secretpassword"
               keyAlias "gradleforandroid"
               keyPassword "secretpassword"
        } 
    }
}

在这个例子中，我们创建了两个不同的签名。 debug配置会被Android Plugin自动设置，并且使用一个已知的Password进行签名，所以不需要为Debug的BuildType创建签名配置。而staging配置使用initWith，它是从另外一个签名配置中Copy的属性。这也就意味着staging的构建会和Debug一样的签名，而没有它自己定义的签名。 而release配置则使用storeFile来指定keystore文件，并且定义了Key的别名以及Password。

当定义完了这个签名的配置后，你需要在BuildType或者Flavors中应用一下。BuildType和Flavors都有一个属性叫做signingConfig，如下所示：

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

通过这种方式会对BuildType以及ProductFlavors应用不同的签名。

当签名一个Flavor版本的时候，你需要重写BuildType中的签名配置W。当需要使用相同的BuildType不同版本的Flavors的签名时，可以通过下述方式：

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

上面这个例子展示了如何在red和blue的Release版本使用不同的签名，但是却不影响Debug和Staging的BuildType。