注册

为什么要选择VersionCatalog来做依赖管理?

虾扯淡

很多人都介绍过Gradle 7.+提供新依赖管理工具VersionCatalog,我就不过多介绍这个了。我们最近也算是成功接入了VersionCatalog,过程也还是有点曲折的,总体来说我觉得确实比我们当前的ext,或者说是用buildSrc的形式进行依赖管理是个更成熟的方案吧。下面是几个介绍的文章,尤其可以看看三七哥哥的。

之前大部分文章只介绍了技术方案,很少会去横向对比几个技术方案之间的优劣。从我们最近一个月的使用结果上来看吧,接下来我给大家分析下实际的优劣,仅仅只代表个人看法, 上表格了。

因为VersionCatalog使用的文件格式是toml,所以后续可能会用toml进行简称。

extbuildSrctoml
声明域*.gradle*.java *.kt*.toml
可修改可修改不可修改不可修改
写法花里胡哨静态变量固定写法 xxx.xxx.xxx
校验随便写编译时校验同步时校验

声明域: 指的是我们在哪里声明这些依赖管理。其中ext可以在绝大部分的.gradle中去进行声明,所以就会导致依赖声明的过于零散。而这部分问题就不存在于buildSrc和toml中,他们只能被声明在固定的位置上。

可修改性: 特制声明的依赖能否被修改,ext声明是在内存空间内,而ext的本质其实就是一个Any他可以存放任意的东西,如果出现同名的则会是后面声明的把前面声明的覆盖掉,这就是一个非常不稳定的属性,而buildSrc则是由class来声明的,我们没有办法在gradle中去修改这部分,所以相对来说是稳定的。而toml也类似,基于固定格式反序列化成代码。不具备修改的能力。

写法: ext这方面是真的拉胯,比如支持libs.abc或者libs."abc"或者libs.["abc"]还可以单引号,就非常的随意,而且极为不统一。这也是我们本次改动中碰到问题最多的时候。其他两种写法都相对比较固定,类似java/kt 中的静态常量。

校验: ext就是爱咋写咋写吧,反正也没有很好的校验啥的。而buildSrc则是基于java的代码编译来的,toml因为是一个新的文件格式,所以内置了一套相对比较强的语法校验,如果不合规则会报错,并显示错误行数。

据说buildSrc对于增量编译的适配等其实不太良好,而且我们是一个复杂的巨型复合构建的工程,所以个人并不太推荐buildSrc。

可以参考这篇文章第二章 Stop using Gradle buildSrc. Use composite builds instead

由此可证哦,VersionCatalog雀食是一个非常好的选择,尤其如果你们当前还是在使用的是ext的情况下。

巨型工程最麻烦的事情其实另外一点就是技术栈的切换,因为要改起来的地方可真的就是太多了,首先就是要先解决复合构建的情况下全局只有一份注册的逻辑,其二就是把当前工程的ext全部转移到toml中,然后要最好和之前的方式接近,尽量保证最小改动。最后则是所有工程都改一下!!!!!!!!(要我狗命)

共享配置

GradleSample demo 工程如下,其中plugin-version就是

我们也采取了之前Gradle 奇淫技巧之initscript pluginManagement一样的方式,通过initscript做到复合构建内共享插件的能力。

另外我们把VersionCatalog作为一个extension抛出来在外部完成注册。

catalogs {
  script = new File(rootProjectDir, "depencies.gradle")

  versionCatalogs {
      create("libs") { from(files("${rootProjectDir.path}/toml/dependencies.versions.toml")) }
      create("module") { from(files("${rootProjectDir.path}/toml/module.versions.toml")) }
  }
  dependencyResolutionManagement {
      repositories {
          maven { setUrl("https://maven.aliyun.com/repository/central/") }
          maven {
              setUrl("https://storage.googleapis.com/r8-releases/raw")
          }
          gradlePluginPortal()
          google()
          mavenLocal()
          maven {
              url "https://dl.bintray.com/kotlin/kotlin-eap"
          }
      }
  }

}

通过这部分配置就可以把共享的部分注入进工程内。然后就是很沙雕的改改改了,把所有的ext全部迁移到我们新的toml上去,然后注册出多个。

命令行工具

TheNext 虾开发的撒币cli工具 专门解决虾的撒币问题

以前也说过了我们工程的模块数量巨大,然后又因为ext的写法风骚,所以我们基本所有的写依赖的地方都要改,就是真的工作量巨大。

一个优秀的摸鱼工程师最重要的天赋就是要学会转化生产力,把这种简单又繁琐的工作交给命令行来解决。所以这就有了TheNext的一个新能力,基于当前的文件目录修改所有的.gradle文件,然后把非标准的ext的写法全部进行一次替换。

02463cf3a6244050b20fb52189a46fe3~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp?

效果如图所示。

