Gradle 之构建变体（BuildVariant）

1、构建变体

1. BuildType

1.1 默认BuildType

默认状况下，Android plugin会自动的构建release和debug两个版本

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
    debug {
        minifyEnabled false
    }
}
// release版本中设置了开启混淆，而且定义了混淆文件的位置复制代码

release和debug的差别主要在因而否能够在设备上调试应用以及APK如何签名。

• debug 版本会被使用已知的名称/密码自动生成的密钥/证书签名。
• release 版本在构建过程当中不会被签名，须要构建后再签名。

1.2 自定义BuildType

Android plugin容许自定义这两个示例，而且能够建立其余的buildType，以下：

buildTypes {
    debug {
        minifyEnabled false
        applicationIdSuffix ".debug"
    }
    custom.initWith(buildTypes.debug)
    custom {
        applicationIdSuffix ".custom"
        versionNameSuffix "-customs"
    }
}复制代码

• 上述配置进行了一下设置

  1. 对默认的debug构建类型进行了修改，关闭了混淆配置，添加applicationId后缀
  2. 以debug为基础建立一个叫custom的构建类型（至关于继承了debug版本），在custom的构建类型中修改applicationId后缀，并添加了versionName的后缀

• 建立一个新的BuildType的步骤为：

  1. 在buildTypes容器下添加一个自定义名称的元素
  2. 调用initWith或者使用闭包进行配置点击查看BuildType的可配置属性

• 对于每个BuildType，Android plugin都会建立对应的“assembleBuildTypeName”任务

• 对于每个BuildType，均可以在dependencies容器中添加名为BuildTypeNameCompile的依赖配置

• 对于每个BuildType，Android plugin都会建立一个对应的sourceSet，默认位置为：src/BuildTypeName
  因此新建BuildType的名字不能是main、androidTest和test这三个已经被用的名字
  BuildType的代码/资源会以如下方式进行合并

  1. manifest会被合并到app的manifest文件中
  2. res目录下的资源文件会替换main里的资源文件
  3. java目录下的文件会被添加到main里的java目录中，因此不能和main里的类重名（含包名）

2. ProductFlavor

2.1 单维度的ProductFlavor

ProductFlavor定义了经过工程构建应用的自定义版本。一个独立的工程能够定义不一样的flavor改变生成的应用。
建立方式：

productFlavors {
    flavor1 {
        minSdkVersion 10
        versionCode 1
    }
    flavor2 {
        minSdkVersion 14
        versionCode 2
    }
}复制代码

• 上述配置进行了如下设置

  1. 新建了两个ProductFlavors，名字分别为flavor1和flavor2
  2. 从新设置了minSdkVersion和versionCode

• 建立一个新的ProductFlavor的步骤为：

  1. 在productFlavors容器下添加一个自定义名称的元素
  2. 使用闭包进行配置

2.2 多维度的ProductFlavor

某些状况下，咱们须要从多个维度来区分app的版本，好比渠道和是否付费，只是咱们就须要建立多维度的ProductFlavor来生成不一样的apk。
建立方式：

flavorDimensions "channle", "version"

productFlavors {
    huawei {
        dimension "channle"
    }

    xiaomi {
        dimension "channle"
    }

    free {
        dimension "version"
    }

    paid {
        dimension "version"
    }
}复制代码

• 上述配置进行了如下设置

  1. flavorDimensions定义了可能用到的维度和顺序
  2. 新建了四个ProductFlavor，每个ProductFlavor都指定了一个维度

• 建立多维度的ProductFlavor的步骤为：

  1. 使用flavorDimensions定义维度和顺序
  2. 在productFlavors容器下添加一个自定义名称的元素
  3. 使用闭包进行配置，必须指定ProductFlavor的维度点击查看ProductFlavor的可配置项

• 对于每个ProductFlavor，Android plugin都会建立对应的“assembleProductFlavorNameDebug”和“assembleProductFlavorNameRelease”任务

• 对于每个ProductFlavor，均可以在dependencies容器中添加名为ProductFlavorNameCompile的依赖配置

• 相似BuildType，Android plugin也会为ProductFlavor建立对应的sourceSet，默认的位置为：src/ProductFlavorName
  因此ProductFlavor的名字不能和已存在的BuildType的名字冲突
  ProductFlavor的代码/资源会以如下方式进行合并

  1. manifest会被合并到app的manifest文件中
  2. res目录下的资源文件会替换main里的资源文件
  3. java目录下的文件会被添加到main里的java目录中，因此不能和main里的类重名（含包名）

3. BuildVariant

BuildType和ProductFlavor相结合，组成了构建变体。每建立一个buildType或productFlavor，都会同时建立相应的变体。

3.1 单维度ProductFlavor时产生的BuildVariant

例如：

buildTypes {
    debug {
        minifyEnabled false
        applicationIdSuffix ".debug"
    }
    custom.initWith(buildTypes.debug)
    custom {
        applicationIdSuffix ".custom"
        versionNameSuffix "-customs"
    }
}

productFlavors {
    flavor1 {
        minSdkVersion 10
        versionCode 1
    }
    flavor2 {
        minSdkVersion 14
        versionCode 2
    }
}复制代码

上述配置的状况下会产生6个BuildVariant:

• flavor1Debug
• flavor1Release
• flavor1Custom
• flavor2Debug
• flavor2Release
• flavor2Custom

3.2 多维度ProductFlavor时产生的BuildVariant

若是是多维度的ProductFlavor，例如：

buildTypes {
    debug {
        minifyEnabled false
        applicationIdSuffix ".debug"
    }
    custom.initWith(buildTypes.debug)
    custom {
        applicationIdSuffix ".custom"
        versionNameSuffix "-customs"
    }
}

flavorDimensions "channle", "version"

productFlavors {
    huawei {
        dimension "channle"
    }

    xiaomi {
        dimension "channle"
    }

    free {
        dimension "version"
    }

    paid {
        dimension "version"
    }
}复制代码

上述配置的状况下会产生12个BuildVariant:

• huaweiFreeDebug
• huaweiFreeRelease
• huaweiFreeCustom
• huaweiPaidDebug
• huaweiPaidRelease
• huaweiPaidCustom
• xiaomiFreeDebug
• xiaomiFreeRelease
• xiaomiFreeCustom
• xiaomiPaidDebug
• xiaomiPaidRelease
• xiaomiPaidCustom

3.3 BuildVariant的使用

• 对于每个BuildVariant，Android plugin都会建立对应的“assembleBuildVariantName”任务

• BuildVariant的sourceSet合并规则：

  1. 全部的manifest会被合并到一个manifest文件中
  2. res目录下的资源文件会遵循优先级覆盖的原则：
     • BuildType会覆盖ProductFlavor
     • flavorDimensions中定义维度是的顺序，决定了ProductFlavor之间资源覆盖的顺序，顺序在在前的优先级越高，高优先级会覆盖低优先级的资源
     • ProductFlavor会覆盖main的资源文件
  3. java目录下的文件会被添加到main里的java目录中，若是所选的BuildVariant中BuildType和ProductFlavor对应的sourceSet中有同名的类，则会编译不经过