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