2017 年google 後，Android studio版本更新至3.0，更新中，連帶着com.android.tools.build:gradle 工具也更新到了3.0.0，在3.0.0中使用了最新的Gralde 4.0 裡程碑版本作為gradle的編譯版本，該版本gradle編譯速度有所加速，更加欣喜的是，完全支援Java8。
當然，對于Kotlin的支援，在這個版本也有所展現，Kotlin插件預設是安裝的。
本文轉載至：https://www.jianshu.com/p/f34c179bc9d0
我們來看看建立一個項目在
Module
中的
dependencies
中的變化。
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.android.support:appcompat-v7:26.1.0'
implementation 'com.android.support.constraint:constraint-layout:1.0.2'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.1'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
}
下面我們來看看他們之前的差異：
首先是2.x版本的依賴方式
再來看看3.0的
可以看到在
Android studio3.0
中，
compile
依賴關系已被棄用，被
implementation
和
api
替代，
provided
被
compile only
替代，
apk
被
runtime only
替代。
我們先來看看
implementation
和
api
的差別：
api：跟 2.x 版本的
compile
完全相同
implementation：使用了該指令編譯的依賴，它僅僅對目前的
Module
提供接口。例如我們目前項目結構如下
LibraryA
中引用了
LibraryC
的庫，如果對
LibraryC
的依賴用的是
implementation
關鍵字。 如下：
dependencies {
. . . .
implementation project（path：'：libraryC'）
}
那麼
LibraryC
中的接口，僅僅隻能給
LibraryA
使用，而我們的
App Module
是無法通路到
LibraryC
提供的接口的，也就是将該依賴隐藏在内部，而不對外部公開。這就是
implementation
關鍵字的作用。
建議
在
Google IO
相關話題的中提到了一個建議，就是依賴首先應該設定為
implement
的，如果沒有錯，那就用
implement
，如果有錯，那麼使用
api
指令，這樣會使編譯速度有所增快。
那為什麼要這麼做呢？
答案是： 1. 加快編譯速度。2. 隐藏對外不必要的接口。
為什麼能加快編譯速度呢？
這對于大型項目含有多個
Module
子產品的， 以上圖為例，比如我們改動
LibraryC
接口的相關代碼，這時候編譯隻需要單獨編譯
LibraryA
子產品就行， 如果使用的是
api
或者舊時代的
compile
，由于
App Module
也可以通路到
LibraryC
,是以
App Module
部分也需要重新編譯。當然這是在全編的情況下。
還不熟悉 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
這個錯誤。
解決辦法可以看這篇部落格：http://blog.csdn.net/yuzhiqiang_1993/article/details/78214812
provided（compileOnly）
隻在編譯時有效，不會參與打包
可以在自己的
module
中使用該方式依賴一些比如
com.android.support
，
gson
這些使用者常用的庫，避免沖突。
apk（runtimeOnly）
隻在生成
apk
的時候參與打包，編譯時不會參與，很少用。
testCompile（testImplementation）
testCompile
隻在單元測試代碼的編譯以及最終打包測試apk時有效。
debugCompile（debugImplementation）
debugCompile
隻在 debug 模式的編譯和最終的 debug apk 打包時有效
releaseCompile（releaseImplementation）
Release compile
僅僅針對 Release 模式的編譯和最終的 Release apk 打包。