目录
一、前言
二、buildTypes
三、buildType
1、buildTypes存在形式
2、buildTypes 中属性的意义
3、buildTypes 中方法的意义
四、写在最后
一、前言
继 上一篇博客 分享了defaultConfig 中可配置参数的含义,今天我们来分享另一个我们也很熟悉的 buildTypes
。
二、buildTypes
buildTypes
也是存在于每个应用级模块中的 android 下的,即如下所示,是每次构建完项目之后自动生成的结构。
android {
buildTypes{
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
}
buildTypes 可以配置我们需要的构建类型,例如我们常用到的 “测试类型” 和 “本地类型”,则可以使用如下配置
buildTypes{
// 发布类型
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
// 测试类型,给测试人员
debug {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
// 本地类型,和后端联调使用
local {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
增加完这些配置后,我们可以在 android studio 看到多了 “debug” 和 “local” 两个可以构建的类型,在 “点击运行” 时,便会使用我们所选择的构建类型。假设此时选择的是 “debug” 类型,我们此时运行代码,则是 debug 下的配置参数。
![7dd992db-b030-eb11-8da9-e4434bdf6706.png](http://p04.5ceimg.com/content/7dd992db-b030-eb11-8da9-e4434bdf6706.png)
当然运行编译成 apk 时,也不例外,各自使用的也是各自类型的配置。
而这里所说的 “release”,“debug”,“local”,三个构建类型其实便是三个 buildType
,buildType
所能配置的参数便是我们今天要来捋清楚的。
三、buildType
buildType 官方文档
https://google.github.io/android-gradle-dsl/3.3/com.android.build.gradle.internal.dsl.BuildType.html
1、buildType存在形式
从上一篇博客我们知道,每个配置最终会被映射为一个类,或是一个属性、或一个方法。buildType
也不例外,他会被映射为 com.android.build.gradle.internal.dsl.BuildType
,继承结构如下
![7ed992db-b030-eb11-8da9-e4434bdf6706.png](http://p04.5ceimg.com/content/7ed992db-b030-eb11-8da9-e4434bdf6706.png)
我们重新看一下 DefaultConfig 的继承结构,可以看到都会继承到 BaseConfigImpl
类,说明两者会有一定的交集。这也说明了为什么我们看 gradle 文件时,总感觉一个配置参数哪里都能出现的情况(后面会进行更多的比较,来解除我们这种疑惑)
![7fd992db-b030-eb11-8da9-e4434bdf6706.png](http://p02.5ceimg.com/content/7fd992db-b030-eb11-8da9-e4434bdf6706.png)
2、buildType 中属性的意义
我们先来一个约定,避免使用的代码过于冗长。
buildTypes{
debug {
// 我们下面的 “使用方法” 代码都是基于这一块,除非特殊说明。
}
}
2.1 applicationIdSuffix
类型:String
描述:会追加在 applicationId 字符串的后面,形成最终的包名。
值得一提:在 defaultConfig 中也有这个属性,但一般不会使用。而会在 buildTypes 中使用,这样可以让包名不同,同时安装多个类型的应用。例如我们上面所提到的 release包、debug包、local包,都可以同时存在而不会覆盖,方便调试。
使用方法:
debug {
applicationIdSuffix '.debug'
}
2.2 consumerProguardFiles
类型:List< File >
描述:这个属性只作用于我们创建的
library
中,包括我们以aar形式导入的 library ,或是直接创建的 library。它的作用是,负责该 library 被进行编译时的混淆规则,我们在 主App 的模块下则可以不用再管理各个 library 的混淆规则,会直接使用各个 library 的混淆规则文件。值得一提:这个属性 和 proguardFiles 的区别在于,consumerProguardFiles 会被 主App模块 作为混淆文件使用导入,而 proguardFiles 则不会。
使用方法:
debug {
consumerProguardFiles 'consumer-rules.pro'
......省略其他配置
}
// 因为该属性是一个 List 类型,如果需要多个文件配置,则如下所示
debug {
consumerProguardFiles 'consumer-rules.pro','zincPower-rules.pro'
......省略其他配置
}
2.3 crunchPngs
类型:boolean
描述:是否对 PNG 图片进行压缩处理。设置为true时,会对未进行最