代码逻辑如下,我们首先会遍历整个工程的文件目录,然后发现.gradle后缀的文件,之后通过正则匹配出dependencies,然后进行把一些"" '' []等等都删掉,然后把- _更换成.,这样就能完成简单的自动替换了。

package com.kronos.mebium.android

import com.beust.jcommander.JCommander
import com.kronos.mebium.action.Handler
import com.kronos.mebium.entity.CommandEntity
import com.kronos.mebium.file.getRootProjectDir
import com.kronos.mebium.utils.green
import com.kronos.mebium.utils.red
import com.kronos.mebium.utils.yellow
import java.io.File
import java.util.Scanner

/**
*
* @Author LiABao
* @Since 2022/12/8
*
*/
class DependenciesHandler : Handler {

   val scanner = Scanner(System.`in`)
   var isSkip = false

   override fun handle(args: Array<String>) {
       isSkip = args.contains(skip)
       val realArgs = if (isSkip) {
           arrayListOf<String>().apply {
               args.forEach {
                   if (it != skip) {
                       add(it)
                  }
              }
          }.toTypedArray()
      } else {
           args
      }
       val commandEntity = CommandEntity()
       JCommander.newBuilder().addObject(commandEntity).build().parse(*realArgs)
       val first = commandEntity.file
       val name = commandEntity.name
       val root = first
       val files = root.walkTopDown().filter {
           it.isFile && it.name.contains(".gradle")
      }
       val overrideList = mutableListOf<Pair<File, File>>()
       files.forEach {
           onGradleCheck(it)?.apply {
               overrideList.add(it to this)
          }
      }
       confirm(overrideList)
  }

   private fun confirm(overrideList: MutableList<Pair<File, File>>) {
       if (overrideList.isEmpty()) {
           return
      }
       println("if you want overwrite all this file ? input y to confirm \r\n".red())
       val input = scanner.next()
       if (input == "y") {
           overrideList.forEach {
               it.first.delete()
               it.second.renameTo(it.first)
          }
           print("replace success \r\n ".green())
      } else {
           print("skip\r\n ".yellow())
      }
  }

   private val pattern =
       "(\\D\\S*)(implementation|Implementation|compileOnly|CompileOnly|test|Test|api|Api|kapt|Kapt|Processor)([ (])(\\D\\S*)".toPattern()

   private fun onGradleCheck(file: File): File? {
       var override = false
       val lines = file.readLines()
       val newLines = mutableListOf<String>()
       lines.forEach { line ->
           val matcher = pattern.matcher(line)
           if (matcher.find()) {
               val libs = matcher.group(4)
               if (!libs.contains(":") && !libs.contains("files(")) {
                   val newLibs =
                       libs.replace("\'", "").replace("\"", "").replace("-", ".").replace("_", ".")
                          .replace("kotlin.libs", "kotlinlibs").replace("[", ".").replace("]", "")
                   if (newLibs == libs) {
                       newLines.add(line)
                       return@forEach
                  }
                   print("fileName: ${file.name} dependencies : $line \r\n")
                   if (isSkip) {
                       override = true
                       newLines.add(line.replace(libs, newLibs))
                       print("$libs do you want replace to $newLibs   \r\n ".green())
                       return@forEach
                  }
                   print("$libs do you want replace to $newLibs ? input y to replace \r\n ".red())
                   while (true) {
                       val input = scanner.next()
                       if (input == "y") {
                           print("replace success\r\n".green())
                           override = true
                           newLines.add(line.replace(libs, newLibs))
                           return@forEach
                      } else {
                           print("skip\r\n ".yellow())
                           break
                      }
                  }
              }
          }
           newLines.add(line)
      }
       if (override) {
           val newFile = File(file.parent, file.name.removeSuffix(".gradle") + ".temp")
           newLines.forEach {
               newFile.appendText(it + "\r\n")
          }
           return newFile
      }
       return null
  }
}

const val skip = "--skip"

代码就基本是这样,如果有正则带佬可以帮忙优化下正则的。

然后这个工具也可以多次复用,因为我这个需求没有办法很快的被合入,需要频繁的rebase master的代码,每次rebase完之后都要进行二次修改,真的吐了。

验收

每个新功能开发最后都是要进行验收的,尤其是技改需求,你到时候把功能搞坏了到时候可是要背黑锅的啊。而且这种需求也没有办法要求测试进行特别系统性的测试,所以还是要开发自己想办法了。

我们拉取了apk包的依赖,然后用HashSet进行了拉平,去除重复依赖,然后通过diff对比前后差异,在基本符合预期的情况下我们就可以进行快速的合入。

结尾

其实本文的核心是给大家分析下几种依赖管理方式的优劣,然后对于还在使用gradle ext的大佬,其实可以逐渐考虑进行替换了。

作者:究极逮虾户
来源:juejin.cn/post/7190277951614058555

0 个评论

要回复文章请先登录注册