上一章我们已经介绍了Gradle脚本的基础，在其中我们也强调了Gradle中最要的Projects和Tasks这两个概念，尤其是Tasks，我们的所有Gradle的构建工作都是由Tasks组合完成的，那么这一章我们就详细的介绍下Tasks–任务。
任务的介绍也是从实用性出发，比如如何多种方式创建任务，如果访问任务的方法和属性等信息，如果对任务进行分组、排序，以及任务的一些规则性知识。

第一种是直接以一个任务名字创建任务的方式：

//1: 
def Task createTask1 = task(creatTask1)
//配置doLast方法
creatTask1.doLast{
    println "创建方法原型: Task task(String name)"    
}

第二种是以一个任务名字+一个对该任务配置的Map对象来创建任务：

//2: 任务名字 + 该任务配置的Map
def Task createTask2 = task(createTask2, group: BasePlugin.BUILD_GROUP)
createTask2.doLast{
    println "任务分组: ${createTask2.group}"    
}

和第一种方式大同小异，只是多了一个Map参数，用于对要创建的Task进行配置，比如我们例子里为其指定了分组为BUILD，我们通过执行该任务可以看到我们的配置其了作用。

Map中可用的配置

第三种方式就是任务名字+闭包配置的方式：

因为Map传参配置的方式（第二种）毕竟可配置的项有限，所以可以通过闭包的方式进行更多更灵活的配置，闭包里的委托对象就是Task，所以你可以使用Task对象的任何方法、属性等信息进行配置，比如示例中我们配置了任务的描述和任务执行后要做的事情。

Project中还有一种名字+Map参数+闭包的的方式，和上面演示的非常相似，就不列出了，下面我们说下TaskContainer创建任务的方式。如果我们去看Project对象中关于上面我们演示的task方法的源代码，就会发现其实他们最终都是调用TaskContainer对象中的create方法，其参数和Project中的task方法基本一样，我们下面看例子，我们使用这种方式重写第三种方式的例子：

tasks是Project对象的属性，其类型是TaskContainer，我们可以使用它来直接创建任务。对于关于TaskContainer其他几种创建方式和前面演示的Project的task方法基本上一样，就不一一写示例了，大家可以参考上面的练习写一下。

4.2 多种方式访问任务

首先呢，我们创建的任务都会作为项目(Project)的一个属性，属性名就是任务名，所以我们可以直接通过该任务名访问和操纵该任务：

通过索引访问的时候，任务名就是我们Key（关键索引），其实这里说key不恰当，因为tasks并不是一个Map，这里再顺便扩展下Groovy的知识，[]在Groovy中是一个操作符，我们知道Groovy的操作符都有对应的方法让我们重载，a[b]对应的是a.getAt(b)这个方法.

//直接通过该任务名访问和操纵该任务
task creatTask1{
    doLast{
        println 'doLast'
    }
}

tasks['creatTask1'].doLast{ 
    //通过路径访问, find找不到会返回null, 而get找不到会抛异常
    println tasks.findByPath(':creatTask1')
    //通过名字访问，通过的名称的访问也有get和find两种，区别和路径访问方式一样。
    println tasks.findByName('creatTask1')
}

值得强调的时候，通过路径访问的时候，参数值可以是任务路径也可以是任务的名字，但是通过名字访问的时候，参数值只能是任务的名字，不能为路径。
通过以上几种方式我们发现访问Gradle的任务非常方便，当我们拿到这个任务的引用的时候，我们就可以按我们的业务逻辑去操纵它，比如配置任务依赖，配置任务的一些属性，调用方法呢，这是Ant做不到的，这也是Gradle的灵活之处。

4.3 任务分组和描述

任务是可以分组和添加描述的，任务的分组其实就是对任务的分类，便于我们对任务进行归类整理，清晰明了。任务的描述就是说明这个任务有什么作用，是这个任务的大概说明。

建议大家创建任务的时候，这两个都要进行配置，便于其他人在看到的时候能很快的了解你定义任务的分类和通途。

def Task myTask = task task1
myTask.description = '这是一个构建的引导任务'
myTask.group = BasePlugin.BUILD_GROUP
myTask.doLast{
    println "group: ${group}, desc: ${description}"
}

4.4 <<操作符

详细读者们已经看到了我们很多例子中使用了这个操作符，这一小节我们就从源代码的角度来讲解下这个操作符，让大家对它有个更深入的了解。
<<操作符在Gradle的Task上是doLast方法的短标记形式，也就是说<<可以代替doLast

过时了吧

4.5 任务的执行分析

当我们执行一个Task的时候其实就是执行其拥有的Actions列表，这个列表保存在Task对象实例中的actions成员变量中，其类型是一个List。

接下来看实例

Task task1 = task(task1, type: CustomTask)
task1.doFirst{
    println "doFirst"
}
task1.doLast{
    println "doLast"
}
task1.doFirst{
    println "new doFirst"
}

class CustomTask extends DefaultTask{
    @TaskAction
    def doSelf(){
        println 'doself'
    }
}

Output

