Gradle依赖树查看
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Gradle依赖树查看相关的知识,希望对你有一定的参考价值。
参考技术A使用Gradle开发中,或多或少都会引入三方库,但是三方库又会有自己的子依赖,那么真正依赖到版本中的版本是多少呢?其实官方也有给出查看方法, 官方说明点这里 ,采用以下方式可查看:
这样子可以看到各个状态下依赖的版本,比如这里截出来的是releaseCompileClasspath的
(1) 利用dependencies查看依赖树
PS:方式一和二还是有区别的,比如看在window中点击androidDepencies,能看到依赖的本地jar包,但是通过命令查看依赖,则查看的没有本地jar文件依赖。
通过--configuration可以配置要查看哪个variant下的版本,比如这里是releaseCompileClasspath看的就是release的依赖。
看打印就能更清晰的看到依赖的版本,是为什么依赖到了,比如okhttp依赖到的是3.9.0版本,是因为com.squareup.okhttp3:logging-interceptor:3.9.0中的依赖是3.9.0 (*),这样子就替换掉了retrofit中的3.8.0的依赖
(2) 利用dependencyInsight 详细查看某个库(采用模糊过滤的方式,比如下面查看的是com.squareup.okhttp)的版本依赖。
这里就能很明显的看到,依赖的okhttp的版本是3.9.0了,interceptor中的3.9.0解决了retrofit中的3.8.0
自己上传maven库之后,可能是覆盖的形式更新的maven库,如果不刷新,则一直都会使用本地缓存的依赖,我试过从文件中找到依赖删除掉他,但是一sync,就自己又生成出来了,很奇怪。
在android右侧gradle选项,随便找一个tasks下的build里面,执行cleanBuildCache
gradle是比较智能的了,也能智能的处理相同包不同版本的冲突,会默认依赖较新的一个版本。但是如果是不同包之间的冲突,那么就会报错,得需要人为来解决了,比如:
依赖:
这两个依赖在一起会报错:
那么我们通过前面的命令可以查 com.github.bumptech.glide:glide下面的依赖树,但是解决这种冲突光看依赖树还不行,得结合报错,CoordinatorLayout$Behavior,我们在出问题的情况下全局搜索(双击shift,记得够上从选择框)一下CoordinatorLayout,就能看到是在哪两个库中存在了,再结合依赖树就能看出来com.github.bumptech.glide:glide依赖了:
而support-fragment:27.1.1下面依赖了
在这个库里也有android.support.design.widget.CoordinatorLayout,就与默认的com.android.support:design的冲突了。
所以处理下即可:
吐槽:google大法更新库是有可能不考虑兼容性的,所以建议都使用同一个版本。出现这个根本原因就是因为两个支持库的版本不一致,一个是26.1.0一个是27.1.1,如果两个都是同一个版本则不会存在这个问题
以上是关于Gradle依赖树查看的主要内容,如果未能解决你的问题,请参考以下文章
Android Gradle 插件Android 依赖管理 ⑤ ( Gradle 依赖优化 | 命令行查看依赖模块 | 依赖冲突问题 | 依赖传递冲突 | 分库冲突 | 依赖分组不同导致冲突 )