了解 Gradle 和 buildType Task

什么是Gradle

Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建开源工具。它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置，目前也增加了基于Kotlin语言的kotlin-based DSL，抛弃了基于XML的各种繁琐配置。面向Java应用为主。当前其支持的语言C++、Java、Groovy、Kotlin、Scala和Swift，计划未来将支持更多的语言。

以上是百科对Gradle的介绍，如果了解Ant或Maven的话，差不多会理解，就是一个构建工程的工具。一个Android工程要打包成APK文件需要很多步骤(依赖,打包,部署，签名,发布,各种渠道的差异管理.....)，而Grdle就是这样一个用来管理打包过程的工具。所以Gradle不是一门语言，它只是一个工具，可以用很多语言来完成它的工作。

初识Gradle

// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
  repositories {
    google()
    jcenter()
  }
  dependencies {
    classpath 'com.android.tools.build:gradle:4.0.1'

    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files
  }
}

allprojects {
  repositories {
    google()
    jcenter()
  }
}

task clean(type: Delete) {
  delete rootProject.buildDir
}

这是我们创建Android工程自动创建的project下的build.gradle文件

第一次见到会觉得内容结构像是配置文件，跟Java的写法差别很大，不过如果改写一下，可能会更容易理解,我们选取一段改下：

dependencies ({
    classpath 'com.android.tools.build:gradle:4.0.1'
  })

这种写法如果是熟悉Kotlin的同学一眼就能看出来，这不就是Lambda吗？完全正确，Grovy的这种语法称为闭包(Closure) ,其作用与Lambda很相似，核心目的就是传递一个方法（或函数） 。

void method(Closure closure){
  ...
}

method ({
  println("execute closure")
})

上面就是Grovy的闭包定义语法，如果闭包为方法的最后一个参数，则可以省略圆括号，就像默认build.gradle文件内容一样。这样我们就知道原来这些不是配置，只是写法类似配置而已，其buildscript{}、repositories{} 等等都是方法调用，并且我们可以看看这些方法是怎么定义的。

    /**
     * Configures the repositories for the script dependencies. Executes the given closure against the {@link
     * RepositoryHandler} for this handler. The {@link RepositoryHandler} is passed to the closure as the closure's
     * delegate.
     *
     * @param configureClosure the closure to use to configure the repositories.
     */
    void repositories(Closure configureClosure);
    
    /**
     * Configures the repositories for the script dependencies. Executes the given closure against the {@link
     * RepositoryHandler} for this handler. The {@link RepositoryHandler} is passed to the closure as the closure's
     * delegate.
     *
     * @param configureClosure the closure to use to configure the repositories.
     */
    void repositories(Closure configureClosure);

可以看到我上面说的语法一样,但是，其实，不过也确实有一些例外，比如：

classpath 'com.android.tools.build:gradle:4.0.1'

这里的classPath跟其他的方法不一样，找不到这个方法，这其实是Grovy的一个机制，叫methodMissing,就是在方法调用的时候如果找不到方法，那么会去调用methodMissing()这个方法，最终在这个方法内处理逻辑。关于methodMissing这边不多做介绍，感兴趣的可以去了解下。

关于 buildTypes

buildTypes默认有两个方法debug和release，但实际上是可以自定义的，命名随意，比如testing

buildTypes {
    internal {
        //TODO
    }
    debug {
        //TODO
    }
    release {
      minifyEnabled false
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
  }
}

从buildTypes的默认方法debug和release我们不难看出，这一般是用来区分生产和测试版本。我们在编译时可以执行gradle assembleInternal/assembleDebug/assembleRelease命令，而执行这些命令不仅仅执行buildTypes下的这三个方法，如果在src目录下有internal/debug/release目录时，也会同时把对应目录打包到工程。比如执行 assembleInternal时会把src下的main和internal两个目录打包。我们可以用这个特性来对不同的app版本做差异化定制。

api,impementation,compileOnly

api 跟以前的compile完全一样，能传递依赖，即子module的依赖会带到主module
implementation 不传递依赖，只在当前module生效
compileOnly 只在编译时有效，不会参与打包

gradle wrapper

gradlew会根据gradle-wrapper.properties文件去下载对应的gradle版本

Task

我们来看一段gradle代码

println(rootProject.buildDir)

task clean(type: Delete) {
  delete rootProject.buildDir
}

然后执行./gradlew

> Configure project :
D:\work******\build

可以看到打印了build的目录

我们换一种写法，再试试

task clean(type: Delete) {
  println(rootProject.buildDir)
  delete rootProject.buildDir
}

然后再执行./gradlew 我没有执行clean task，所以正常是不应该打印的吧，我们来看看结果；

> Configure project :
D:\work******\build

纳尼？什么鬼？没执行task也会执行task里面的代码么？？但是为什么build目录没有被删除呢？这也太奇怪了吧!!

我相信多数人看到这里都会觉得很奇怪，方法难道能只执行某几行？其实并不是这样，clean task中的代码其实都执行了，只是在执行到delete的时候会把它放到task列表中，在调用clean之后再去真正执行删除逻辑。我们可以把添加到任务列表时的工作当作是配置操作，在调用clean时才是真正的执行操作。

看到这有人就会想，那我如果要在task执行完毕之后输出提示日志，那该怎么做呢？如果在task最后执行，虽然日志输出了，但肯定不是任务执行之后输出的。那我们该怎么做呢？可以用doLast doFirst方法来打印执行时的日志

task clean(type: Delete) {
  println(1)
  delete rootProject.buildDir
  println(2)
  doLast {
    println "执行完毕"
  }

  doFirst {
    println "开始执行"
  }
}

> Configure project :
1
2

> Task :clean
开始执行
执行完毕

从输出的日志也能看出task执行有两个阶段：配置和执行。

task调用其他task用denpendsOn

task taskA(){
  doLast{
    println"taskA executed"
  }
}

task taskB(dependsOn:taskA){
  doLast {
    println "taskB executed"
  }
}

这种写法表示执行taskB之前会执行taskA，如果taskA也有依赖，那也会先执行taskA的依赖，就这样一直递归。这就是一个依赖关系网，被称作有向无环图。

gradle执行流程

setting.gradle
各个build.gradle的配置阶段绘制有向无环图
执行阶段

gradle plugin

一个简单的自定义plugin

class TestPlugin implements Plugin<Project> {

    @Override
    void apply(Project target) {
        println "Hello gradle plugin"
    }
}

apply plugin: TestPlugin

这样我们在执行./gradlew时，就能看到"Hello gradle plugin"了

> Configure project :app
Hello gradle plugin

gradle plugin-extension

class TestPlugin implements Plugin<Project> {
    @Override
    void apply(Project target) {
        def extension = target.extensions.create("testPluginExt11",TestPluginExtension)
        target.afterEvaluate {
            println "Hello gradle ${extension.name}"
        }
    }
}

class TestPluginExtension{
    def name = 'pluginExt'
}

apply plugin: TestPlugin

testPluginExt11{
    name = 'newPluginExt'
}

//日志输出
> Configure project :app
Hello gradle newPluginExt

创建插件工程

library name只能时buildSrc，因为buildSrc是插件的保留module名称
buildSrc module不能配置到setting.gradle
配置固定META-INFO /resouces/MEATA-INF/gradlep-lugin/**.properties

 implementation-class=***.***.***