《Android群英传：神兵利器》个人读书笔记，仅做学习记录之用
第四章：与 Gradle 的爱恨情仇
Gradle 使用的是 DSL 语言，即领域特定语言
4.1 如何学习 Gradle
4.2 Gradle 初探
4.2.1 项目全局 build.gradle
4.2.2 Module build.gradle
apply plugin 领域
- Gradle 所引入的插件
android 领域
- 描述了该 Android module 构建过程中所用到的所有参数
dependencies 领域
- 描述了该 Android module 构建过程中所依赖的所有库
4.2.3 local.properties
- 这里配置了 Android Gradle 插件所需要使用的 Android SDK 路径
4.2.4 Gradle Task
-
assemble task
用于组合项目的所有输出，包含 assembleDubug 和 assembleRelease 两个Task。通过执行 gradle assemable 指令，Gradle 会编译出两个Apk——debug 和 release -
Check
用于执行检查任务 -
Build
类似一个组合指令，它执行了 Check 和 assemable 的所有工作 -
Clean
用于清理所有的中间编译结果
想要使用某个 task ，直接使用 gradle task_name 即可，例如：gradle clean
4.3 Gradle 进阶
4.3.1 更改项目结构
这边主要介绍将项目从 Eclipse 迁移到 Android Studio 的目录结构调整。当前Android Studio 的版本已经更新到 3.3 可以说是非常完善了，而 AS 也已成为主流。
4.3.2 构建全局配置
4.3.2.1 全局参数
在项目根目录的 build.gradle 中，通过 ext 领域可以指定全局的配置信息。
ext{
compilesdkVersion 23
buildToolsVersion '23.0.1'
minSdkVersion 19
targetSdkVersion 23
versionCode 1
versionName "1.0.0.1"
}
这样就不用在每一个 module 中单独配置了，利于管理
4.3.2.2 引用配置
设置好全局参数后，可以在每个 module 中使用这些配置
android {
compileSdkVersion rootProject.ext.compileSdkVersion
}
当然也可以把 ext 全局配置写在 allprojects 领域中，这样每个 module 就可以直接引用申明的变量了。但这样的话 Gradle 的版本更新通知检查机制就会失效。不过总的来说，利大于弊。
4.3.3 构建 DefaultConfig
4.3.4 构建 BuildTypes
4.3.5 构建 SigningConfigs
4.3.6 生成签名
Build/Generate Signed APK
6.1 配置签名
signingConfigs {
testSigning {
keyAlias 'testSigning.keystore'
keyPassword 'testSigning@123456'
storePassword 'testSigning@123456'
storeFile file('../../build/security/testSigning.keystore')
}
}
4.3.6.2 使用签名
testSigning {
applicationId "com.android.testSigning"
signingConfig signingConfigs.testSigning
}
4.3.7 Android 领域中的可选配置
4.3.7.1 compileOptions
配置编译的选项（设置 Java 的编译选项），通常可以在这里指定 Java 的编译版本
4.3.7.2 lintOptions
用于控制 Lint 代码检查。通过这个选项，可以在 Lint Check 发生 error 的时候继续编译
4.3.8 构建 Proguard
Proguard 配置是 Android 的 apk 混淆文件配置，它同样也可以 精简代码、资源，优化代码结构
buildTypes {
release {
minifyEnabled true // 是否混淆
proguardFiles 'proguard.cfg'
}
}
4.3.8 Gradle 动态参数配置
Gradle 给开发者提供了 gradle.properties 文件来配置动态的设置参数
4.3.9 System.properties 方式
4.3.9.1 key\value 方式
4.3.9.2 属性方式
4.3.9.3 系统参数
4.3.10 多渠道打包
所谓多渠道打包实际上就是在代码层面上标记不同的渠道名，从而便于统计不同的应用市场中该 App 的下载量
4.3.10.1 创建渠道占位符
在 AndroidManifest 文件的 Application 节点下创建
<meta-data
android:name="PRODUCT"
android:value="${CHANNEL_VALUE}"/>
${CHANNEL_VALUE} 就是要进行替换的渠道占位符
4.3.10.2 配置 Gradle 脚本
productFlavors {
test1{
applicationId "com.android.test1"
signingConfig signingConfigs.test1
manifestPlaceholders = [CHANNEL_VALUE: "test1"]
}
test2{
applicationId "com.android.test2"
signingConfig signingConfigs.test2
manifestPlaceholders = [CHANNEL_VALUE: "test2"]
}
test3{
applicationId "com.android.test3"
signingConfig signingConfigs.test3
manifestPlaceholders = [CHANNEL_VALUE: "test3"]
}
}
以上就是打包了三个不同的 apk
4.3.11 脚本优化
productFlavors {
test1{
applicationId "com.android.test1"
signingConfig signingConfigs.test1
// manifestPlaceholders = [CHANNEL_VALUE: "test1"]
}
test2{
applicationId "com.android.test2"
signingConfig signingConfigs.test2
// manifestPlaceholders = [CHANNEL_VALUE: "test2"]
}
test3{
applicationId "com.android.test3"
signingConfig signingConfigs.test3
// manifestPlaceholders = [CHANNEL_VALUE: "test3"]
}
}
productFlavors.all { flavor ->
flavor.manifestPlaceholders = [CHANNEL_VALUE: name]
}
增加的 productFlavors.all 领域对所有的 productFlavors 进行了遍历，并使其 name 作为渠道名
4.3.12 生成重命名包
// 编译时输出不同的apk名称，
applicationVariants.all { variant ->
variant.outputs.each { output ->
def outputFile = output.outputFile
if (outputFile != null && outputFile.name.endsWith('.apk')) {
//这里修改apk文件名
def fileName = "${variant.productFlavors[0].name}.apk"
output.outputFile = new File(outputFile.parent, fileName)
}
}
}
4.3.13 为不同版本添加不同的代码
4.4 Gradle 多项目依赖
Android Studio 提供了一种新的依赖方式——arr。通过 arr 方式，主项目可以像使用 jar 包一样使用这个库项目，并且这个 arr 项目中可以带有资源，相当于封装了一个可以使用完整源码的 jar 包。
4.4.1 jar 包依赖
jar 包依赖的重复管理，尽量将重复的 jar 包移动到主项目中，以避免重复依赖导致的编译问题
4.4.2 SO 库依赖
在 module/src/mian 中创建一个 jniLibs 目录即可
4.4.3 本地库项目依赖
4.4.3.1 创建 module
4.4.3.2 解析 Gradle 依赖库
- build.gradle： 控制每个 module 的编译过程
- gradle.properties： 设置 Gradle 脚本中的参数
- local.properties： Gradle 的 SDK 相关环境变量配置
- settings.gradle： 配置 Gradle 的多项目管理
4.4.4 远程仓库依赖
Gradle 支持以 arr 的方式依赖远程服务器上的库项目
4.4.4.1 远程仓库的配置
4.4.4.2 引用 Maven 中央库
4.4.4.3 引用本地服务器中央库
4.4.5 本地 arr 依赖
4.4.6 使用 Gradle 上传 arr 到 Maven 库
4.5 Gradle 依赖管理
4.5.1 Gradle 依赖库缓存
4.5.2 利用 Gradle 的通知机制
4.5.3 利用 Gradle 的依赖检查
4.5.4 Gradle 依赖传递
4.5.5 Gradle 依赖统一管理
4.6 Gradle 使用技巧
4.6.1 生成 Gradle 编译脚本
4.6.2 Gradle peer not authenticated
4.6.3 Gradle 性能检测
4.6.4 Gradle 加速
在 gradle.properties 文件中添加如下代码（表示开启 Gradle 的多线程和多核心支持）：
org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.configureondemand=true
然后将 build.gradle 中 javaMaxHeapSize 值增加到 4g（表示开启 Gradle 的增量编译，增加编译的内存资源到4g）
dexOptions {
javaMaxHeapSize "4g"
}
4.6.5 增加编译内存
4.6.6 Gradle 调用终端指令
4.6.7 使用 Gradle 精简资源
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles 'proguard.cfg'
}
}
其中 shrinkResources 依赖于 minifyEnabled 只有其开启时，才会生效
4.6.8 清除 Gradle 缓存
4.6.9 使用 Gradle 本地缓存
Setting-Build-Build Tools-Gradle 标签中选择 Offline work
4.6.10 Gradle 版本问题导致的编译错误
Setting-Build-Build Tools-Gradle 中设置 默认的 wrapper 或者选择 本地的 gradle
4.6.11 Gradle 资源冲突
4.7 Gradle 自定义插件
4.7.1 构建默认插件
4.7.2 构建自定义插件
4.8 Gradle 思考
4.8.1 Grovvy 初探
- Grovvy 是一种基于 JVM 的动态语言（可以在 Java 虚拟机上运行的脚本语言）
- Task 是 Grovvy 的核心，它是完成 Grovvy 任务的最小执行单元
4.8.2 Gradle 项目架构
4.8.3 Gradle 生命周期
- Initiliazatijon——初始化配置，即执行 settings.gradle 脚本
- Configration——解析每个 Project 中的 build.gradle 脚本
- Build——最后的编译阶段
4.9 使用 Android Studio 的图形化界面
此章节涉及的内容比较多，好多有用的东西，有时间还是可以自己去看看这本书的
网友评论