持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第15天，点击查看活动详情
本篇继续之前的 Gradle 系列，进一步学习一些配置
使用场景
默认情况下，Android Plugin 会自动给项目构建 debug 和 release 版本。两个版本的区别在于能否在安全设备（非 dev ）上调试，以及 APK 如何签名。debug 使用通过通用的 name/password 对生成的密钥证书进行签名（为了防止在构建过程中出现认证请求）。release 在构建过程中不进行签名，需要自行签名。
在项目中可以根据不同的构建类型赋予不同的权限，比如，只在 debug 模式下才允许打印日志，只在 release 在进行混淆、签名，在不同的模式下使用不同的资源，在不同环境下使用不同的服务配置等。
创建 BuildTypes
自定义一个 BuildTypes 的格式为： 名称{}
这些配置是通过 BuildType 对象来完成的。默认情况下，debug 和 release 实例都会被创建。Android plugin 允许像创建其他 Build Type 一样自定义这两种类型。在 buildTypes 的 DSL 容器中进行配置：
android {
buildTypes {
debug {
applicationIdSuffix ".debug"
}
jnidebug {
initWith(buildTypes.debug)// 复制
packageNameSuffix ".jnidebug"
jnidebugBuild true
}
}
}
- 上面的实例 配置了默认的 debug 版本，定义了应用 id 后缀
- 创建了名为 jnidebug 版本，以 debug 配置作为默认配置（initWith 函数，复制 build类型的属性）
- jnidebug 版本添加了包名后缀，并且开启了JNI 组件的debug 功能
可以在 buildTypes {} 中创建新的 BuildTypes，并且可以通过 initWith() 或者直接使用闭包来配置
代码及资源集合
BuildTyps 可以用于添加特定的代码及资源，每个 Build Type 会有默认的 sourceSet，路径为 src/<buildTypeName>/，比如 src/debug/java。BuildType 名称不能是 main 或者 androidTest（它们是 plugin 内部实现的）。
这个路径是可以被修改的
android {
sourceSets.buildtypename.setRoot('路径')
}
虽然路径是有默认的，但是文件夹是不会自动创建的，需要手动创建，结构可以像 main 文件夹一样。创建 AndroidManifest.xml 文件 或者 java、res 文件夹。
Task
每个 Build Type 都会创建一个新的 assemble 任务。例如：assembleDebug。 当 debug 和 release 构建类型被预创建的时候，assembleDebug 和 assembleRelease 会被自动创建。同样，有了新的 buildType 也会对应创建 assembleJnidebug task，并且 assemble 会依赖 assembleJnidebug。
buildType 的属性和方法
常用属性
| 属性 | 描述 |
|---|---|
| applicationIdSuffix | 应用 id 后缀 |
| name | build type的名字 |
| versionNameSuffix | 版本名称后缀 |
| minifyEnabled | 是否混淆 |
| proguardFiles | 混淆文件 |
| signingConfig | 签名配置 |
| multiDexEnabled | 是否拆成多个Dex |
常用方法
| 方法 | 描述 |
|---|---|
| buildConfigField(type, name, value) | 添加一个变量生成 BuildConfig 类 |
| consumerProguardFile(proguardFile) | 添加一个混淆文件进arr包 |
| consumeProguardFile(proguardFiles) | 添加混淆文件进arr包 |
| externalNativeBuild(action) | 配置本地的build选项 |
| initWith(that) | 复制这个 build 类型的所有属性 |
| proguardFile(proguardFile) | 添加一个新的混淆配置文件 |
| proguradFiles(files) | 添加新的混淆文件 |
| resValue(type, name, value) | 添加一个新的生成资源 |
| setProguardFiles(proguardFileIterable) | 设置一个混淆配置文件 |
启用 proguard 混淆
可以为不同的 buildTypes 选择是否启用混淆，一般 release 发布版本是需要启用混淆的，这样别人反编译之后就很难分析你的代码，而我们自己开发调试的时候是不需要混淆的，所以 debug 不启用混淆。对 release 启用混淆的配置如下：
android {
buildTypes {
release {
minifyEnabled true
proguardFile getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
- minifyEnabled 为 true 表示启用混淆，对应的 task 也将自动创建
- proguardFile 是混淆使用的配置文件
proguard-android.txt文件在 SDK 的路径下，使用 getDefaultProguardFile() 可以获取这些文件的完整路径。proguard-rules.pro在 module 根目录下。
启用 zipAlign
这个也是比较简单的，同样也是在 buildTypes 里配置，可以为不用的 buildTypes 选择时候开启 zipAlign
android {
buildTypes {
release {
zipAlignEnabled true
}
}
}
配置应用签名
要为应用配置签名信息需要在 android DSL 设置 signingConfigs {...} ，再在 buildTypes 中配置 signingConfig 即可
android {
signingConfigs {
release {
storeFile file("release.keystore")
keyAlias "tina"
keyPassword "123456"
storePassword "123456"
}
debug {
...
}
}
buildTypes {
release {
signingConfig signingConfigs.release
}
debug {
signingConfig signingConfigs.debug
}
}
}
其中
- storeFile：签名证书文件
- keyAlias：别名
- keyPassword：key的密码
- storePassword：证书的密码
配好相关信息即可在 buildTypes 配置使用
小结和预告
到这里介绍了如何创建一个新的构建类型，和相关常用的配置。和构建类型很相似的一个 DSL 还有构建变体，学会这个可以更灵活的定义编译版本。
