记一次依赖冲突排查感悟

因为上线了一个功能,引入了dexposed,导致打包打不过去,报的错误是so重复或者代码重复(如果只是so重复,可以pickFirst解决)。通过打依赖树、排查,最后发现跟项目中用的一个调试工具相关。间接引入了epic,而它把dexposed的源码、so直接拷贝过来!如果不是我之前看过epic的源码,估计排查仍然遥遥无期。
命令行:

gradlew :app:depencencies > dependencies.txt

结论:
有些开源库很坑,把别的开源库的源码,原封不动的拷贝过来,很坑!以后再遇到这种情况,依赖树直接看不出来的话,可以从这个角度入手排查问题了。

最后编辑于 :
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

  • 东西有点多,但是资源绝对nice,自己都全部亲身体验过了,大家可放心使用 github排名: https://gi...
    Rance935阅读 11,759评论 26赞 312
  • 自己总结的Android开源项目及库。 github排名https://github.com/trending,g...
    passiontim阅读 2,857评论 1赞 26
  • https://github.com/7heaven/bitmapMesh Android开源项目及库整理总结 字...
    奈何心善阅读 4,853评论 2赞 40
  • 各种帮助类汇总:https://github.com/Blankj/AndroidUtilCode 常用的 ios...
    懦弱的me阅读 1,542评论 0赞 51
  • Swift1> Swift和OC的区别1.1> Swift没有地址/指针的概念1.2> 泛型1.3> 类型严谨 对...
    cosWriter阅读 11,849评论 1赞 32

友情链接更多精彩内容