gradledependencies（gradle dependencies分析依赖）

by intanet.cn ca 移动开发 on 2024-03-19

本篇文章给大家谈谈gradledependencies，以及gradle dependencies分析依赖对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

1、Gradle依赖树查看
2、android studio gradle dependencies 包存放在哪儿
3、处理Gradle依赖冲突
4、问android studio gradle dependencies 包存放在哪儿
5、在Gradle中添加Dependency Check，以及在Sonar中查看报告
6、Gradle dependencies

Gradle依赖树查看

使用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，如果两个都是同一个版本则不会存在这个问题

[img]

android studio gradle dependencies 包存放在哪儿

android studio 对于依赖包的管理是通过配置build.gradle 文件来实现的

1. 后面配裤橘纯李括号内有Project的，是项目的配置文件

其中一般存放的是依赖包的网络库地址和abdroid的gradle构建文件版本信息

以下是包含默认仓库地址jcenter 和第三方库地址的示例

一般第三方库在使用非jcenter仓库的时候都会在安装说明上详细指出

2. 后面括号有Module的，是项目的配置文件

一般包含了版本培团号，依赖，打包信息等

依赖包相关代码，一般是这样的

testCompile 指的是在测试时包含的依赖

compile +'**** ' 指的是gradle特有的云依赖，通过指定包的packageid和版本就可以自动从云仓库下载对应的依赖包

compile +project 指的是引用项目中其他的模块作为依赖

compile files 指的直接依赖对应的jar包，括号内的是相对地址，一般存放在对应模块的lib文件夹内

管理依赖的可视化界面可以从最右边的按钮进去，界面如下

处理Gradle依赖冲突

在Android开发过程中会总会引入一些第三方依赖库,无可避免的会遇到jar/aar包冲突，Manifest合并冲突，资源冲突等问题

基于此本次主要记录下如何处理类冲突，jar/aar版本冲突。先由常见的com.ta.utdid2.a.a.a found in modules alicloud-android-utdid-2.5.2 android-utdid冲突入手，常见于支付宝sdk和友盟Sdk的冲突。

磨刀不误砍材工,在处理冲突问题前，要先了解下如何查看Gradle依赖树，在AS的Terminal里输入 gradle :app:dependencies 即可查看gradle依赖树。输出结果如下（示意）

输出依赖树后，在里面搜索android-utdid，会发现有多个第三方库对utdid存在引入关系。

经过查看得知utdid我依赖为：com.aliyun.ams:alicloud-android-utdid:2.5.2

该依赖库的Group为com.aliyun.ams。module为alicloud-android-utdid

下面要做的就是去除其他依赖对utdid的引入，仅保留一次有效的引用关系即可。

implementation ('com.xxx:yyy:0.0.0.4'){

exclude module: 'alicloud-android-utdid'

}

implementation ('com.aaa:bbb:0.4'){

exclude module: 'alicloud-android-utdid'

}

常规查阅资料大家推荐去除重复引入的方法都是exclue group。实际上如该group下的依赖项较多，且只想去除某一个依赖时，这时使用exclude module能更细节且准确的控制去除某一项的引用关系。

以上为utdid的处理方式

关于微信sdk冲突的团兄处理方式

问题背景：我方已集成wechat-sdk-android-with-mta sdk用作分享和支付功能，随着业务发展需要接入一个第三方业务Sdk，该Sdk内部棚或游具备支付功能，他们也进行了wechat-sdk-android-with-mta的引入，且两个微信sdk的版本不一致。

此时如果进行打包就会爆出各种com.tecent.xx的类冲突。

处理方式参照支付宝sdk的冲突方式

implementation ('com.xxx:zzz:0.6'){

exclude module: 'wechat-sdk-android-with-mta'

}

关于百度地图API_KEY冲突的处理方式

百度地图需要在主工程的Manifest里注册一个API_KEY。如此时引入的第三方Sdk里同样有百度地图，且已经在内部注册了com.baidu.lbsapi.API_KEY。

此时会出现Manifest.xml的合并冲突。解决方式为增加tools:replace="android:value"属性即可

meta-data

android:name="com.baidu.lbsapi.API_KEY"

android:value=""

tools:replace="android:value"/

在开发中不同第三方Sdk对基础依赖的版本会发生变化，比如ktx和compact的版本。需要强制指定这些基础依赖的版本统一

方式链销为在build.gradle(app)里增加

configurations.all{

resolutionStrategy.force'androidx.core:core-ktx:1.8.0-alpha01'

}

后续将持续添加AndroidStudio里各种冲突的处理方式。

问android studio gradle dependencies 包存放在哪儿

1、Android Studio项目结构，建议你百度一下：初学Android Studio项目结构第一课，熟悉Android Studio项目结构和Eclipse的区别

2、dependencies依赖包，Android Studio通常先检查项目是否需要，如果需要而且没有，自动联网下明睁载，哪桥然后自动添加，同时，也可以手动添加dependencies依赖包，放置依赖包的位置和Eclipse的一样激缓岁

在Gradle中添加Dependency Check，以及在Sonar中查看报告

在项目中需要引入 dependency check 的工具来扫描相关依赖的库是否有安全漏洞等问题。由于是使用Gradle作为依赖构建工具，以及kotlin作为开发语言，所以选择了 owasp dependency check 的 Gradle 插件的方式。最后需要将报告上传到 sonar 进行展示。

在 build.gradle.kts 中添加相关的依赖：

在 sonar 的配置项中添加 dependency check 报告者颤的路径：

在 sonar 中选择 Administration 的tab，进入 Marketplace 。在 Plugins 中搜索并安装如图的插件：

项目中使用了 Jenkins 作为CI构建工具，所以需要在其中添加一个 stage 用于将 dependency check report 上传到 sonar 中。如下：

由于 dependency check 并不是每次跑pipeline都需要，所以通过 timeout+input 的方式来手动run这一个stage。当跑完 ./gradlew dependencyCheckAnalyze 后就会生成相关的report文档，默认是html格式，可以通过配置修改。

当dependency check跑完之后，就应该执行 ./gradlew sonarqube 命令将本地report上传到sonarqube来分析。sonar的 host.url 和 login 参数既可以配置在sonar对应的properties，也可以在run命令的时候传入。这郑嫌冲里是因为将 creds 配置到了Jenkins中，所以在Jenkins file中通过获取凭证的方喊歼式来配置。

当Jenkins CI跑完Sonar Analysis后，就可以去Sonar上查看对应的dependency check的report。如图