解決辦法

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 沖突了。我的項目里面已經(jīng)有一個 okhttp：3.8.1 了，這里導(dǎo)入這個庫的時候，又將 okhttp：3.10.0 給導(dǎo)入進(jìn)來了，直接排除掉就可以，具體說明文章末尾細(xì)講！

至于 group 和 module，可以看我下面這個引入，類比下：

com.squareup.okhttp3:okhttp:3.10.0

2、全局刪除

android{//....//剔除工程中所有的該依賴configurations {all*.exclude group: 'org.hamcrest', module: 'hamcrest-core'}
}

這個是一個很傻的辦法，直接全局設(shè)定，把導(dǎo)入的某 jar 包全部刪除，這樣就不沖突了？也許打包是沒問題了，只要用到功能必閃退吧！（貌似有人說要配合 Multidex 一起用，看看咯！）

（ps. 后續(xù)更新：有可能是其他庫帶來的，其實根本用不到，還是有用的）

3、開啟 Multidex 功能

我是想不到 jar 包沖突和 Multidex 有什么關(guān)系，但是看到幾篇博客說能解決問題，也順便說一下吧！我個人認(rèn)為 Multidex 就是解決 class 過多的，不知道是不是。

（ps. 后續(xù)更新：是不是可能引入的庫造成了類太多了？）

步驟 1：更改 build.grade

defaultConfig {...// Enabling multidex support.multiDexEnabled true
}dependencies {...compile 'com.android.support:multidex:1.0.1'
}

步驟 2：設(shè)置 Application 類

public class MyApplication extends Application {@Overridepublic void onCreate() {super.onCreate();MultiDex.install(this);}
}

步驟 3：更改 grade.properties

org.gradle.jvmargs=-XX:MaxHeapSize\=2048m -Xmx2048m

步驟 4：通過增大可用內(nèi)存解決「:app:transformClassesForDexForDebug」異常，在 gradle.build 中指定 javaMaxHeapSize：

android {...dexOptions {javaMaxHeapSize "4g" //specify the heap size for the dex process}
}

4、強(qiáng)制修改版本

這個辦法在網(wǎng)上見的多，大致就是在模塊的 gradle 文件里面強(qiáng)制使用某一個版本的 jar 包，這樣就不會下載兩個 jar 包了。

我是發(fā)現(xiàn)沒什么用，網(wǎng)上有的說放根目錄，有的說放 android 里面，我不確定放哪啊！我是都試了，沒效果，可能運行項目的姿勢不對嘍？

（ps. 后續(xù)更新：放在 gradle 中最外層就可以，親測有用。

在不清楚在那里引入的庫的話，切換到project目錄，看看哪個重復(fù)了，統(tǒng)一下版本，很有用！）

android{//....//放在這？？？  
}
//根節(jié)點？？？
configurations.all {//resolutionStrategy.force 'com.squareup.okhttp3:okhttp:3.10.0'resolutionStrategy.eachDependency { DependencyResolveDetails details ->def requested = details.requestedif (requested.group == 'com.google.android.exoplayer') {if (!requested.name.startsWith("multidex")) {details.useVersion '2.9.3'}}}
}

還有人說可以在工程的 gradle 中強(qiáng)制設(shè)置，我是發(fā)現(xiàn)也是沒什么用，提一下。

allprojects {...configurations.all {resolutionStrategy.force 'com.squareup.okhttp3:okhttp:3.10.0'}
}

5、自行刪除

這個方法我覺得可以解決特定問題，但局限性很大。

我們知道別人的依賴我們是無法修改的，但是自己本地 lib 是可以刪除，如果是和我們本地的 jar 包沖突的話，我們刪掉自己的就行了。

這個解決辦法有局限性，一個是要求沖突的 jar 包在我們本地（可以操作），另一個如果我們用的版本較高，而別人的版本較低怎么辦？那豈不是涼涼，此為下策！

6、使用 compileOnly

compileOnly 的形式引入庫會只在編譯時有效，不參與打包，它是解決一個什么問題呢？其實就是多個模塊中，會沖突的庫，讓其中一個 implementation ，其他使用 compileOnly，最后出來能夠共用一個庫（當(dāng)然要有一個）。

那這個辦法和解決我們的問題有什么關(guān)聯(lián)呢？其實這個辦法和第二個方法類似，目的就在打包，引入的庫的時候?qū)?implementation 改為 compileOnly，讓引入的庫只在編譯時有效，不會參與打包，這樣就能夠打包了。

這個問題也很明顯，我要是能找到?jīng)_突的庫，讓它單獨 compileOnly 固然能解決問題，可是事與愿違，我們沖突的庫一般都是在別人的庫里面，如果直接將所有內(nèi)容以 compileOnly 形式導(dǎo)入，我們百分百要用到這個庫里面的東西啊，一用就會閃退，最終只是自欺欺人罷了！

（ps. 后續(xù)更新：年少輕狂啊！作為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)

使用 gradlew 分析

查看依賴關(guān)系需要用到的命令為：

gradlew :[module_name]:dependencies

如需分析工程中app這個module的依賴關(guān)系行命令則為 ：

gradlew :app:dependencies --configuration releaseRuntimeClasspath

從下面的關(guān)系樹可以看到各個依賴之間的關(guān)系，以及依賴版本號合并后的最終版本號

+--- 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

如果你不想在命令終端中查看，而是想把依賴關(guān)系輸出到文件中，則可以使用以下命令：
gradlew :[module_name]:dependencies > [output_file]

例如將app module的依賴關(guān)系輸出到dependence.txt文件中：
gradlew :app:dependencies > dependence.txt

簡單小結(jié)

依賴

上面我們通過 gradlew 命令能夠看到，實際上我們項目的依賴是一種樹的關(guān)系，每個模塊、每個庫都會直接或間接地引用別的庫，最后匯總到我們地安卓項目中。

點開頂部地 Project Structure ，選擇 Dependencies ，我們可以看到自己地一些庫

而選擇 Project 目錄后，我們可以看到所有的庫（aar/jar）

為什么會沖突，實際上就是這個匯總問題，當(dāng)所有庫都放一起了，加入有兩個版本不一致的庫，豈不是有兩個jar(aar) 包？所以有了我們上面的解決辦法，去掉一個，或者全去掉。

沖突

我們一直講的沖突，卻沒有說到為何沖突，實際上沖突有下面這些形式：

1. 項目自己引用的 jar 包重復(fù)

2. 項目中 jar 包和第三方庫（module、遠(yuǎn)程庫、aar、jar）沖突

3. 第三方庫之間的沖突

如果是我們自己的，很好辦，可以自己隨便操作（刪除或修改），如果是第三方的就改不了，只能在引入庫的時候排除掉。（如果功能都用不到，刪除了也沒問題）

結(jié)語