前言
dependencies對於Android開發人員來說，並不陌生， 它是用來配置當項目的依賴項，接收的是一個DependencyHandler的閉包。
dependencies的類型
dependencies的類型可以分爲以下幾種
- compile
- testCompile
- androidTestcompile
- debugCompile
- releaseCompile
- implementation
- testImplementation
- androidTestImplementation
- debugImplementation
- releaseImplementation
- provided
- api
就以上類型，針對仔細說明
compile
從依賴上講，用compile修飾的配置會傳遞依賴，而大多數的依賴衝突都是由compile產生的，什麼是傳遞依賴？
打個比方：我們現在有libA，然後libB用compile依賴libA，最後libC依賴libB。那這個時候，libC自然能夠使用libA的內容，因爲libA的內容跟隨這個libB而傳遞到了libC中。如下圖：
而且compile得越多，所產生的依賴樹也就越長，也就越難控制。
從編譯上講，使用compile配置的依賴項，會跟隨打包流程將源碼打包到apk中。
testcompile和androidTestcompile
這兩個依賴項配置和compile是差不多的，也會產生傳遞依賴，唯一不同的是，testcompile和androidTestcompile不會參與源碼打包，只會參與測試包的打包，並且只有在測試模式下啓動纔會生效，debug和release包不生效。
debugCompile和releaseCompile
- debugCompile
只在buildType爲debug的時候參與打包，release不參與打包，比方說我們的內存泄露檢測工具-LeakCanary，其實我們也只是需要在debug模式下打包調試，而發佈release版本就需要進行打包了，所以用debugCompile來進行配置 - releaseCompile
releaseCompile和debugCompile完全相反，只在release模式下參與打包，應用場景不是很多。
implementation
implementation 是Gradle4.1(Android studio3.0)新增的依賴方式，implementation和compile不同，該依賴方式不會產生傳遞依賴，implementation有點像provided和、debugCompile和releaseCompile的集合體。
來個具體場景，例如：有libA公共庫，libB通過implementation依賴libB，然後app無論通過什麼方式依賴libB，lib1的依賴都不會傳遞過來，必須要在app中重新依賴一次。如下圖：
使用implementation有什麼好處呢？
- 很大程度減少重複依賴的問題
- 在開源 lib 的時候儘量採用implementation的方式依賴一些v4、v7包
剩餘的implementation
和前面的compile一樣，只是implementation不會產生傳遞依賴，就不一一闡述了。
provided
只參與編譯，不參與打包。例如說有libB依賴了libA，moduleC又同時依賴了libA和libB，那麼libB就可以使用provided來依賴libA。
api
api是Gradle4.1(Android studio3.0)新增的依賴方式,其作用於compile基本一致。
總結
以上是就是dependencies的類型講解，對於使用Gradle plugin 3.X.X以上版本的gradle，我們應該轉而使用implementation，減少compile的使用，避免依賴衝突的產生。如果我們有開放的lib，那麼更加應該使用implementation依賴一些v4、v7的包，儘量少給lib的使用者造成困擾。
最後
未完待續、敬請期待！
免爲其難的關注一下公衆號吧！！
