[移动开发] Android—Gradle教程（一）

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 移动开发 -> Android—Gradle教程（一） -> 正文阅读

[移动开发]Android—Gradle教程（一）

前言

在前几篇中，讲解了Groovy的基础语法，学习新语法过程总是枯燥的，但为了更好的掌握Gradle，那就必须经过该过程。当然从这一篇将会从零基础开始，开展对Gradle的讲解。

1. 掌握Gradle基础

1.1 环境配置

去官网下载gradle或者从本地用户文件夹下的.gradle/wrapper/dists找到本地缓存的gradle开发工具包 (注意带bin文件夹的这个grade-x.x)
系统属性配置：

添加GRADLE_HOME：C:\Users\sheji.gradle\wrapper\dists\gradle-6.5-all\gradle-6.5
添加Path：%GRADLE_HOME%\bin

检查配置

CMD 命令窗口输入 gradle -v，看看是否显示当前Gradle版本

在这里插入图片描述

1.2 Hello Gradle!

我们学习任何开发语言，第一个程序都离不开Hello 程序。所以仪式感还是要有的。

在工程文件夹下，创建一个build.gradle文件：

在文件里写入代码

task hello{
	println 'Hello, Gradle!'
}

打开cmd终端，移动到工程目录下，执行命令：> gradle -q hello
最终效果

如图所示

当运行成功时，将会自动创建.gradle文件夹。

此时我们继续在这个命令窗口执行命令：gradle wrapper
将会看到
在这里插入图片描述
如图所示

在本目录里面，系统自动帮我们创建了一系列文件以及文件夹，这些文件都似曾相识，打开AS和idea对比一下，发现目录里面有的对应编译器都会有。

这就是一个很标准的gradle工程目录结构：

gradlew和gradlew.bat分别是Linux和Windows下的可执行脚本，具体业务逻辑是在/gradle/wrapper/gradle-wrapper.jar中实现，gradlew最终还是使用Java执行这个jar包来执行相关的Gradle操作的。

1.2.1 gradle-wrapper.properties解读

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-6.1.1-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

这段代码就是这个文件里面的内容，现在将逐一进行解读

distributionBase：下载的Gradle压缩包解压后存储的主目录
distributionPath：相对于distributionBase的解压后的Gradle压缩包的路径
distributionUrl：Gradle发行版压缩包的下载地址
- -bin：二进制发布版
- -all：bin基础上还包含了源码和文档
zipStoreBase：同distributionBase，只不过存放的是zip压缩包的
zipStorePath：同distributionPath，只不过存放的是zip压缩包的

而 distributionBase对应的值为：GRADLE_USER_HOME

1.2.2 GradleUserHome 属性解读

默认路径在~/.gradle/ ，不建议使用本地maven的m2替代，因为原本的.gradle目录下的模块分的很清晰，功能明确
如果启动时，指定参数，使用别的目录代替GradleUserHome ，后果是每次构建需要重新下载插件与依赖到新的目录
默认情况下，gradle运行时，除了和项目打交道，还有当前项目构建的全新的GradleUserHome目录，所有jar包都得重新下载

1.3 Gradle部分命令行

gradlew -?/-h/-help 使用帮助
gradlew tasks 查看所有可执行Tasks
gradlew --refresh-dependencies assemble 强制刷新依赖
gradlew cBC 等价与执行Task cleanBuildCache，这种通过缩写名快速执行任务
gradlew :app:dependencies 查找app工程依赖树

2. 熟悉Gradle构建机制

2.1 熟悉setting.gradle的作用

我们继续看 Java、Android工程目录
在这里插入图片描述
如图所示

这里我们看到：这个俩个工程目录比刚刚多了个setting.gradle文件，现在来单独说明下这个文件具体有啥作用：

Gradle支持多工程构建，使用settings.gradle来配置添加子工程(模块)
settings文件在初始化阶段执行，创建Settings对象，在执行脚本时调用该对象的方法
Settings.include(String… projectPaths)
- 将给定的目录添加到项目构建中，’:app’表示文件相对路径，相当于’./app’文件夹
- 多项目架构进行分层，把同层次的子工程放在同一文件夹下便于管理，使用’:xxx:yyy’表示

刚刚也说明了，settings文件在初始化阶段执行，那么其他阶段有哪些呢？这就要从Gradle生命周期开始说起了。

