因为上线了一个功能，引入了dexposed，导致打包打不过去，报的错误是so重复或者代码重复（如果只是so重复，可以pickFirst解决）。通过打依赖树、排查，最后发现跟项目中用的一个调试工具相关。间接引入了epic，而它把dexposed的源码、so直接拷贝过来！如果不是我之前看过epic的源码，估计排查仍然遥遥无期。
命令行：
gradlew :app:depencencies > dependencies.txt
结论：
有些开源库很坑，把别的开源库的源码，原封不动的拷贝过来，很坑！以后再遇到这种情况，依赖树直接看不出来的话，可以从这个角度入手排查问题了。
因为上线了一个功能，引入了dexposed，导致打包打不过去，报的错误是so重复或者代码重复（如果只是so重复，可...
Maven Helper解决的是Maven依赖的冲突问题 FindBugs初步排查代码中的Bug ECTransa...
一、背景 在日常的开发中，排查问题是一个合格Java开发者的的基本能力。对于常见的NullPointerExcep...
记一次压测异常排查
JVM问题排查实战 记一次频繁FGC的简单排查 一次JVM GC长暂停的排查过程 如何使用MAT进行内存泄露分析
今天项目依赖了一个基础组件之后，启动失败，排查过程走了一些弯路，最终确认是因为依赖组件版本冲突造成了java.la...
什么是依赖冲突 依赖冲突是指项目依赖的某一个jar包，有多个不同的版本，因而造成类包版本冲突 依赖冲突的原因 依赖...
概要 JVM排查工具的实践 permG与方法区 permG与Metaspace 记第一次使用jvm排查工具实践的过...
引用的模块较多，产生的依赖关系可能会有冲突—— 进入主工程 gradle dependencies 查看依赖关系 ...
看了解决Android依赖冲突,学到了一些依赖分析并解决的方法。 run app仔细查看App的Build信息2...
本文标题：记一次依赖冲突排查感悟
本文链接：https://www.haomeiwen.com/subject/lumfqctx.html
网友评论