Android gradle provided、implementation等指令注意点

其实这类文章博客网上一搜一大堆,但有些地方可能说的不太清楚(都一样的内容,抄袭太严重),这里只是做个精简的总结和一些其他地方没提到的点。

一、Android Studio 3.0开始使用了新的指令,原来的很多被弃用了,总的来说是为了加快构建编译速度。

下面是一个总结表格:

Android Studio 2.X Android Studio 3.X
apk runtimeOnly
provided compileOnly
compile api
没有对应 implementation
debugCompile debugImplementation
releaseCompile releaseImplementation
androidTestCompile androidTestImplementation

需要解释的主要是implementation系列指令:

implementation:注意compile是和api对应的,效果相同。implementation的区别在于对外可见性,而且可以加快编译速度(原理在于减少不必要的重复编译过程)。举个例子如下:

A module 依赖 B module,B 依赖 C module。
Android Studio 2.X使用compile:
A compile B
B compile C
A module不仅可以引用B module,还可以引用C module的接口和类。
Android Studio 3.X使用implementation:
A implementation B
B implementation C
A module只可以引用B module,不可以引用C module。C 对 A 是不可见的!

简单来说,从Android Studio 3.X开始,依赖首先应该设置为implement,如果没有错,那就用implement,如果有错,那么使用api指令,这样会使编译速度有所增快。(就这样理解够了,很多文章又是画图又是长篇大论的,完全没有必要,本来就不是多么复杂的东西)。

二、provided(compileOnly)和compile(api)区别

按照几乎所有文章的说法:

provided只提供编译支持,但是不会写入apk。使用provide可以避免支持包版本冲突和重复打包导致安装包体积徒增。

但就我的实践来说(支持包V7,V4之类):

1、不使用provided也不会导致支持包重复,依赖module编译出来的aar并不包含那些多个module(包括app module)重复使用的支持包。

2、如果依赖module使用的style中引用了支持包(V7,V4之类的)中的主题,那么,使用provided会报错(找不到主题资源)。如果只是引用支持包中的类和接口是可以使用provided的(但意义也不大,反正也不会重复)。

3、可能直接引用jar包的方式会重复把,但现在这种场景不多了。

 

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

 

Android gradle provided、implementation等指令注意点

上一篇:原生js判断某个元素是否有指定的class名的几种方法【转】


下一篇:Kubernetes 1.6 配置可视化界面