2.2 熟悉Gradle生命周期

Gradle生命周期无非就是这三个：Initialization、Configuration、Execution

Initialization
- Gradle支持单项目和多项目构建。在初始化阶段，Gradle确定哪些项目将参与构建，并为每个项目创建Project实例，一般我们不会接触到它。(比如解析settings.gradle)
Configuration
- 配置阶段，解析每个工程的build.gradle文件，创建要执行的任务子集和确定各种任务之间的关系，并对任务的做一些初始化配置。
Execution
- 运行阶段，Gradle根据配置阶段创建和配置的要执行的任务子集，执行任务。

而这三个生命周期又与执行流程息息相关。

2.3 熟悉Gradle执行流程

在这里插入图片描述
如图所示

从这张图可知，不同的阶段都有对应方法的调用顺序，在这里我们暂可熟悉这些即可：

初始化阶段里面的Setting.gradle
配置阶段的所有
执行阶段的所有

刚刚已经讲解了setting.gradle的作用，现在接着讲解配置阶段相关的内容。

2.4 熟悉Gradle配置阶段

解析每个Project中的build.gradle，解析过程中并不会执行各个build.gradle中的task。
经过Configration阶段，Project之间及内部Task之间的关系就确定了。一个Project包含很多Task，每个Task之间有依赖关系。Configuration会建立一个有向图来描述Task之间的依赖关系，所有Project配置完成后，会有一个回调project.afterEvaluate()，表示所有的模块都已经配置完了。

因为这里配置阶段和Gradle对应的Task（任务列表）相互绑定，所以这里不好拿代码单独解释配置相关的方法，需要结合Gradle任务一起讲，所以这里先忍耐一下，等讲完Task(任务列表)后，再一起解析。

2.5 熟悉Gradle任务

Gradle Task：

task是gardle中最小的任务单元，任务之间可以进行复杂的操作（如动态创建任务，多任务间依赖调用等等)。gradle的执行其实就是由各种任务组合执行，来对项目进行构建的
使用gradlew help命令，任何gradle项目都有一个该task，可以执行此命令观察taks执行的流程是否如预期
可以使用工具查看，还可以通过 gradlew tasks 命令查看可运行任务。
- 使用gradlew tasks --all 命令查看所有任务
- 使用gradlew A B 命令表示执行任务A和B，支持驼峰简写

注：task是gardle中最小的任务单元，犹如我们现在所常用的金钱单位0.01元一样（别钻牛角尖）。

概念都说了一大堆，接下来就到了愉快的撸码验证环节了。

创建java环境下的Gradle工程项目，进入build.gradle


this.beforeEvaluate {
    println "this.beforeEvaluate"
}
//等同beforeEvaluate
this.gradle.beforeProject {
    println "this.beforeProject"
}

this.afterEvaluate {
    println "this.afterEvaluate"
}
//等同配置阶段完成后
this.gradle.afterProject {
    println "this.afterProject"
}


this.gradle.taskGraph.whenReady{
    println "whenReady"
}

// Gradle3.0 << ，在4.x以上就废弃了
task A {

    println "configuration A.."

    doFirst {
        println "doFirst A.."
    }

    doLast {
        println actions
        println "doLast A1.."
    }

}

task B{
    println "configuration B.."

    doFirst {
        println "doFirst B.."
    }

    doLast {
        println actions
        println "doLast B1.."
    }
}

this.gradle.buildFinished {
    println "buildFinish"
}

代码解析

这里面开头那几个this指向对应的方法，就是刚刚我们执行流程图对应的方法，过后又定义了两个task任务单元，里面分别对不同的action有不同的打印输出，接下来我们看看运行效果：

运行效果一：运行taskA

在这里插入图片描述
如图所示

点击右边任务列表中的task或者点击左侧对应task的运行按钮

> Configure project :
configuration A..
configuration B..
this.afterProject
this.afterEvaluate
whenReady

> Task :A
doFirst A..
[org.gradle.api.internal.AbstractTask$ClosureTaskAction@261ae6e0, org.gradle.api.internal.AbstractTask$ClosureTaskAction@76e733fb]
doLast A1..
buildFinish

