Gradle学习4——深入了解Task和构建生命周期

2017-10-14  本文已影响151人  sososeen09

学习本系列前可以下载相关的github项目gradleLearnDemo。
地址：https://github.com/sososeen09/gradleLearnDemo

1 声明Task

默认情况下，每个新创建的task都是org.gradle.api.DefaultTask类型的，它是标准的org.gradle.api.Task 实现。DefaultTask的所有属性都是private的，只能通过getter和setter方法来访问。

幸运的是，Groovy提供了一些语法糖，可以直接通过属性名来使用属性。在底层，Groovy会为你调用这些方法。

一个简单的task可以是这样，

version ='0.1-SNAPSHOT'
task printVersion {
    doLast{
      println "Version: $version"
    }
}

执行gradle printVersion 命令，结果是

:printVersion
Version: 0.1-SNAPSHOT

如果换成doFirst，执行的结果也是一样的。

task printVersion {
    doFirst{
      println "Version: $version"
    }
}

2 给现有的Task添加动作

task在创建后，可以根据需要添加很多动作，在内部，每个task都保持了一个动作列表，在运行时，它们按顺序执行。

version ='0.1-SNAPSHOT'

// 声明一个包含doFirst和doLast的task
task printVersion {
    doFirst{
      println "Before reading the project version"
    }

    doLast{
      println "Version: $version"
    }
}

//在动作列表的开始添加doFirst闭包
//在动作列表的最后添加doLast闭包，采用别名的方式
printVersion.doFirst {println "First action"}
printVersion<<{println "Last action"}

执行gradle printVersion 命令，结果是：

:printVersion
First action
Before reading the project version
Version: 0.1-SNAPSHOT
Last action

如上所示，可以给现有的task添加一些动作，这在你想要为不是自己编写的task执行自定义逻辑时非常有用。比如，为Java插件的compileJava task添加一个doFirst动作来检查项目中至少包含一个Java源文件。

3 访问DefaultTask属性

Gradle提供了一个基于SLF4J日志库的logger实现。除了常规的日志级别如DEBUG、ERROR、INFO、TRACE、WARN，之外Gradle还增加了一些额外的日志级别。通过Task的方法可以直接访问logger实例。例如，打印QUIET日志级别的版本号：

version ='0.1-SNAPSHOT'
task printVersion << {
  logger.quiet "Version: $version"
}

Task还有两个属性：description和group。description属性用于描述任务的作用，而group属性则用于定义task的逻辑分组。
创建task的时候可以为这两个属性设置值作为参数。

task printVersion(group: 'versioning',description:'Print project version' ) << {
  logger.quiet "Version: $version"
}

也可以通过setter方法来设置属性：

task printVersion{
  group = 'versioning'
  description = 'Print project version'
  doLast{
    logger.quiet "Version: $version"
  }
}

执行 gradle task 命令，可以看到task正确的分组和描述

Versioning tasks
----------------
printVersion - Print project version

尽管设置task的描述和分组和可选的，但是为所有的task指定description和group是一个比较好的实践，这会帮助用户比较容易的去识别task的功能。

4 定义task依赖

dependsOn方法允许声明依赖一个或多个task。

version ='0.1-SNAPSHOT'
task first << { println 'first'}
task second << { println 'second' }

//指定多个task依赖
task printVersion(dependsOn :[second,first]) << {
    logger.quiet "Version: $version"
}

//task third(dependsOn : printVersion) <<{
//    println 'third'
//}

//还可以采用这样的方式
task third <<{ println 'third'}
third.dependsOn('printVersion')

执行gradle -q third 结果如下：

first
second
Version: 0.1-SNAPSHOT
third

看到执行结果会有一点点意外，printVersion任务的依赖是second和first，为什么不是先执行second再执行first呢？在Gradle中，task执行顺序是不确定的。

5 Task的执行顺序

理解Gradle并不能保证task依赖的执行顺序是很重要的。dependsOn方法只是定义了所依赖的task需要先执行。Gradle的思想是声明在一个给定的task执行之前什么该被执行，而没有去定义它该如何执行。在Gradle中，执行顺序是由task的输入/输出规范自动确定的。

