你们中的许多人可能已经知道，Gradle引入了一种新的（但不稳定的）方式来集中依赖性声明。在庞大的代码库和多模块项目中，管理Gradle依赖关系一直很困难。以前解决方案遇到的另一个问题是，没有两个项目正在使用Gradle声明或配置相同。在Android中，您总是需要一些时间来记住存储依赖项的gradle文件，或记住与库路径混合的版本的声明数组。

例如，我们可以做：

// third_party_dependencies.gradle

someArrayOfDependencies = [...]

// my_main_dependencies.gradle
someOtherArrayOfDependencies = [...]

，然后对每个人，只需应用一些versions.gradlefile的版本化即可。另一种方式，因为在新的Kotlin项目中更常见，但在Android上不太常见，它是将版本传播在gradle.properties文件中，然后从那里应用属性。底线： 一个重构或结构 没有太多。依赖性变得越来越大，无论如何，总是有机会跟踪东西。更不用说忘记不时更新依赖项。

使用Gradle版本目录，现在有一种以集中式方式读写依赖项的方法，然后由于此功能引入的语法而有一些更轻松的方法来访问它们。在我的示例中，我正在尝试使用gradle .kts文件的版本目录，但是我认为与普通的groovy gradle文件相同的行为。

在开始之前，我们必须注意此功能是不稳定的，因此跳入生产是没有多大意义的（更不用说它可能会影响构建时间）。我个人使用版本目录开始了一个新的Side项目，因此我不打算在一年左右的时间内获得生产。 IDE无论如何都会通知您。

首先，我们在settings.gradle.kts中启用Gradle版本目录4：

enableFeaturePreview("VERSION_CATALOGS")

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

是的，这是一个.toml文件。它的结构使其更具可读性（或不可读取），并且对于一些不错的代码生成而言容易。

让我们看看一个简单的例子：

[versions]
coroutines = "1.6.4"

[libraries]
coroutines-core = { group = "org.jetbrains.kotlinx", name = "kotlinx-coroutines-core", version.ref = "coroutines" }
coroutines-testing = { group = "org.jetbrains.kotlinx", name = "kotlinx-coroutines-test", version.ref = "coroutines" }

首先，括号中的命名（[versions]，[libraries]）是必要的，因此编译器知道哪个元素是什么。但是我通常喜欢此功能，实际上是您在图书馆声明中注意到的-。 -一旦编译了代码并准备在gradle文件中使用。

implementation(libs.coroutines.core)
testImplementation(libs.coroutines.testing)

基本上就是这样。这样，它感觉真的很自然，而gradle依赖性更加直观。公平地说，我总是会从文件转到文件，因为在我需要多次复制的缓存中，我不正确地记住变量名称。尤其是在与Gradle合作时，没有多少人喜欢它，对我个人而言，这会破坏我的注意力很多。
但是，使用.tomlfiles，即使编译器在提供确切的描述和问题方面相当不错，您也必须非常小心的变量等错别字。阅读它给我的错误，我不记得试图搜索该错误，因为它已经很容易理解和自我解释。

gradle公约是集中依赖依赖性的好方法。当然，在使用它时，有一些问题，尤其是在新的依赖介绍中构建项目时。但是，即使在很早的阶段，也看起来很有希望。

如果您想了解有关Gradle版本目录的更多信息，请查看此link here。