传统的依赖管理
过去通过gradle的ext属性来维护依赖库一个map
ext {
dependencies = [
"appcompat" : "androidx.appcompat:appcompat:1.2.0",
"recyclerview" : "androidx.recyclerview:recyclerview:1.2.0",
]
}
然后再相应的module中添加具体的引用
implementation rootProject.ext.dependencies[appcompat]
implementation rootProject.ext.dependencies[recyclerview]
这种方法实现了依赖库的集中管理，但是缺少IDE的支持在添加依赖库的时候IDE不能自动补全
buildSrc方式管理依赖库
- 什么是buildSrc
当你运行Gradle时，它会检查项目中是否存在一个名为buildSrc的目录。
然后Gradle会自动编译并测试这段代码，并将其放入构建脚本的类路径中。您不需要提供任何进一步的操作提示。
- 使用buildSrc
- 创建与app同级的文件夹buildSrc
- 在buildSrc文件夹里创建名为build.gradle.kts的文件,并添加如下代码
plugins {
`kotlin-dsl`
}
repositories {
mavenCentral()
}
-
在buildSrc的module中创建src、main、java文件夹，目录格式如下图
微信截图_20210716154051.png 在java目录中创建类Deps.kt 并添加相应的依赖管理
object V{
const val appcompat="1.2.0"
const val retrofit="2.9.0"
const val material="1.3.0"
}
object Deps {
const val appcompat= "androidx.appcompat:appcompat:${V.appcompat}"
const val retrofit= "com.squareup.retrofit2:retrofit:${V.retrofit}"
const val material= "com.google.android.material:material:${V.material}"
}
- 在具体的mudole中引用
mudole_one/build.gradle
dependencies {
implementation Deps.appcompat
implementation Deps.material
implementation Deps.retrofit
}
mudole_two/build.gradle
dependencies {
implementation Deps.appcompat
implementation Deps.material
implementation Deps.retrofit
}
最终实现如下效果
动画.gif
总结
buildSrc 方式管理依赖大大增加了依赖管理的便捷性和易用性
优点
- 共享 buildSrc 库工件的引用，全局管理依赖
- 支持 AndroidStudio 自动补全，实现Autocomplete
- 支持依赖库的点击跳转
缺点
A change in buildSrc causes the whole project to become out-of-date.
Thus, when making small incremental changes, the --no-rebuild command-line option is often helpful to get faster feedback.
Remember to run a full build regularly or at least when you’re done, though.
buildSrc的更改会导致整个项目过时，因此，在进行小的增量更改时，
-- --no-rebuild命令行选项通常有助于获得更快的反馈。不过，请记住要定期或至少在完成后运行完整版本
- 缺点就是buildSrc 依赖更新将重新构建整个项目
