[移动开发]了解 Gradle 和 buildType Task，准备Android面试

// 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**目录时，也会同时把对应目录打包到工程。比如执行 **assembleInterna**l时会把**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