Gradle是一个好用的构建工具 与maven ant 蕾丝,使用它的原因是:
1.配置相关依赖代码量少,不会像maven一样xml过多
2. 打包编译测试发布都有,而且使用起来方便
3.利用自定义的任务可以完成自己想要的功能
我们使用homebrew 安装
brew install gradle
# 进入用户目录下的配置文件
vim ~/.bash_profile
which gradle
/opt/homebrew/bin/gradle
# 修改.bash_profile文件, 在文件的最后加上如下配置:
export PATH=$PATH:/opt/homebrew/bin/
# 修改后, 按[Esc], 命令":wq"保存退出, 并在终端使用如下命令使配置生效:
source ~/.bash_profile
XPTSH0195LAD:bin root# gradle -v
------------------------------------------------------------
Gradle 7.4.2
------------------------------------------------------------
Build time: 2022-03-31 15:25:29 UTC
Revision: 540473b8118064efcc264694cbcaa4b677f61041
Kotlin: 1.5.31
Groovy: 3.0.9
Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM: 11.0.15.1 (Oracle Corporation 11.0.15.1+2-LTS-10)
OS: Mac OS X 12.2.1 x86_64
安装成功
存放依赖包目录;
├── gradle //为包装文件生成的文件夹
│ └── wrapper 一个盒子 保证gradle本地版本安装一致,远端服务端没有gradle 构建问题 自己会去官方下载
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties 官方配置文件 里面有官方下载地址和本地保存路径
├── gradlew //Gradle 包装器启动脚本
├── gradlew.bat //Gradle 包装器启动脚本
├── settings.gradle //用于定义构建名称和子项目的设置文件
└── app
├── build.gradle //app项目的构建脚本
└── src
├── main
│ └── java //默认 Java 源文件夹
│ └── demo
│ └── App.java
└── test
└── java //默认 Java 测试源文件夹
└── demo
└── AppTest.java
1.如何保证大家本地安装的Gradle版本的一致性?
2.服务器端构建,分配到的服务器没有安装Gradle,如何进行构建?
Gradle Wrapper则是用来解决上面两个问题的方案——把gradle装进盒子里,这个盒子就是wrapper
当你需要某个版本的gradle的时候,gradle wrapper就会去gradle的官方服务器下载对应版本
在项目的gradle-wrapper.properties配置文件我们可以看到,gradle的远程下载地址,以及本地的存放地址(前两行的地址拼接)
这样通过配置文件配置gradle就解决了上面两个问题,我们把这个配置文件push到仓库,同事拉去下来也就制定好了gradle的版本,同时如果机子没有gradle的话会自动去下载
Task
在gradle中task就是一系列的操作任务,例如我们有如下五种常见的task
| clean | 清理构建产物(./gradlew clean) |
|build |执行构建(./gradlew build)|
test 运行测试(./gradlew test)
tasks 查看所有tasks(./gradlew tasks)
help 查看帮助信息(./gradlew help --task build)
task的执行也是有依赖的,即一个大的task会有几个小的task构成
使用./gradlew xxx --dry-run命令即可查看名字为xxx的task命令的构成
如果./gradlew build -x test
依赖管理
在build.gradle文件里我们可以进行项目的依赖管理,我们只需往dependencies里添加我们需要的类库的坐标即可
需要注意的是坐标前的关键字不同会产生不同的效果
api 能访问依赖库所依赖的库的方法
implementation 依赖的库只能自己库本身访问,举个例子,A依赖B,B依赖C,如果B依赖C是使用的implementation依赖,那么在A中是访问不到C中的方法的
compileOnly 只在编译的时候有效, 不参与打包
runtimeOnly 只在打包的时候有效,编译不参与
testImplementation 在单元测试和打包测试apk的时候有效
版本冲突问题
如果你依赖了库A的1.0版本,又依赖了库B,这个库B依赖了库A的2.0版本,此时就发生了版本冲突问题
1.我们可以手动去除冲突的依赖,在冲突的库选一个进行exclue
Java
implementation ('com.carlos.test:Test:1.0.0') {
exclude group: "io.reactivex.rxjava2",module: "rxjava"
// exclude group: "io.reactivex.rxjava2:rxjava:2.1.11"
}
implementation ‘io.reactivex.rxjava2:rxjava:2.1.13’
2.我们可以强制使用某版本依赖
Java
configurations.all {
resolutionStrategy {
force 'io.reactivex.rxjava2:rxjava:2.1.13'
}
}