轉載: https://blog.csdn.net/yuzhiqiang_1993/article/details/78366985
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插件默認是安裝的。
下面我們來看看他們之前的差異:
首先是2.x版本的依賴方式:
再來看看3.0的:
可以看到在Android studio3.0中,compile依賴關係已被棄用,被implementation和api替代,provided被compile only替代,apk被runtime only替代,剩下的看名字就知道了。
我們先來看看implementation和api的區別:
implementation依賴關係圖
implementation:只能在內部使用此模塊,比如我在一個libiary中使用implementation依賴了gson庫,然後我的主項目依賴了這個libiary,那麼,我的主項目就無法訪問gson庫中的方法。這樣的好處是編譯速度會加快,推薦使用implementation的方式去依賴,如果你需要提供給外部訪問,那麼就使用api依賴即可
api依賴關係圖
compile(api)
api:跟2.x版本的 compile完全相同。用api指令編譯,libiary內部依賴對app Module 是可見的,app Module也可以使用Library內部依賴。這種是我們最常用的方式,使用該方式依賴的庫將會參與編譯和打包。
當我們依賴一些第三方的庫時,可能會遇到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打包。