了解 Gradle 和 buildType Task
Posted 涂程
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了了解 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=***.***.***
最后小编在这分享一份,我在学习提升时,从网上收集整理了一些 Android 开发相关的学习文档、面试题、Android 核心笔记等等文档,希望能帮助到大家学习提升,如有需要参考的可以直接去我 CodeChina地址:https://codechina.csdn.net/u012165769/Android-T3 访问查阅。
以上是关于了解 Gradle 和 buildType Task的主要内容,如果未能解决你的问题,请参考以下文章
Android Gradle 插件BuildType 编译类型配置 ⑦ ( BuildType#testCoverageEnabled 配置 )
Android Gradle 插件BuildType 编译类型配置 ⑥ ( BuildType#signingConfig 配置 )
在 gradle 中添加对特定 productFlavor 和 buildType 的依赖
Gradle 总是从最后一种风格中的 buildType 中获取值
使用 gradle buildTypes 的 Android 的不同 Apk
Android开发:《Gradle Recipes for Android》阅读笔记(翻译)3.1——使用Build Types