Android依赖库的优化

在Android项目的 External Libraries 下面，可以看到项目所用到的所有官方库或者第三方库。如下：
这里写图片描述

仔细浏览，有时候会发现，同一个库出现了多个版本，比如上图中的com.facebook.stetho库，一个1.4.1版本，一个1.5.0版本。甚至会看到一些不知从哪里冒出来的库，比如上图出现的com.google.zxing库。据我所知zxing是一个二维码扫描库，但是我的项目里并没有二维码的功能，我也没有通过gradle导入过这个库，它怎么就莫名出现在我的项目里了呢？既然这个库我用不上，那么我该如何去掉它呢？还有一个问题，stetho为什么会出现两个版本？是哪些地方在使用他们呢？我可不可以只使用一个版本来减少引用库的数量呢？这篇文章就是要解决以上的疑惑。

1. 全局分析项目依赖库

这里写图片描述

双击运行上图中Gradle projects里面项目根目录下的 android > androidDependencies，就会出现下图的结果，得到整个项目的依赖关系树。

这里写图片描述

然后用关键字查找，可以发现是一个：libraries：lib_zjump_model 的模块在引用它。进入 lib_zjump_model 模块的 build.gradle 文件查看引用配置，果然就发现了stetho-okhttp3:1.4

这里写图片描述

把它的版本号改为1.5.0，同步一下项目，再查看External Libraries ，可以发现项目的引用库里只有一个com.facebook.stetho:stetho-okhttp3:1.5.0了。这样，就成功去除了一个库的多余版本。

2. 分析指定依赖库

接下来就是zxing库，通过关键字查找，居然找不到这个库。那只能用另一种方法了。

gradlew :module_name:dependencyInsight --configuration compile --dependency library_name

在Terminal中输入上面的命令行(如果gradlew不可用，尝试把gradlew改为gradle)，其中 module_name 用模块名替换， library_name 用想要查找的库名关键字替换。比如我这里想在app模块下查找zxing库，于是输入指令：

gradlew :app:dependencyInsight --configuration compile --dependency zxing

结果什么也没查到，证明zxing库不是在app模块中被引入的。现在由于不知道到底是哪个模块引入了zxing，只能一个模块一个模块去试。最后发现它出现在thirdlogin模块里，结果如下：

> Task :thirdlogin:dependencyInsight
com.google.zxing:core:3.3.0
\--- com.facebook.android:facebook-android-sdk:4.26.0
     \--- compile

通过结果可以知道，zxing库是com.facebook.android库自带的。我需要用到facebook库，但是我不需要它里面的zxing库，那么该怎么去除它呢。方法如下：

compile ('com.facebook.android:facebook-android-sdk:4.26.0'){
     exclude group: 'com.google.zxing', module: 'core'
}

在facebook库的引用下面exclude掉zxing库即可。然后同步项目，去External libraries查看，就能发现zxing库已经不见了。

3. 一些还算重要的说明

说明 1

上面的命令行，有一个

--configuration compile

说明分析的是通过 compile 关键字引入的依赖库，但是在 gradle3.0之后，官方已经推荐使用 implementation 和 api 关键字，关于这三种引入方式的区别，建议不明白的人都去了解一下，这里我就不细说了。如果引入依赖库的时候，使用的不是 compile 关键字，那么上面的命令行就什么都找不到。而且把命令行中的 compile 替换为 implementation 或者 api 也没有用。目前我也没找到解决这个问题的方法。如果已经使用了 implementation 关键字，分析的时候只能把它暂时改为 compile，待分析完成之后再改回去。这样做就是稍微麻烦了一点，对项目没有什么影响。

说明2

对于同一个库引入了多个版本的情况，有时候可能是因为第三方库引入了这个库，而我们自己在项目中也需要并引用了这个库。第三方库引入的版本和我们自己引入的版本不一样，所以就出现了多个版本的库。有些第三方库维护者很久不去更新，它里面使用到的库版本已经落后了，那我们也没有办法啊。
对于一个项目存在多个模块的情况，有可能不同的模块要引用相同的库，这个时候必须保证库的版本号相同，以免自己造成多版本库情况的出现。