本篇博客是在学习 gradle 相关知识时简要的记录了一下 gradle 的一些注意事项, 记录的内容比较简单, 主要是为了给自己提供一个思路, 平时在开发过程中如果忘记了, 打开看一下有个印象, 具体的一些细节问题如果记不起了可以百度查找

dependOnmustRunAfter 的区别

1
2
3
4
Task A = tasks.create('A')
Task B = tasks.create('B')
B.dependOn(A)
B.mustRunAfter A
  • dependOn - 设置任务的依赖关系, 当执行任务B时一定会先执行A
  • mustRunAfter - 设置任务的排序, 当执行任务B时不需要执行任务A, 但是当任务A和任务B同时执行时, 任务将在任务B之前执行

闭包

闭包就是一段代码块, 需要时还是用{}括起来使用, 箭头前面的表示形参, 箭头后面的表示执行语句, 闭包中的最后一行可以作为返回值返回.

闭包可以作为一个方法的参数传入, 也可以作为一个方法的返回值返回, 它是连接内部函数和外部函数的一个桥梁

闭包如果没有参数的话, 会隐含一个默认的参数it, 和 this 的作用类似, 代表的是传入闭包的参数.

闭包中有三个属性:

  1. this
  2. owner
  3. delegate

默认情况下这三个属性的值是相同的, 但是当闭包有包含关系的时候, this 指的就是当前的闭包, owner 指的是当前闭包的所有者, 也就是当前闭包的外层闭包.

使用 delegate 可以实现闭包委托, 但是需要搭配 resolveStrategy 一起使用才能达到效果

gradle 中守护进程

gradle --daemon clean

gradle 中有一个命令 --daemon 可以用来开启一个守护进程, 这个守护进程在后台运行. 在开启了守护进程后, 在==下一次==运行构建时构建速度将会变快. (第一次不会快反而会慢)

注意点:

  1. 守护进程只会被创建一次
  2. 守护进程会在3小时空闲时间之后自动失效
  3. 如果先要重新启动守护进程, 在构建时需要再次加上 --daemon

gradle 构建块

每个 gradle 构建都包含了三个基本的构建块: project, task, property

每个构建至少包含一个 project, 可以包含一个或者多个task

projecttask 暴露的属性可以用来控制构建

属性扩展

使用ext{} 可以为 projet 增加额外属性

可以在 gradle.properties 文件中添加 gradle 属性, 在这里定义的属性对所有的 project 可见, 即在所有的 module 中都可以获取到这里定义的属性

gradle 构建的生命周期

  1. 初始化阶段

    初始化阶段 gradle 会去执行 settings.gradle 文件读取要构建项目包含那些module

  2. 配置阶段

    配置阶段 gradle 会遍历所有的 moudle, 梳理所有的 task

  3. 执行阶段

    执行阶段按照 task 正确的顺序依次执行

我们可以在 ==初始化阶段== 和 ==配置阶段== 直接做一些操作, 也可以在 ==配置阶段== 和 ==执行阶段== 做一些操作

增量编译

gradle 会通过比较某个任务的两次构建 taskinputsoutputs 来决定是否执行 task, gradle 会在本地生成快照, 如果两次的 inputsoutputs 都一样, 就会将任务的状态设置成 UP-TO-DATE, 任务就不会被执行

gradle 命令缩写

如果一个 task 的定义是遵循驼峰命名的, 那么我们在使用命令行的时候就可以使用所写的方式

eg: 使用 gradle helloWorld 运行一个 task 名称为 helloWorld 的任务, 我们可以简写为 gradle hW , 但是要保证的是 task 的名称是唯一的

gradle 中的依赖关键字

  1. api

    该依赖方式会传递所有的依赖库, 当其他 module 依赖了该 module 时, 可以使用该 module 下通过 api 需依赖的库

  2. implementation

    该依赖方式所依赖的库不会传递, 只会在当前 module 中生效

  3. compileOnly (对应之前的 provided)

    该依赖只在编译时有效 , 不会参与打包

    可以在自己的 moudle 中依赖一些常用的库, 比如 gson okhttp 等, 这样可以避免多个 module 使用同一个依赖库的不同版本而导致的依赖冲突问题

  4. runtimeOnly (对应之前的 apk)

    只在生成 apk 的时候参与打包, 编译时不会参与, 很少使用到

  5. testImplementation

    只在单元测试代码的编译以及最终打包测试 apk 时有效

  6. debugImplementation

    只在 debug 模式的编译和最终的 debug apk 打包时有效

  7. releaseImplementation

    只在 release 模式的编译和最终 release apk 打包时有效