随着AndroidStido3.0的发布,更新,我们会发现项目之前使用的compile以及被弃用了,而被取代为 implementation。下面就介绍一下AS3.0+版本中各种依赖关系的使用.

   在Android studio3.0中,compile依赖关系已被弃用,被implementation和api替代,provided被compile only替代,apk被runtime only替代,剩下的看名字就知道了。

假如你的现有项目是运行在AS 2.0+的,在你的AS升级到3.0+后,会出现如下错误:

当然,只需要将原先的依赖关系根据提示替换为新的依赖关系就好了,但是, 现在市场上大型app由于业务繁多,大多采用组件化的方式,这时候就需要新建多个moudle,moudle之间都是依赖的。例如下图分moudle的方式:

主要的pppcar依赖其它basemodule和my_library等;

我们先来看看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这个错误。


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打包。


看了上面的介绍我们就可以找到对应的依赖关系了

谷歌为什么要把compile改成implementation?

  1. 使moudle之间解耦,不相互依赖。

我们都知道组件化,单个moudle是可以直接运行的,我们想单独运行moudle-prod模块,如果使用的是compile的话,编译的时候app moudle也需要重新编译,但是使用implementation,app moudle就不会编译了。间接提高了编译速度。

Last modification:March 26th, 2019 at 07:51 pm
If you think my article is useful to you, please feel free to appreciate