一、构建变体

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中有同名的类，则会编译不通过