结果和我们期望的一样。我们前面讲了，执行Tasks的时候就是在遍历执行actions List，那么要达到这种doFirst、doSelf、doLast顺序的目的，就必须把doFirst的Actions放在actions List的最前面，把doSelf的Actions放在List中间，把doLast的Actions放在List最后面，这样才能达到按约定顺序执行的目的。

当我们使用task方法创建task1这个任务的时候，Gradle会解析其带有TaskAction标注的方法作为其Task执行的Action，然后通过Task的prependParallelSafeAction方法把该Action添加到actions List里：

doFirst和doLast这两个方法的实现代码

doFirst永远都是在actions List第一位添加，保证其添加的Action在现有actions List元素的最前面，doLast永远都是在actions List末尾添加，保证其添加的Action在现有actions List元素的最后面。一个往最前面添加，一个往最后面添加，最后这个actions List按顺序就形成了doFirst、doSelf、doLast三部分的Actions，就达到的doFirst、doSelf、doLast三部分的Actions顺序执行的目的。

这一小结是基于源代码对Task执行的分析，可能有点难，但是我还是建议大家仔细看，一遍看不懂多看几遍，结合着例子和源代码看，理解了对整个Task的执行就熟悉的多了。

4.6 任务排序

其实并没有真正的任务排序功能，这个排序不像我们想象的通过设置优先级或者Order顺序实现，而是通过任务的shouldRunAfter和mustRunAfter这两个方法来显示的，他们可以控制一个任务一定或者应该在某个任务之后执行，通过这种方式你可以在某些情况下控制任务的执行顺序，而不是通过强依赖的方式。

这个功能是非常有用的，比如我们公司自己设置的必须先执行单元测试，才能进行打包，这就保证了App的质量。类似情况还有很多，比如必须要单元测试之后才能进行集成测试；打包成功之后才能进行部署发布等。

taskB.shouldRunAfter(taskA) 表示taskB应该在taskA执行之后执行，这里的应该而不是必须，所以有可能任务顺序并不会按预设的执行。
taskB.mustRunAfter(taskA) 表示taskB必须在taskA执行之后执行，这个规则就比较严格。

task task1{
    doLast{
        println 'task1.doLast'
    }
}

task task2{
    doLast{
        println 'task2.doLast'
    }
}

task2.mustRunAfter(task1)

然后在此执行./gradlew task2 task1，查看输出

这个排序目前还属于Beta版，以后的Gradle版本可能会有变动，但是如果正好项目中遇到了类似的情况，不妨试试，很有用。

4.7 任务的启用和禁用

Task中有个enabled属性，用于启用和禁用任务，默认是true表示启用的，设置为false则禁止该任务执行，输出会提示该任务被跳过.

在某些情况下可以通过该属性灵活的控制任务的执行，这种方式需要在执行到具体逻辑的时候才能进行判断设置，下面我们讲一种提前设置条件的方式来控制任务执行还是跳过。

4.8 任务的onlyIf断言

断言就是一个条件表达式，Task有一个onlyIf方法，它接受一个闭包作为参数，如果该闭包返回true则该任务执行，否则则跳过。这有很多用途，比如控制哪些情况下打什么包，什么时候执行单元测试，什么情况下执行单元测试的时候不执行网络c而是等等，现在就以一个打首发包的例子来说明。

假如我们的首发渠道是应用宝和百度，直接执行build会编译出来所有包，这个太慢也不符合我们的需求，现在我们就采用onlyIf的方式通过属性来控制：
略

4.9 任务规则

我们通过以上章节知道了我们创建的任务都在TaskContainer里，是由其进行管理的。所以我们当我们访问任务的时候时候都是通过TaskContainer进行访问，而TaskContainer又是一个NamedDomainObjectCollection（继承它），所以我们说的任务规则其实是NamedDomainObjectCollection的规则。

NamedDomainObjectCollection是一个具有唯一不变名字的域对象的集合，它里面所有的元素都有一个唯一不变的名字，该名字是String类型，所以我们可以通过名字获取该元素，比如我们通过任务的名字获取该任务。

说完唯一不变的名字，我们再说规则，NamedDomainObjectCollection的规则有什么用呢？我们上面说了要想获取一个NamedDomainObjectCollection的元素是通过一个唯一的名字获取的，那么这个唯一的名字可能在NamedDomainObjectCollection中并不存在，具体到任务中就是说你想获取的这个任务不存在，这时候就会调用我们添加的规则来处理这种异常情况，我们看下源代码：

以名字查找的时候，如果没有找到则调用applyRules(name)应用我们添加的规则。
我们可以通过调用addRule来添加我们自定义的规则，它有两个用法：

一个是直接添加一个Rule，一个是通过闭包配置成一个Rule再添加，两种方式大同小异，如果仔细观察你会发现，Gradle中基本上都是这种写法，成对出现。

当我们执行、依赖一个不存在的任务时，Gradle会执行失败，失败信息是任务不存在，我们使用规则对其进行改进，当执行、依赖不存在的任务时，不会执行失败，而是打印提示信息提示该任务不存在：

此外它还可以根据不同的规则动态创建需要的任务等情况。

本文属自学历程, 仅供参考
详情请支持原书 Android Gradle权威指南