其實這類文章博客網上一搜一大堆，但有些地方可能說的不太清楚（都一樣的內容，抄襲太嚴重），這里只是做個精簡的總結和一些其他地方沒提到的點。
一、Android Studio 3.0開始使用了新的指令，原來的很多被棄用了，總的來說是為了加快構建編譯速度。
下面是一個總結表格：
| Android Studio 2.X | Android Studio 3.X |
|---|---|
| apk | runtimeOnly |
| provided | compileOnly |
| compile | api |
| 沒有對應 | implementation |
| debugCompile | debugImplementation |
| releaseCompile | releaseImplementation |
| androidTestCompile | androidTestImplementation |
需要解釋的主要是implementation系列指令：
implementation：注意compile是和api對應的，效果相同。implementation的區別在於對外可見性，而且可以加快編譯速度（原理在於減少不必要的重復編譯過程）。舉個例子如下：
A module 依賴 B module，B 依賴 C module。 Android Studio 2.X使用compile： A compile B B compile C A module不僅可以引用B module，還可以引用C module的接口和類。 Android Studio 3.X使用implementation： A implementation B B implementation C A module只可以引用B module，不可以引用C module。C 對 A 是不可見的！ 簡單來說，從Android Studio 3.X開始，依賴首先應該設置為implement，如果沒有錯，那就用implement，如果有錯，那么使用api指令，這樣會使編譯速度有所增快。（就這樣理解夠了，很多文章又是畫圖又是長篇大論的，完全沒有必要，本來就不是多么復雜的東西）。
二、provided（compileOnly）和compile（api）區別
按照幾乎所有文章的說法：
provided只提供編譯支持，但是不會寫入apk。使用provide可以避免支持包版本沖突和重復打包導致安裝包體積徒增。
但就我的實踐來說（支持包V7,V4之類）：
1、不使用provided也不會導致支持包重復，依賴module編譯出來的aar並不包含那些多個module（包括app module）重復使用的支持包。
2、如果依賴module使用的style中引用了支持包（V7,V4之類的）中的主題，那么，使用provided會報錯（找不到主題資源）。如果只是引用支持包中的類和接口是可以使用provided的（但意義也不大，反正也不會重復）。
3、可能直接引用jar包的方式會重復把，但現在這種場景不多了。
可以看到在gradle3.0中，compile依賴關系已被棄用，被implementation和api替代，provided被compile only替代，apk被runtime only替代，剩下的看名字就知道了。
我們先來看看implementation和api的區別：
api：跟2.x版本的 compile完全相同
implementation：只能在內部使用此模塊，比如我在一個libiary中使用implementation依賴了gson庫，然后我的主項目依賴了libiary，那么，我的主項目就無法訪問gson庫中的方法。這樣的好處是編譯速度會加快，推薦使用implementation的方式去依賴，如果你需要提供給外部訪問，那么就使用api依賴即可
還不熟悉2.x版本依賴的可以看看下面的說明，括號里對應的是3.0版本的依賴方式。
compile（api）
這種是我們最常用的方式，使用該方式依賴的庫將會參與編譯和打包。
當我們依賴一些第三方的庫時，可能會遇到com.android.support沖突的問題，就是因為開發者使用的compile依賴的com.android.support包，而他所依賴的包與我們本地所依賴的com.android.support包版本不一樣，所以就會報All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes這個錯誤。
解決辦法可以看這篇博客：com.android.support沖突的解決辦法
provided（compileOnly）
只在編譯時有效，不會參與打包
可以在自己的moudle中使用該方式依賴一些比如com.android.support，gson這些使用者常用的庫，避免沖突。
apk（runtimeOnly）
只在生成apk的時候參與打包，編譯時不會參與，很少用。
testCompile（testImplementation）
testCompile 只在單元測試代碼的編譯以及最終打包測試apk時有效。
debugCompile（debugImplementation）
debugCompile 只在debug模式的編譯和最終的debug apk打包時有效
releaseCompile（releaseImplementation）
Release compile 僅僅針對Release 模式的編譯和最終的Release apk打包。