Gradle之构建变体（BuildVariant）

2019年6月9日 492次阅读 来源: zly394

一、构建变体

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中有同名的类，则会编译不通过
    原文作者：zly394
    原文地址: https://www.jianshu.com/p/98ee75dd49f4
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