解决 Android 依赖冲突
解决办法
问题原因就是，各个模块所有的依赖（递归）的 jar 包最后都会加载到安卓的项目中，你可以选择 project 形式查看 External Libraries，都在这了。所以解决问题关键就是干掉冲突，剩下一个就行了，或者全不要就行了！
下面直接先上解决办法吧，急性子就不为难急性子了，本人最烦的就是说一大堆废话，后面几行代码就能问题。
1、引入时剔除
//逗号别掉了
implementation 'com.ezviz.sdk:ezuikit:2.2.1', {
exclude group: 'com.squareup.okhttp3', module: 'okhttp'
}
//或者用下面方式
// implementation('com.ezviz.sdk:ezuikit:2.2.1') {
// exclude group: 'com.squareup.okhttp3', module: 'okhttp'
// }
这里直接拿我解决的 SDK 为例，其中 okhttp 冲突了。我的项目里面已经有一个 okhttp：3.8.1 了，这里导入这个库的时候，又将 okhttp：3.10.0 给导入进来了，直接排除掉就可以，具体说明文章末尾细讲！
至于 group 和 module，可以看我下面这个引入，类比下：
com.squareup.okhttp3:okhttp:3.10.0
2、全局删除
android{
//....
//剔除工程中所有的该依赖
configurations {
all*.exclude group: 'org.hamcrest', module: 'hamcrest-core'
}
}
这个是一个很傻的办法，直接全局设定，把导入的某 jar 包全部删除，这样就不冲突了？也许打包是没问题了，只要用到功能必闪退吧！（貌似有人说要配合 Multidex 一起用，看看咯！）
（ps. 后续更新：有可能是其他库带来的，其实根本用不到，还是有用的）
3、开启 Multidex 功能
我是想不到 jar 包冲突和 Multidex 有什么关系，但是看到几篇博客说能解决问题，也顺便说一下吧！我个人认为 Multidex 就是解决 class 过多的，不知道是不是。
（ps. 后续更新：是不是可能引入的库造成了类太多了？）
步骤 1：更改 build.grade
defaultConfig {
...
// Enabling multidex support.
multiDexEnabled true
}
dependencies {
...
compile 'com.android.support:multidex:1.0.1'
}
步骤 2：设置 Application 类
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
MultiDex.install(this);
}
}
步骤 3：更改 grade.properties
org.gradle.jvmargs=-XX:MaxHeapSize\=2048m -Xmx2048m
步骤 4：通过增大可用内存解决「:app:transformClassesForDexForDebug」异常，在 gradle.build 中指定 javaMaxHeapSize：
android {
...
dexOptions {
javaMaxHeapSize "4g" //specify the heap size for the dex process
}
}
4、强制修改版本
这个办法在网上见的多，大致就是在模块的 gradle 文件里面强制使用某一个版本的 jar 包，这样就不会下载两个 jar 包了。
我是发现没什么用，网上有的说放根目录，有的说放 android 里面，我不确定放哪啊！我是都试了，没效果，可能运行项目的姿势不对喽？
（ps. 后续更新：放在 gradle 中最外层就可以，亲测有用。
在不清楚在那里引入的库的话，切换到project目录，看看哪个重复了，统一下版本，很有用！）
android{
//....
//放在这？？？
}
//根节点？？？
configurations.all {
//resolutionStrategy.force 'com.squareup.okhttp3:okhttp:3.10.0'
resolutionStrategy.eachDependency { DependencyResolveDetails details ->
def requested = details.requested
if (requested.group == 'com.google.android.exoplayer') {
if (!requested.name.startsWith("multidex")) {
details.useVersion '2.9.3'
}
}
}
}
还有人说可以在工程的 gradle 中强制设置，我是发现也是没什么用，提一下。
allprojects {
...
configurations.all {
resolutionStrategy.force 'com.squareup.okhttp3:okhttp:3.10.0'
}
}
5、自行删除
这个方法我觉得可以解决特定问题，但局限性很大。
我们知道别人的依赖我们是无法修改的，但是自己本地 lib 是可以删除，如果是和我们本地的 jar 包冲突的话，我们删掉自己的就行了。
这个解决办法有局限性，一个是要求冲突的 jar 包在我们本地（可以操作），另一个如果我们用的版本较高，而别人的版本较低怎么办？那岂不是凉凉，此为下策！
6、使用 compileOnly
compileOnly 的形式引入库会只在编译时有效，不参与打包，它是解决一个什么问题呢？其实就是多个模块中，会冲突的库，让其中一个 implementation ，其他使用 compileOnly，最后出来能够共用一个库（当然要有一个）。
那这个办法和解决我们的问题有什么关联呢？其实这个办法和第二个方法类似，目的就在打包，引入的库的时候将 implementation 改为 compileOnly，让引入的库只在编译时有效，不会参与打包，这样就能够打包了。
这个问题也很明显，我要是能找到冲突的库，让它单独 compileOnly 固然能解决问题，可是事与愿违，我们冲突的库一般都是在别人的库里面，如果直接将所有内容以 compileOnly 形式导入，我们百分百要用到这个库里面的东西啊，一用就会闪退，最终只是自欺欺人罢了！
（ps. 后续更新：年少轻狂啊！作为SDK提供给别人用得到啊）
好了，上面就是解决依赖冲突的几种办法了，推荐第一个，其他有些鸡肋。
依赖分析
这里将一下我们如何定位冲突，实际上编译的时候就会报错了，如下：
Execution failed for task ':app_vs:checkDebugDuplicateClasses'.
Duplicate class okhttp3.Address found in modules jetified-okhttp-3.10.0.jar (com.squareup.okhttp3:okhttp:3.10.0) and jetified-okhttp-3.8.1.jar (okhttp-3.8.1.jar)
这里就是提示我 jetified-okhttp-3.10.0.jar 和 jetified-okhttp-3.8.1.jar 有冲突了，不过这还是比较简单的信息，下面介绍使用 gradlew 分析。
使用 gradlew 分析
查看依赖关系需要用到的命令为：
gradlew :[module_name]:dependencies
如需分析工程中app这个module的依赖关系行命令则为 ：
gradlew :app:dependencies --configuration releaseRuntimeClasspath
从下面的关系树可以看到各个依赖之间的关系，以及依赖版本号合并后的最终版本号
+--- com.android.support:support-core-utils:28.0.0 (*)
| | | +--- com.android.support:customview:28.0.0
| | | | +--- com.android.support:support-annotations:28.0.0
| | | | \--- com.android.support:support-compat:28.0.0 (*)
| | | +--- com.android.support:viewpager:28.0.0
| | | | +--- com.android.support:support-annotations:28.0.0
| | | | +--- com.android.support:support-compat:28.0.0 (*)
| | | | \--- com.android.support:customview:28.0.0 (*)
| | | +--- com.android.support:coordinatorlayout:28.0.0
如果你不想在命令终端中查看，而是想把依赖关系输出到文件中，则可以使用以下命令：gradlew :[module_name]:dependencies > [output_file]
例如将app module的依赖关系输出到dependence.txt文件中：gradlew :app:dependencies > dependence.txt
简单小结
实际上这些内容应该写在最前面的，但是我觉得解决问题优先，实际上上面得内容看起来还是有点摸不着头脑的，虽然可能能解决你的问题。
依赖
上面我们通过 gradlew 命令能够看到，实际上我们项目的依赖是一种树的关系，每个模块、每个库都会直接或间接地引用别的库，最后汇总到我们地安卓项目中。
点开顶部地 Project Structure ，选择 Dependencies ，我们可以看到自己地一些库
而选择 Project 目录后，我们可以看到所有的库（aar/jar）
为什么会冲突，实际上就是这个汇总问题，当所有库都放一起了，加入有两个版本不一致的库，岂不是有两个jar(aar) 包？所以有了我们上面的解决办法，去掉一个，或者全去掉。
冲突
我们一直讲的冲突，却没有说到为何冲突，实际上冲突有下面这些形式：
-
项目自己引用的 jar 包重复
-
项目中 jar 包和第三方库（module、远程库、aar、jar）冲突
-
第三方库之间的冲突
如果是我们自己的，很好办，可以自己随便操作（删除或修改），如果是第三方的就改不了，只能在引入库的时候排除掉。（如果功能都用不到，删除了也没问题）
结语
以上就是解决依赖冲突的一些办法，这里有两点内容，希望读者再了解了解，说不定对依赖有更深的理解：
-
Gradle 导入方式（implementation、api、compileOnly等）
-
混淆