本文介绍的的最新的一种方式 Version Catalogs。好了，废话不多说，我们开始学习这一种项目统一依赖方式。
介绍
需要注意的是，这个方式是在 Gradle7.0 以上使用的（经过测试，必要要 gradle 7.4.2 以上版本才能解析）。如果当前的应用小于这个版本，建议采用别的方式。当时可以往下看学习学习。
首先，提供 《官方文档 - version catalogs 》给到大家，还是建议大家先看一下官方文档，当然都是英文，可以翻译看看，然后再回来看这篇文章会事半功倍。当然如果直接看也没有关系。
实现方式
本文主要介绍 version catalogs 项目统一依赖管理的两种实现方式。分别是：
- 直接在项目的
setting.gradle文件当中实现- 新建一个
.toml后缀文件实现
据了解，目前这个方式还是预览版本，所以需要在 项目的 setting.gradle 文件当中手动开启：
// VERSION_CATALOGS当前并不是稳定版本功能
// 所以需要预先开启功能预览 enableFeaturePreview('FEATURE')
enableFeaturePreview("VERSION_CATALOGS")
方式一：
在项目的setting.gradle文件当中，所有代码如下：
//settings.gradle
pluginManagement {
repositories {
google()
mavenCentral()
gradlePluginPortal()
maven { url "https://jitpack.io" }
}
}
// VERSION_CATALOGS当前并不是稳定版本功能
// 所以需要预先开启功能预览 enableFeaturePreview('FEATURE')
enableFeaturePreview("VERSION_CATALOGS")
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
gradlePluginPortal()
google()
mavenCentral()
maven { url "https://jitpack.io" }
}
versionCatalogs{
libs{
version('compileSdk','33')
version('minSdk','21')
version('targetSdk','32')
version('coreKtx','1.7.0')
version('appcompat','1.3.0')
version('material','1.4.0')
version('constraintLayout','2.1.3')
......
alias('imp_coreKtx').to('androidx.core','core-ktx').versionRef('coreKtx')
alias('imp_appcompat').to('androidx.appcompat','appcompat').versionRef('appcompat')
alias('imp_material').to('com.google.android.material','material').versionRef('material')
alias('imp_constraintLayout').to('androidx.constraintlayout','constraintLayout').versionRef('constraintLayout')
......
//组合
bundle('android_base',['imp_coreKtx','imp_appcompat','imp_material'])
}
}
}
rootProject.name = "LeoDevMvpKotlinDemo"
include ':app
include ':lib_fast_dev_mvp_kt'
我们只需要在 dependencyResolutionManagement 增加代码即可，下面我们来解释一下如何使用的：
version():顾名思义，这个是写版本号的， version（‘名字’，‘版本号’）。alias().to().versionRef():这个就是导依赖的路径设置， alias('名字').to('依赖路径').versionRef('版本号名称')。bundle():组合，将已经定义的依赖组合到一起，可理解为依赖数组。bundle(名字',['依赖名字','依赖名字'])
其中，如果不定义version版本号，那么可以直接写成：
alias('imp_coreKtx').to('androidx.core','core-ktx').version('1.7.0)
不过还是建议大家分开来，统一下version版本号。这里再举例一下怎拆分，例如，我们需要导入一个依赖：
implementation 'androidx.appcompat:appcompat:1.3.0'
那么我们就可拆分成这样:
version('version_appcompat','1.3.0')
alias('imp_appcompat').to('androidx.appcompat','appcompat').versionRef('version_appcompat')
这就是第一种编写方式，但是这种方式有一种弊端，当我们项目依赖越来越多的时候，dependencyResolutionManagement这个方法就会越来越长。并且这个 setting.gradle 不止单单放我们的导入依赖的代码，也有我们导入库的地址代码等等，不够单一。
所以我们有了第二种，创建一个单独文件的方式。
方式二：
在项目的根目录下(也就是 setting.gradle 同级目录)，创建一个后缀名为 .toml 的文件，名字自定，我这里创建了 project.version.toml 的文件，如下图:
文件里面代码如下：
//project.version.toml
[versions]
compileSdk = "33"
minSdk = "21"
targetSdk = "32"
versionCode = "1"
versionName = "1.0.0"
coreKtx = "1.7.0"
appcompat = "1.3.0"
material = "1.4.0"
constraintlayout = "2.1.3"
[libraries]
coreKtx = { module = "androidx.core:core-ktx", version.ref = "coreKtx" }
appcompat = { module = "androidx.appcompat:appcompat", version.ref = "appcompat" }
material = { module = "com.google.android.material:material", version.ref = "material"}
constraintlayout = { module = "androidx.constraintlayout:constraintlayout", version.ref = "constraintlayout" }
[bundles]
andorid_base = ["coreKtx","appcompat","material","constraintlayout"]
[plugins]
application = { id = "com.android.application"}
这里主要分为四个部分，[versions],[libraries],[bundles],[plugins]。分别为[版本]，[依赖]，[组合]，[插件]。我们直接照搬就好。经过测试第四个[plugins]不太稳定，有时候会报错，可不写。
我们文件创建好，编码完毕之后呢，需要在我们方法一的地方增加一行代码，导入我们新建的这个文件。代码如下：
//setting.gradle
dependencyResolutionManagement {
versionCatalogs {
libs {
from(files("./project.verisons.toml"))
}
}
}
其实也就是将我们方法一里面的所有代码，写到了单独的文件里面，然后再单独导入这个文件。
具体使用
两种方式的实现，使用方法都是一样的。我们在项目的 build.gradle文件里面就可以直接写入代码啦。写之前记得点击一下 死丢丢 的那个小象。重新构建一下项目。
当 死丢丢 构建完毕之后哦，我们就可以去到项目的 build.gradle文件里 coding 啦，使用如下：
android {
namespace 'leo.dev.mvp.kt'
compileSdk libs.versions.compileSdk.get().toInteger()
defaultConfig {
applicationId "leo.dev.mvp.kt"
minSdk libs.versions.minSdk.get().toInteger()
targetSdk libs.versions.targetSdk.get().toInteger()
versionCode libs.versions.versionCode.get().toInteger()
versionName libs.versions.versionName.get().toString()
testInstrumentationRunner libs.versions.testInstrumentationRunner.get().toString()
}
......
}
我们在输入的时候，输入 libs 之后就会有相对应的提示啦。在依赖里面的使用如下：
dependencies {
//bundle
implementation libs.bundles.andorid.base
implementation libs.bundles.smart.refresh
implementation libs.bundles.net
implementation libs.bundles.junit
......
}
注意事项
需要注意的是，如果你定义名字的时候，使用了下划线。那么导入的时候需要多一个层级，什么意思呢？如果你输入的名字是如下类似的：
//方式一：
alias('imp_coreKtx').to('androidx.core','core-ktx').versionRef('coreKtx')
//方式二：
andorid_base = ["coreKtx","appcompat","material","constraintlayout"]
那么在导入依赖的时候就需要如下写法：
//方式一：
implementation libs.imp.coreKtx
//方式二：
implementation libs.bundles.andorid.base
可以简单理解为，它会自动把 _ 转为 . ，并且需要注意的是，在编码的过程中，代码可能会提示 libs()的代码块，如果使用这个，构建会报错（具体原因没有深入研究）。总之，我们先手动输入 libs 就不会出现问题啦。
总结
以上就是本篇文章的全部内容。这种项目依赖管理方式必须在高版本的gradle上面实现，实现有两种：
- 项目的
setting.gradle文件- 创建一个新的
.toml后缀名文件
两个方式的区别，也写在了文章上面，至于采用哪种方式，就看各位的喜好了。唯一需要注意的就是在命名的时候，输入下划线的导入区别。参考上面的注意事项。
