大家好,又见面了,我是你们的朋友全栈君。
前言
在前几篇中,讲解了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
到这里,我们应该大概对Gradle任务有所了解了,每一个任务task都是最小单位,而每个task里都有对应的actions。而Gradle构建就是每一个任务单位相互执行后的结果。
结束语
本篇讲解到这里就结束了,相信你对Gradle基础以及构建机制有所认知,在下一篇里,将会继续对Gradle进行深一步的讲解。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/154154.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...