天天看點

implementation、api、compileOnly差別詳解

Android Studio3.0正式版已經出來了,相比2.x的版本,Gradle版本也更新為了3.x,編譯速度提高了不少。

當我們使用AS3.0建立項目時會發現,預設的依賴由之前的compile更改為implementation了。

下面我們來看看他們之前的差異:

首先是2.x版本的依賴方式:

implementation、api、compileOnly差別詳解

再來看看3.0的:

implementation、api、compileOnly差別詳解

可以看到在Android studio3.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打包。

---------------------

來源:CSDN

原文:https://blog.csdn.net/yuzhiqiang_1993/article/details/78366985

繼續閱讀