新一代版本依赖管理Vesion Catalog的使用及发布

news/2024/11/29 12:54:09/

前言

前段时间使用新版本的Android Studio创建了个项目想测试点东西，项目创建后发现整个Gradle的依赖管理发生了巨大的变化。
先说一下我使用的Android Studio的版本如下。
在这里插入图片描述
创建项目后主要变化如下：

  1. 原本的.gradle变成了.gradle.kts，也就是说以后肯定是以kts脚本为主了。kts相较于grovvy使用起来更加方便，语言统一，且有提示。
  2. AGP版本升到了8+
  3. 版本依赖变成了下面这个样子
    在这里插入图片描述
    点击依赖发现会跳转到 gradle目录下的libs.versions.toml 文件内
    在这里插入图片描述

这个libs.version.toml实际上是Gradle新版本提供的一种依赖管理方式，详情可以看 version catalog 官方文档

在version catalog 之前，实际上在Android中的Gradle依赖管理还有以下几种方式

  1. 直接依赖 最原始的方式，维护依赖版本时很麻烦
  2. 在ext中声明依赖的信息，然后在依赖处使用ext中声明的变量进行依赖管理，初步解决了依赖版本统一的问题，但写起来没提示，还是很麻烦
  3. 通过内置的buildSrc插件进行依赖管理，在插件内部通过代码维护依赖信息，使用依赖时导包使用即可，本质上就是个静态变量的方式。这种方式算是比较友好了，写依赖的时候有提示，在编译期会进行校验，由于每次更改都会导致全量编译，因此对编译速度有一定的影响。
  4. 使用Include build，可以像buildSrc那样把依赖信息维护在代码内，使用时也跟跟buildSrc类似，但是编译速度要更快，也有提示以及点击跳转等功能。

前面几种方式我都用过，在version catalog出来之前的很长一段时间我用的都是Include build这种方式，但是其还有一个问题没法解决就是根目录下的插件版本没办法管理到，如图所示，例如我希望把therouter的插件版本也管理起来，因为他的版本我已经在com.yzq.dependency-manager中声明过了。
在这里插入图片描述
但是不管是buildSrc还是Include build，都是编译期才生效，并且其生命周期也都在根目录build.geadle执行之后，所以没办法把插件相关的配置给维护起来。

而 Vesion Catalog 就解决了这个问题。

Vesion Catalog的使用和发布

Version Catalog的使用非常简单，官方文档介绍的已经非常详细了，推荐直接去看 官方文档 即可。
需要注意的是使用Version Catalog对Gradle的版本是有要求的，推荐直接在AGP8以上的版本使用，没有什么奇怪的限制。

这里我门快速过一下使用方式

方式一

直接在settings.gradle.kts中声明versionCatalogs以及相关的配置信息即可

