Gradle之构建变体(BuildVariant)

一、构建变体

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
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