Build Tasks
在build文件中使用了Android或者Java插件之后就会自动创建一系列可以运行的任务。
Gradle中有如下一下默认约定的任务:
-
assemble
该任务包含了项目中的所有打包相关的任务，比如java项目中打的jar包，Android项目中打的apk
-
check
该任务包含了项目中所有验证相关的任务，比如运行测试的任务
-
build
该任务包含了assemble和check
-
clean
该任务会清空项目的所有的输出，删除所有在assemble任务中打的包
assemble, check 和 build 任务实际上并不做任何事情，它们其实只是为插件提供了一个钩子，真正的事情都是由插件来完成的。这样的话，开发人员就不需要关心我到底运行的是一个java项目还是一个Android项目，也不用关心我到底使用了哪些gradle插件，因为我都可以调用这些约定的任务来完成构建。
注意：Gradle会自动检查一个任务的输入和输出。比如连续两次运行build任务的，Gradle会报告所有的任务都已经是最新刚运行过的了，不需要再次运行。这样的话，任务之间就算是有相互依赖，也不会导致重复的执行。
Java项目常用的任务
Java plugin 主要创建了两个任务：
-
jar
assemble任务会依赖jar任务，看名字就知道这是负责打jar包的任务。jar任务本身又会依赖很多其他的任务，比如classes任务，classes任务会编译java代码
-
test
check任务会依赖test任务，这个任务会运行所有的测试。测试代码使用testClasses任务编译，但是我们基本不用手动运行testClasses任务因为test任务已经添加了对它的依赖。
通常情况下，我们只要运行assemble和check任务就够了。
Android项目常用的任务
和其他gradle插件一样，Android插件也提供了一些默认的任务，比如assemble，check，build，clean，同时它也提供了一些自己特有的任务，比如：
-
connectedCheck
运行那些需要在真机或者模拟器上执行的检查任务，这些任务会并行地在所有连接的设备上运行
-
deviceCheck
使用APIs连接远程设备执行检查.主要用于CI(持续集成)服务上.
上面两个任务都会执行 assemble 和 check任务。新加这两个任务是很有必要的，这样可以保证我们可以运行那些不需要连接设备的检查任务。
注意：build任务并不依赖于deviceCheck或者connectedCheck
一个Android项目通常至少会有两种输出：debug apk和release apk。对应的gradle中有两个任务可以分别输出不同的apk：assembleDebug/assembleRelease。
这两个任务又会依赖其他的任务来构建一个apk。assemble任务依赖这两个任务，调用assemble任务就会生成两种apk。
BuildType
默认情况下，Android插件自动为项目构建一个debug和一个release版本的应用。这两个版本的不同主要体现在在非开发机上的调试功能以及APK的签名方式。debug版本使用一个用公开的name/password创建的key来签名（这样构建的时候就不需要提示输入密码了）。release版本在构建的时候不会进行签名，而是稍后在做。
这个可以使用gradle中的BuildType对象来进行配置。默认情况下，2个BuildType的实例会被创建，一个debug，一个release。Android插件允许自定义这两个实例，当然你也可以创建其他的build type。配置由buildTypes这个DSL来完成：
android {
buildTypes {
debug {
applicationIdSuffix ".debug"
}
jnidebug.initWith(buildTypes.debug)
jnidebug {
packageNameSuffix ".jnidebug"
jniDebuggable true
}
}
}
上面的代码完成了下列配置：
-
配置默认的debug Build Type
设置debug版本的包名为<应用id>.debug，这样就可以在设备上同时安装debug和release版本了。
-
创建一个新的BuildType，名字是jnidebug，同时配置它是复制自debug Build Type。
配置jnidebug开启debug版本的JNI组件，添加一个不同的包名后缀。
创建一个新的的Build Types非常简单，只需要在buildTypes下面通过调用initWith或者使用闭包添加一个新的元素。下表是可以配置的属性以及默认值：
| 属性名 | debug版本默认值 | release或其他版本默认值 |
|---|---|---|
| debuggable | true | false |
| jniDebuggable | false | false |
| renderscriptDebuggable | false | false |
| renderscriptOptimLevel | 3 | 3 |
| applicationIdSuffix | null | null |
| versionNameSuffix | null | null |
| signingConfig | android.signingConfigs.debug | null |
| zipAlignEnabled | false | true |
| minifyEnabled | false | false |
除了这些属性，Build Types还可以用来配置代码和资源文件。针对每一个Build Type，一个新的对应的sourceSet会被创建，这个sourceSet使用一个默认的路径src/< buildtype名字>/。这就意味着Build Type的名字不能是main或者androidTest（这是由插件强制的），同时每个Build Type的名字必须是唯一的。
和其他的source sets一样，Build Type中的source set路径也是可以配置
android {
sourceSets.jnidebug.setRoot('foo/jnidebug')
}
另外,对每一个Build Type,一个新的assemble< BuildType名字>任务会被创建.当debug和release Build Types被预先创建的时候,他们对应的assemble任务也会被一起创建.
上面的build.gradle代码片段还会创建一个assembleJnidebug任务，assemble任务也会添加对assembleJniDebug任务的依赖，正如它对assembleDebug和assembleRelease任务的依赖一样。
可能是使用场景：
-
仅在debug模式下使用的权限，release模式不使用。
-
debug时使用不同的实现
-
debug模式使用不同的资源（比如当一个资源的值依赖于签名的时候）
-
BuildType中的 代码/资源文件 将会被按照下列方式处理：
-
manifest配置会被merge到app manifest中
-
代码不会被merge，会被当做另一个代码目录（source folder）来使用
-
资源文件会覆盖同名的main中的资源文件