dependencyResolutionManagement {repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)repositories {google()mavenCentral()}versionCatalogs {create("androidLibs") {/*声明版本号*/version("minSdk", "21")version("compileSdk", "33")version("targetSdk", "33")version("kotlin", "1.8.22")/*** 声明依赖库*  方式一：别名, 依赖库的具体坐标和版本*  方式二：别名, group，artifact，version*/library("androidx-appcompat", "androidx.appcompat:appcompat:1.3.1")//方式一library("androidx-core-ktx", "androidx", "core:core-ktx").version("1.6.0")//方式二/*把依赖库打包 一起依赖*/bundle("androidx", listOf("androidx-appcompat", "androidx-core-ktx"))/*声明插件*/plugin("android-library", "com.android.library").version("8.0.2")plugin("kotlin-android", "org.jetbrains.kotlin.android").versionRef("kotlin")}}
}

随后使用方式如下：

plugins {
//    id("com.android.library")
//    id("org.jetbrains.kotlin.android")/*依赖插件 等同于上面注释掉的代码*/alias(androidLibs.plugins.android.library)alias(androidLibs.plugins.kotlin.android)
}android {namespace = "com.yzq.mylibrary2"compileSdk = androidLibs.versions.compileSdk.get().toInt()
}dependencies {/*单独依赖*/implementation(androidLibs.androidx.core.ktx)implementation(androidLibs.androidx.appcompat)/*打包依赖*/implementation(androidLibs.bundles.androidx)
}

在添加依赖时是有提示的，同时把插件的版本也管理起来了。

方式二

方式二是官方推荐的方式，就是在toml文件中管理依赖。创建新项目时默认就是这种方式，默认的文件路径在文章开头也给出了，是在gradle文件夹里。
在这里插入图片描述

至于写法也很简单，这里不赘述了。

  • [versions]就是声明版本的
  • [libraries]就是声明依赖库的
  • [plugins]就是声明插件的
  • [bundles]就是打包依赖，用来简化依赖

示例如下：

[versions]
agp = "8.2.0-alpha10"
kotlin = "1.8.21"
core-ktx = "1.9.0"
junit = "4.13.2"
androidx-test-ext-junit = "1.1.5"
espresso-core = "3.5.1"
appcompat = "1.6.1"
material = "1.9.0"
constraintlayout = "2.1.4"
lifecycle-livedata-ktx = "2.6.1"
lifecycle-viewmodel-ktx = "2.6.1"
navigation-fragment-ktx = "2.6.0"
navigation-ui-ktx = "2.6.0"[libraries]
core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "core-ktx" }
junit = { group = "junit", name = "junit", version.ref = "junit" }
androidx-test-ext-junit = { group = "androidx.test.ext", name = "junit", version.ref = "androidx-test-ext-junit" }
espresso-core = { group = "androidx.test.espresso", name = "espresso-core", version.ref = "espresso-core" }
appcompat = { group = "androidx.appcompat", name = "appcompat", version.ref = "appcompat" }
material = { group = "com.google.android.material", name = "material", version.ref = "material" }
constraintlayout = { group = "androidx.constraintlayout", name = "constraintlayout", version.ref = "constraintlayout" }
lifecycle-livedata-ktx = { group = "androidx.lifecycle", name = "lifecycle-livedata-ktx", version.ref = "lifecycle-livedata-ktx" }
lifecycle-viewmodel-ktx = { group = "androidx.lifecycle", name = "lifecycle-viewmodel-ktx", version.ref = "lifecycle-viewmodel-ktx" }
navigation-fragment-ktx = { group = "androidx.navigation", name = "navigation-fragment-ktx", version.ref = "navigation-fragment-ktx" }
navigation-ui-ktx = { group = "androidx.navigation", name = "navigation-ui-ktx", version.ref = "navigation-ui-ktx" }[plugins]
androidApplication = { id = "com.android.application", version.ref = "agp" }
kotlinAndroid = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }[bundles]
androidX = { modules = ["core-ktx", "appcompat", "material", "constraintlayout", "lifecycle-livedata-ktx", "lifecycle-viewmodel-ktx", "navigation-fragment-ktx", "navigation-ui-ktx"] }

使用上跟方式一完全一样，默认我们不需要在settings.gradle.kts配置任何东西。gradle会自动加载gradle目录下的libs.versions.toml文件，默认的名称也是libs。
当然，如果你想把文件名字或者路径改一下也完全没问题，改完后手动配置下依赖即可。

例如

  versionCatalogs {create("libs") {from(files("version-catalog/libs.versions.toml"))}}

发布到远端

如果你没有共享依赖的需求，那么上面的方式已经足够使用了。
但是现在基本上都是组件化开发了，特别是当组件数量比较多或者公司内有其他App时，大概率就会有统一依赖版本以及共享依赖的需求了。
那我们可以把Version Catalog发布到远端，组件或其他项目需要时直接依赖然后使用即可，这样就很方便的实现了版本的统一以及快速依赖了。毕竟拷贝来拷贝去非常麻烦且不好维护。

Version Catalog发布也比较简单，按照 官方文档 来即可。
发布完成后，直接依赖远程的配置就可以了。
示例：

    versionCatalogs {create("libs") {from("com.xeonyu:version-catalog:0.0.2-SNAPSHOT")}
}

到这里，我们就实现了共享版本目录了。

配合Include Build 简化配置

解决完共享依赖的问题后，我们还可以配合之前用的Include Build来简化日常的依赖配置。
比如作为一个module，它的配置比较固定，无非就是些 minSdk，targetSdk，混淆配置，插件配置之类的，而且每个module的配置基本一致，同时作为公司内部的组件，我们希望组件的版本(例如minSdk,targetSdk等)能够跟App的版本保持一致，那么我们就可以结合Include Build加上version catalog来实现了。
还有一些三方依赖比如room，therouter等，他们的配置是固定成套的，我们可以通过写插件的方式把他们的配置集中起来，项目需要用到时直接一行代码就能搞定依赖了。