我们发现在配置阶段，两个Task里面的 configuration 都被打印了出来，随后就打印了配置结束的方法，以及准备进入到执行阶段的whenReady方法。因为运行的A任务，所以随后就进入了taskA的执行阶段，在执行阶段里，优先运行的doFirst 其次是doLast 对应的action，最后如愿的调用了buildFinish方法来结束整个Gradle编译。

不过这里有个小瑕疵：运行发现，配置前的beforeEvaluate、beforeProject对应方法并没有打印出来，如有知情的大佬知道其原因欢迎相互交流。不过这并不影响我们的发挥，因为每个任务的配置代码在构建的时候都会执行。

我们发现，单独运行A或者B的时候，配置阶段都执行了对应任务里面的配置，唯独运行没有一起运行，而我们在使用Android Gradle的时候，都是扒拉扒拉全运行完，就像配置阶段一样。那我们要怎样做呢？

task A {

    println "configuration A.."

    doLast {
        println actions
        println "doLast A1.."
    }

}

task B{
    println "configuration B.."

    doLast {
        println actions
        println "doLast B1.."
    }
}

A.dependsOn B

在这里我这只加了 A.dependsOn B 这段代码，看着意思就有点像，A继承B，运行一下A试试：

> Configure project :
configuration A..
configuration B..

> Task :B
[org.gradle.api.internal.AbstractTask$ClosureTaskAction@213f5745]
doLast B1..

> Task :A
[org.gradle.api.internal.AbstractTask$ClosureTaskAction@70cabab9]
doLast A1..

我们发现，运行A的时候，两者都一起运行了，但是问题来了，当我运行B的时候，又变成了单独运行，而且如果出现多个task怎么办呢？总不能相互 dependsOn 吧？

接下来又对代码进行一系列改造：

task A {

    println "configuration A.."

    doLast {
        println actions
        println "doLast A1.."
    }

}

task B{
    println "configuration B.."

    doLast {
        println actions
        println "doLast B1.."
    }
}

task C {
    println "configuration C.."

    doLast {
        println "doLast C.."
    }
}

task hello2(dependsOn: [A, C, B]) {
    doLast {
        println "doLast hello2"
    }
}

这里我们看出，这里定义了新的任务hello，随后将已存在的task通过数组的形式相互绑定，换句话说，就是定义了一个管理类，将所有零散的任务单元全部管理了其他，想运行所有任务单元，只需要运行这个管理类即可。所以运行一下hello2任务单元试试：

> Configure project :
configuration A..
configuration B..
configuration C..

> Task :A
[org.gradle.api.internal.AbstractTask$ClosureTaskAction@40880123]
doLast A1..

> Task :B
[org.gradle.api.internal.AbstractTask$ClosureTaskAction@111c4be4]
doLast B1..

> Task :C
doLast C..

> Task :hello2
doLast hello2

BUILD SUCCESSFUL in 0s
4 actionable tasks: 4 executed
18:33:17: Task execution finished 'hello2'.

在代码里，我特意将 B和C相互兑换位置，结果发现，运行单位元，就是按照字母排序的方式依次运行。

现在又有新的问题，我们在使用任何对象的时候，使用完了都会被回收掉，那么任务执行完了，是不是也会有对应的回收任务？那该使用什么关键字呢？

接下来继续改造代码：

task A {

    println "configuration A.."

    doLast {
        println actions
        println "doLast A1.."
    }

}

task B{
    println "configuration B.."

    doLast {
        println actions
        println "doLast B1.."
    }
}

task C {
    println "configuration C.."

    doLast {
        println "doLast C.."
    }
}

task hello2(dependsOn: [A, C, B]) {
    doLast {
        println "doLast hello2"
    }
}

task finalized {
    doLast {
        println "clear all tasks"
    }
}

hello2.finalizedBy finalized

这里我们看到，又新增了一个task，里面表示执行清理逻辑，随后使用了 finalizedBy 关键字将，任务总管理和清理任务相互关联，运行效果看看

> Configure project :
configuration A..
configuration B..
configuration C..

> Task :A
[org.gradle.api.internal.AbstractTask$ClosureTaskAction@25b5129e]
doLast A1..

> Task :B
[org.gradle.api.internal.AbstractTask$ClosureTaskAction@74447d23]
doLast B1..

> Task :C
doLast C..

> Task :hello2
doLast hello2

> Task :finalized
clear all tasks