Gradle-任务
任务结果标签
当 gradle 执行一个任务时,它会在控制台和 tooling api 根据任务结果给任务打标签。
这些标签是根据任务是否有操作,是否应该执行操作,是否执行了操作以及这些操作做了哪些改变 来标记的。
下面是 gradle 的标签以及对应的条件
-
(无标签)或者 executed
任务执行了它的操作。- 任务有操作并且 gradle 已经决定作为构建的一部分来执行
- 任务没有操作但有些依赖,并且执行了某些依赖项。参考下面的生命周期任务。
-
up-to-date
任务输出没有变化- 任务有输入和输出,但没有改变。另行参考增量构建
- 任务有操作,但是没有改变它的输出。
- 任务没有操作但是有些依赖,但所有的依赖都是最新的,忽略的或者来自缓存。参考下面的生命周期任务
-
from-cache
任务的输出能够在先前的任务执行中被找到- 任务输出能够从缓存中恢复。具体的可另行参考
-
skipped
任务没有执行它的操作- 任务已经明确的在命令行中被排除。
- 任务的 onlyif 返回 false
-
no-source
任务不需要执行它的操作- 任务有输出和输入,但是没有来源。例如输入是空的。
在android studio 的 build console 就可以看到这个标签
tooling api 是指 gradle 提供的编程 api,通常给 ide,ci 服务器使用的
创建任务
最简单方便的定义方式:定义一个 hello 任务
这是使用 dsl 的语法
task hello { dolast { println 'hello world!' } }
这里的 task 看着像一个关键字,实际上是一个方法,这个方法的原型是 taskcontainer.create()
任务的创建就是使用这个方法给 project 添加一个 task 类型的属性,名字就是我们的任务名字;所以才能使用任务名字引用一些api,例如为任务添加额外的属性。
也可以使用一个字符串当做任务名称,指定一个类型
task('hello') { dolast { println "hello" } } task('copy', type: copy) { from(file('srcdir')) into(builddir) }
或者是直接使用 tasks.create 方法; tasks 是 project的一属性 类型是 taskcontainer
tasks.create('hello') { dolast { println "hello" } } tasks.create('copy', copy) { from(file('srcdir')) into(builddir) }
任务配置
在创建任务的的时候,可以传入参数对任务进行配置,比如 任务分组,任务描述等等
task(hello,group:'hello',description:'这是一个 hello。'){ dolast{ println "name:$name; group:$group; description:$description;" } }
输出如下
> task :hello name:hello; group:hello; description:这是一个 hello。; build successful in 694ms
也可以在闭包中对任务进行配置
task taskx{ group 'hello' description '在闭包里配置' dependson hello } tasks.create('tasky',copy){ description '使用 tasks.create()' dependson hello group 'hello' }
使用 gradle help --task 任务名
查看任务详情
可以配置的参数如下
配置项 | 描述 | 默认值 |
---|---|---|
type | 基于一个存在的 task 来创建,和我们的类继承差不多 | defaulttask |
dependson | 用于配置任务的依赖 | [] |
action | 添加到任务的一个 action 或者一个闭包 | null |
description | 任务描述 | null |
group | 任务分组 | null |
任务访问
通常是在配置任务或者是使用任务依赖的时候访问任务。
下面是几种获取任务引用的方式
使用 dsl 语法的方式
task hello task copy(type: copy) // access tasks using groovy dynamic properties on project println hello.name println project.hello.name println copy.destinationdir println project.copy.destinationdir
使用 tasks 集合访问
task hello task copy(type: copy) println tasks.hello.name println tasks.named('hello').get().name println tasks.copy.destinationdir println tasks.named('copy').get().destinationdir
使用 tasks.getbypath() 方法
可以在构建文件的任何地方使用这个方法,它接受任务名字,任务相对路径或者绝对路径。
project(':projecta') { task hello } task hello println tasks.getbypath('hello').path println tasks.getbypath(':hello').path println tasks.getbypath('projecta:hello').path println tasks.getbypath(':projecta:hello').path
输出如下
gradle -q hello
:hello :hello :projecta:hello :projecta:hello
当我们拿到这个任务的引用的时候,就可以按照我们的任务逻辑去操作它,比如配置任务依赖,配置任务的一些属性,调用方法等。
添加操作
可以使用 task.dolast 和 task.dofirst 为任务添加操作
其中 dofirst 是在任务之前执行,dolast 在任务之后执行
task taskz taskz.configure { group 'custom' description '添加操作的实验' } taskz.dofirst { println 'add dofirst. first' } taskz.dolast { println 'add dolast. first' } taskz.dolast { println 'add dolast. second' } taskz.dofirst { println 'add dofirst. second' }
执行任务 gradle taskz
gradle taskz
> task :taskz add dofirst. second add dofirst. first add dolast. first add dolast. second build successful in 608ms
从输出可以看到是先执行 dofirst 然后是 dolast 。
执行分析
任务的执行其实就是执行它的 actions 列表。
这个列表保存在 task 对象实例中的 actions 成员变量中,其类型是一个 list
private list<inputchangesawaretaskaction> actions;
现在我们把 task 之前执行、task 本身执行以及 task 之后执行分别称为 dofirst,doself,dolast。下面做个演示
class customtask extends defaulttask{ @taskaction def doself(){ println 'task 自己本身在执行 in doself.' } } task taska(type:customtask) taska.dofirst { println "do first. task 之前执行" } taska.dolast { println "do last. task 之后执行" }
例子中定义了一个 customtask 并声明了一个 doself 方法,使用 @taskaction 标注,意思是这是任务本身要执行的方法。
执行 taska 输出
> task :taska do first. task 之前执行 task 自己本身在执行 in doself. do last. task 之后执行 build successful in 726ms
前面说过任务执行就是执行它的 actions list。那么要达到这种 dofirst、doself、dolast 顺序的目的,就必须把 dofirst 的 actions 放在 actions list 的前面,把 doself 的 actions 放在 list 的中间,把 dolast 的 actions 放在 list 最后面,这样才能达到按约定顺序执行的目的。
当我们使用 task 方法创建 taska 这个任务的时候,gradle 会解析其带有 task action 标注的方法作为其 task 执行的 action,然后通过 task 的 prependparallelsafeaction 方法把该 action 添加到 actions list 里。
@override public void prependparallelsafeaction(final action<? super task> action) { if (action == null) { throw new invaliduserdataexception("action must not be null!"); } gettaskactions().add(0, wrap(action)); }
这个时候任务刚刚被创建,不会有 dofirst 的 action, actions list 一般是空的。
只有在创建任务时,传入了配置参数中的 action 选项配置的时候才会有。(上面配置任务有提到)
这个时候 actions list 就有了任务本身的 action了。
再来看 dofirst 和 dolast 两个方法的实现代码
@override public task dofirst(final action<? super task> action) { return dofirst("dofirst {} action", action); } @override public task dofirst(final string actionname, final action<? super task> action) { hascustomactions = true; if (action == null) { throw new invaliduserdataexception("action must not be null!"); } taskmutator.mutate("task.dofirst(action)", new runnable() { @override public void run() { gettaskactions().add(0, wrap(action, actionname)); } }); return this; } @override public task dolast(final action<? super task> action) { return dolast("dolast {} action", action); } @override public task dolast(final string actionname, final action<? super task> action) { hascustomactions = true; if (action == null) { throw new invaliduserdataexception("action must not be null!"); } taskmutator.mutate("task.dolast(action)", new runnable() { @override public void run() { gettaskactions().add(wrap(action, actionname)); } }); return this; }
看最重要的 actions.add 这部分
dofirst 永远都是在 actions list 第一位添加,保证其添加的 action 在现有的 actions list 的最前面。
dolast 永远都是在 actions list 末尾添加,保证其添加的 action 在现有的 actions list 元素的最后面。
一个往最前面添加,一个往最后面添加,最后这个 actions list 就形成了 dofirst,doself,dolast三部分的 actions.
也就保证了 dofirst,doself,dolast三部分的 action 顺序执行的目的。
这个任务执行分析在 《android gradle 权威指南》 中有很详细的解释。
任务排序
任务依赖也能够达到让任务排序的目的,但是还是有些区别的。
主要区别是排序不影响任务执行,只影响执行顺序。
有两种排序规则 “must run after” and “should run after”.
taska.mustrunafter(taskb) 表示 taska 必须总是在 taskb 之后运行。
taska.shouldrunafter(taskb) 表示 taska 应该在 taskb 之后运行,并不一定必须运行,没有那么严格。
should run after 不会被执行通常是在两个场景下
- 陷入顺序循环
- 在执行任务依赖的时候如果满足了这个规则,将不会再次执行了。例如 再执行 taskb 的依赖时将 taska 给执行了,那么在 taskb 完成后将不会再执行 taska。
must run after
task taskx { dolast { println 'taskx' } } task tasky { dolast { println 'tasky' } } tasky.mustrunafter taskx
> gradle -q tasky taskx taskx tasky
should run after
task taskx { dolast { println 'taskx' } } task tasky { dolast { println 'tasky' } } tasky.shouldrunafter taskx
> gradle -q tasky taskx taskx tasky
如果只执行一个任务的话顺序规则就没用了
gradle -q tasky
tasky
任务跳过
gradle 提供了多种方式跳过任务,任务被跳过将不会执行。
使用断言 onlyif
这个方法接收一个闭包参数,闭包返回 false 就不会执行,返回 true 将执行任务
这个方法是在执行任务前被调用的,不是在配置阶段。
task hello { dolast { println 'hello world' } } hello.onlyif { !project.hasproperty('skiphello') }
gradle hello -pskiphello
> task :hello skipped build successful in 0s
使用 stopexecutionexception
如果断言不能满足你的话,就可以使用这个 stopexecutionexception ,使用这个异常可以执行时根据逻辑进行判断。
这个异常可以在一个操作中抛出,抛出后直接跳过这个任务进行下一个任务。
task compile { dolast { println 'we are doing the compile.' } } compile.dofirst { // here you would put arbitrary conditions in real life. // but this is used in an integration test so we want defined behavior. if (true) { throw new stopexecutionexception() } } task mytask { dependson('compile') dolast { println 'i am not affected' } }
gradle -q mytask
i am not affected
使用 enabled = false
每个任务都有一个 enabled 标志,默认是 true,如果设置为 false 这个任务将会被标记为 skipped,直接跳过
task disableme { dolast { println 'this should not be printed if the task is disabled.' } } disableme.enabled = false
执行 gradle disableme
gradle disableme
task :disableme skipped build successful in 0s
使用 超时时间
每个任务都有一个 timeout 属性用来限制执行时间。
当任务执行超时,任务执行线程就会被终止,任务将会被标记失败。
如果使用了 --continues 其他任务将会继续执行。
如果任务不能响应超时,任务将不会被终止。
gradle 所有的内置任务都会响应超时。
task hangingtask() { dolast { thread.sleep(100000) } timeout = duration.ofmillis(500) }
任务规则
正常情况下在使用 gradle 执行任务时,如果任务不存在就会抛出异常。
而任务规则就是在 gradle 找不到任务时应用的规则,例如我们可以在找不到任务时打印一句话或者执行其他操作。
任务规则的添加和创建一样都是由 taskcontainer 完成,其实这个实在 nameddomainobjectcollection 接口中的,不过 taskcontainer 继承了这个接口。
tasks.addrule("这就是一个任务规则描述"){ taskname -> task (taskname){ println "$taskname 不存在" } }
这个 方法有多个重载,详情可查看 api。
api 传送门
生命周期任务
生命周期任务通常是没有操作的,通常是表达一个概念,例如下面几个:
- 一个步骤,例如 check 检查,build 构建;
- 一个可构建的东西,例如一个可执行文件
- 一个组合了多个逻辑任务的空壳任务,例如 使用 compileall 任务执行所有编译任务
base plugin 中定义了标准生命周期任务:
- check
- assemble
- build
几乎所有的核心语言插件都应用了 base plugin, 例如 java plugin。
所以它的生命周期任务几乎所有语言插件都有。
除非生命周期任务有操作,否则它的结果标记应该是由它的依赖的执行结果决定的。
如果所有的依赖都被执行了,那么就应该标记 executed
如果所有的依赖都是最新的,跳过的或来自缓存,那么就应该被标记为 up-to-date
上一篇: 深入理解 Handler 消息机制