示例：

plugins {alias(libs.plugins.yzq.android.application)alias(libs.plugins.yzq.android.room)
}

插件部分不是很通用，一般需要根据自身需要编码定制，这里就不啰嗦了，主要是提供些思路，抛砖引玉。
关于插件的发布可以参考
发布Gradle插件 文档，剩下的就是写插件发布然后应用了。

总结

总而言之，Version Catalog和Include Build可以帮助开发人员更好地管理和配置项目中的依赖库和插件，提高开发效率，并保持版本的统一性。同时，通过发布Version Catalog和编写Gradle插件，可以实现依赖的共享和集中管理。

如果你觉得本文对你有帮助，麻烦动动手指顶一下，可以帮助到更多的开发者，如果文中有什么错误的地方，还望指正，转载请注明转自喻志强的博客 ，谢谢！


http://www.ppmy.cn/news/695727.html

相关文章

网页直播英文版上线，跨国企业客户用着很酷哇

网页直播英文版上线，跨国企业客户用着很酷哇

阿酷TONY原创文章 / 网页直播产品评测 / 长沙 网页直播是什么？ 基于网页浏览器直接发起直播，比如打开谷歌浏览器，360浏览器直接登录发起直播即可，无须安装客户端软件，很方便很酷~~~ 第1部分：网页直播英文…
阅读更多...
微云网页版服务器繁忙,腾讯微云传输速度慢的几种原因及解决方法

微云网页版服务器繁忙,腾讯微云传输速度慢的几种原因及解决方法

大家经常使用腾讯微云吧，不过大家知道腾讯微云传输速度慢怎么办吗?下面小编就给大家分享腾讯微云传输速度慢的几种原因及解决方法，希望会对你有所帮助。 腾讯微云传输速度慢的几种原因及解决方法： 1、网络宽带本身速度慢 解决办法&#xff1…
阅读更多...
免费视频存储平台（微云、百度网盘、谷歌硬盘、酷播云）的截图对比

免费视频存储平台（微云、百度网盘、谷歌硬盘、酷播云）的截图对比

这个文章整理自2018年11月29日，主要是考虑的视频方面的存储平台，以下介绍了，腾讯的微云、百度网盘、谷歌云端硬盘、酷播云免费视频存储平台。 腾讯QQ的微云： 官网地址：https://www.weiyun.com 提供10G免费空间&…
阅读更多...
整理网页资料加入App的流程

整理网页资料加入App的流程

整理网页资料加入App的流程 编者：李国帅 qq：9611153 微信lgs9611153 时间：2019/11/11 起因: 以前收集了一些电子图书，后来学了android编程，就像把它们放到app里，自己有时间的话就会翻翻，比…
阅读更多...
2021-06-15

2021-06-15

作用: 这个只是一个简单的思路 作用是 就算脚本在客户手里 我们依然可以通过微云笔记来随时控制那边的脚本是否执行 比如客户拿了脚本跑路了 而且我们也没有做平时做的一些限制 我们可以使用微云来关闭脚本 客户运行脚本就会提示关闭无法运行下去 微云端： 脚本端&a…
阅读更多...
IDM突破下载限制

IDM突破下载限制

IDM突破下载限制 好久没写了，水篇文刷一下存在感 各位都是大佬级别的人物，IDM是什么可能比我还清楚，我就不详细介绍了。如果有人不清楚，请看下文Wikipedia的解释。 Internet Download Manager（简称IDM）是一…
阅读更多...
何谓网页重构

何谓网页重构

前端重构平时做什么 前端架构：文件结构规划、结构样式模块化页面制作：稳健、保真（交互、视觉）、可扩展如何去读一个视觉稿：最高境界是眼中有图，手中无图（用代码实现效果）规范整理&am…
阅读更多...
IT常说的协议指的是什么？—Vecloud微云

IT常说的协议指的是什么？—Vecloud微云

协议是一种数字语言，我们可以通过它与Internet上的其他人进行通信。 协议是在通信通道的两端相互接受和实施的一套规则，用于信息的正确交换。 通过采用这些规则，两个设备可以相互通信并可以交换信息。 每个协议以不同的术语定义和具有唯一名称…
阅读更多...
最新文章

Copyright @ 2022~2023