Gradle系列之Android Gradle基础配置
通过前面几篇文章学习了 Gradle 基础知识以及 Gradle 插件相关的知识，关于 Gradle 及其插件相关知识请先阅读下面几篇文章：
上篇文章了解了 Android Gradle 插件的一下配置方法，记得刚开始接触 Android 中的 build.gradle 配置文件也是一脸懵逼，不知道各个配置项的具体含义，这篇文章将对 Android 开发中一些最基本的配置进行介绍，如果你有这方面的疑惑，相信这篇文章对你有一定收获，主要内容如下：
默认配置
配置签名信息
构建应用类型
使用混淆
启用zipalign优化
默认配置
defaultConfig 是 Android Gradle 配置文件中的一个配置块，defaultConfig 的类型是 ProductFlavor，如果没有自定义 ProductFlavor，则使用默认的 ProductFlavor 来配置 Android 工程，下面对 defaultConfig 中的一下配置属性进行介绍：
1//默认的ProductFlavor配置块
2defaultConfig {
3 //配置App的包名
4 applicationId "com.manu.base"
5 //配合App最低支持的Android系统版本，下面两种minSdkVersion的配置效果是一致的
6 minSdkVersion 19
7 <!--minSdkVersion 'KitKat'-->
8 //配置App基于哪个Android SDK开发
9 targetSdkVersion 26
10 //配置App的内部版本号，一般用于版本升级
11 versionCode 1
12 //配置App外部版本号，该版本号供用户查看
13 versionName "1.0"
14 //配置单元测试时使用的Runner
15 testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
16 //配置测试App的包名
17 testApplicationId "com.manu.androidgradleproject.test"
18 //使用指定的签名文件配置
19 signingConfig signingConfigs.release
20}
配置签名信息
配置 App 签名信息的好处无非是防止 App 被恶意篡改，签名可保证 App 的唯一性且只有使用相同签名的后续升级包才能正常安装，在创建完签名文件之后，如果不做配置打包时每次都必须要指定签名文件的密码、别名等，一般 App 开发时在 denug 和 release 模式下时配置不同的签名文件。
第一步：创建签名证书文件,如下图所示填写相关信息:
第二步：使用 signConfigs 配置块配置已创建签名证书文件的相关信息如下：
1//签名文件配置
2signingConfigs {
3 release{
4 //签名证书文件
5 storeFile file("project.jks")
6 //签名证书文件密码
7 storePassword "111111"
8 //签名证书密钥别名
9 keyAlias "project_jks"
10 //签名证书中密钥密码
11 keyPassword "111111"
12 }
13 debug{
14 //默认情况下，debug模式下的签名已配置为Android SDK自动生成的debug签名文件证书
15 //默认签名文件位置：.android/debug.keystore
16 }
17}
第三步：使用签名文件配置，在 android{} 下 defaultConfig{} 中使用上述配置，具体如下：
1defaultConfig {
2 //...
3 //使用指定的签名文件配置
4 signingConfig signingConfigs.release
5}
除了在 defaultConfig{} 中配置，还可以在分别在 denbug 或者是 release 模式下配置不同的签名文件，可在 buildTypes{} 中单独配置配置，具体如下：
1buildTypes {
2 release {
3 signingConfig signingConfigs.release
4 //...
5 }
6 debug{
7 signingConfig signingConfigs.debug
8 //...
9 }
10
11 //...
12}
构建应用的类型
Android Gradle 内置了两种构建类型 debug 和 release，两者区别是前者一般用在调试状态，后者一般用于正式发布状态，其他方面都一样，那么如何增加新的构建类型呢，可直接在 buildTypes{} 中添加要添加的类型即可，buildTypes 接收的参数是一个域对象，添加的构建类型都是 BuildType，所以可以通过 BuildType 的相关属性来配置构建类型，下面是 BuildType 的常见的一些配置属性：
1buildTypes {
2 release {
3 //...
4 }
5 debug{
6 //配置签名
7 signingConfig signingConfigs.debug
8 //配置在当前构建类型下applicationId的后缀，构建生成Apk的包名会在applicationId的基础上添加后缀
9 applicationIdSuffix '.debug'
10 //配置是否生成一个可供调试的Apk
11 denbuggable true
12 //配置是否生成一个可供调试jni(c/c++)代码的Apk
13 jniDebuggable true
14 //是否启用proguard混淆
15 minifyEnabled true
16 //配置当程序中方法数超过65535个时，是否启用自动拆分多个dex的功能，
17 multiDexEnabled true
18 //配置proguard混淆使用的配置文件，可配置对个混淆文件
19 proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'
20 //配置是否自动清理未使用的资源,默认为false
21 shrinkResources true
22 //开启zipalign优化(见下文)
23 zipAlignEnabled true
24 }
25}
当在 buildTypes{} 中添加新的构建类型之后，Android Gradle 都会自动生成一个 SourceSet，构建 Apk 会从对应的 SourceSet 中进行构建，切记新构建类型的名称不能和已有的相同。且要在 src 目录下为新创建的构建类型添加源代码目录和资源文件等，在创建好构建类型的同时，Android Gradle 插件也会生成对应的 assemble 任务来用于构建该类型的项目，如 release 对应的是 assembleRelease，执行该任务会生成对应的 Apk.
使用混淆
代码混淆主要了增加反编译的难度，发布正式版 App 时一般都得进行代码混淆，实际上 Android SDK 下面已经提供了默认的混淆文件，具体位置在 Android SDK 下面的 tools/progrard 下面，里面的内容主要是一些最基本的不能混淆的内容，两个默认的混淆文件如下：
1//没优化
2proguard-android.txt
3//已优化
4proguard-android-optimize.txt
那么如何使用混淆呢，在 buildTypes{} 中对应的构建类型下设置 minifyEnabled 为 true 开启混淆，然后配置具体的混淆文件，具体如下：
1buildTypes {
2 release {
3 //开启混淆
4 minifyEnabled false
5 //配置混淆文件
6 proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
7 }
8 //...
9}
启用 zipalign 优化
zipalign 是 Android 提供的一个整理优化 apk 文件的工具，可在一定程度上上提高系统和应用的运行效率，更快的读取 apk 中的资源，降低内存的使用，开启 zipalign 优化只需要在 buildTypes{} 中对应的构建类型下开启 zipalign 优化即可，具体如下：
1buildTypes {
2 release {
3 //开启zipalign优化
4 zipAlignEnabled true
5 //''
6 }
7 //...
8}
这篇算介绍了 Android 开发中一些常见配置项的介绍，如果感觉有帮助，可以关注或点赞支持一下。
推荐阅读：