好处：

  1. 不需要知道整个task依赖链上的关系是否发生改变，这样可以提高代码的可维护性和避免潜在的破坏。
  2. 因为构建没有严格的执行顺序，也就是支持task的并行执行，这样可以极大地节约构建执行时间。

6 理解task配置

在Gradle脚本中可以定义通用的Groovy代码的功能。Groovy中只需要声明属性，不需要添加访问权限修饰符。getter和setter方法本质上是在生成字节码时自动添加的，运行时可以直接使用。

version=new ProjectVersion(0,1)
class ProjectVersion{
    Integer major
    Integer minor
    Boolean release

    ProjectVersion(Integer major, Integer minor){
       this.major=major
       this.minor=minor
       this.release=Boolean.FALSE
    }

    ProjectVersion(Integer major, Integer minor, Boolean release){
       this.major=major
       this.minor=minor
       this.release=release
    }

    @Override
    String toString(){
      "$major.$minor${release?'': '-SNAPSHOT'}"
    }
}

task printVersion << {
  logger.quiet "Version: $version"
}

运行 gradle printVersion ，得到的结果与之前相同。

我们也可以使用配置文件来设置属性。
例如新建一个version.properties文件。

major = 0
minor = 1
release = false

对应的version就是0.1-SANPSHOT

然后可以添加task的配置块

// Project接口提供了file方法，它会创建一个相对于项目目录的java.io.File实例
// versionFile是一个扩展属性
ext.versionFile=file('version.properties')

//没有使用左移操作符定义task配置
task loadVersion{
    project.version=readVersion()
}

//readVersion方法，注意：这个是方法，而不是task
ProjectVersion readVersion(){
    logger.quiet 'Reading the version file'
    if(!versionFile.exists()){
        throw new GradleException ("Required version file dose not exist:$versionFile.canonicalPath " )
    }

    //Groovy的文件实现通过添加新的方法来读取InputStream
    Properties versionProps=new Properties()
    versionFile.withInputStream{stream->
        versionProps.load(stream)
    }
    // 在Groovy中，如果return是方法中的最后一条语句的话，则可以将它省略
    new ProjectVersion(versionProps.major.toInteger(),versionProps.minor.toInteger(),versionProps.release.toBoolean())
}

运行 gradle printVersion，会看到 loadVersion 中的代码执行了。尽管 loadVersion 这个task的名字没有打印出来，但是可以看到打印日志了。

Reading the version file
:printVersion
Version: 0.1-SNAPSHOT

我们不禁疑问，为什么我们没有执行 loadVersion 这个task，也没有声明依赖关系，但是它内部的代码依然被执行了呢？
原因就是我们在loadVersion这个task闭包中的project.version=readVersion()属于task配置块，而task配置块永远在task动作执行之前被执行，只要触发构建，脚本文件中的所有task配置块都会执行，这牵涉到了Gradle的构建生命周期问题。

注意区分 配置块和action是不同的，task的action一般就是doFirst和doLast。

7 构建生命周期阶段

无论什么时候执行Gradle构建，都会运行三个不同的生命周期阶段：初始化、配置和执行。

Gradle生命周期示意图.png

初始化阶段，Gradle为项目创建了一个Project实例。给定的构建脚本只定义了一个项目，在多项目构建中，这个构建阶段变得更加重要。根据正在执行的项目，Gradle找出哪些项目依赖需要参与到构建中。

注意：在这个构建阶段当前已有的构建脚本代码都不会被执行。

配置阶段，Gradle构造了一个模型来表示任务，并参与到构建中来。增量式构建特性决定了模型中的task是否需要被运行。这个阶段非常适合与为项目或执行task设置所需的配置。

注意：项目每一次构建的任何配置代码都可以被执行——即使你只执行gradle tasks

执行阶段，所有的task都应该以正确的顺序被执行。执行顺序是由它们的依赖决定的。如果任务被认为没有修改过，将被跳过，这个牵涉到增量式构建，我们下一篇再讲。

上一篇下一篇

猜你喜欢

热点阅读