android gradle 4.1以上依赖的改变:compile->api和implementation

转载请注明出处:
android gradle 4.1以上依赖的改变:compile->api和implementation

地址:http://blog.csdn.net/qq_22744433/article/details/78345225

提前准备

升级到gradle插件(gradle-tools)3.0.0:

  • 需要gradle版本升级到4.1以上。
  • android studio版本升级到3.0.0以上。

依赖使用api和implementation,废弃compile

区别示意图

提示一下:gradle tools升级到3.0.0以上,compile关键字 已经明确写明废弃了(api关键字的作用等同于之前的compile),但是google官方文档上说“还会保留一段时间,直到下个比较大的gradle tools版本发布”。所以现在仍然使用compile,不会报错。

gradle插件升级到3.0.0以上最大的区别是依赖方式的改变:

implementation的“访问隔离”只作用在编译期

implementation的“访问隔离”只作用在编译期。什么意思呢?如果lib C 依赖了lib A 2.0版本,lib B implementation依赖了lib A 1.0版本:

  • 那么编译期,libC 可访问2.0版本的libA ,libB可访问1.0版本的libA。但最终打到apk中的是2.0版本(通过依赖树可看到)。
  • 在运行期,lib B 和lib C都可访问lib A的2.0版本(因为apk的所有dex都会放到classLoader的dexPathList中)。

使用implementation有什么好处

  • 如果项目中有很多级联的工程依赖,比如上图中lib A B C的依赖是工程依赖。如果使用的依赖方式是compile/api,那么当lib A接口修改后重新编译时,会重新编译libA B C(即使lib C中并没有用到修改的libA的接口)。如果使用implementation依赖,因为“编译期隔离”的原因,不相关的lib就不会进行重新编译。
  • 如果项目中都是aar依赖,编译减少时长这个优点就没有了(因为aar已经是编译好的字节码了)。那么还有什么用呢?还是以上图为例。之前我们都是compile依赖,如果lib A已经依赖了lib B,那么在libC的build.gradle中就不用写lib A的依赖了。但这样会有问题:
    • 我从lib C的build.gradle的依赖列表中不能完整的知道libC都需要依赖哪些lib。
    • 假设这么一种情况,我知道项目中的依赖的libA的最高版本是2.0,那么app运行时就是使用的这个2.0版本的libA。这时候我需要打一个libC的aar。lib C如果通过compile传递依赖了libA,因此从lib C的build.gradle中不知道lib C 编译时依赖的是哪个版本的lib A。如果libC 打aar(编译)时,依赖的仍然libA 1.0,可能这个aar就有问题了。

所以使用implementation是一种比较规范的依赖做法。虽然可能需要多写一写依赖,但是项目的可读性是有很大好处的(虽然多写一些依赖,apk打包运行时仍然是采用最高版本的lib,所以对运行不影响)。

你可能感兴趣的:(gradle,gradle,android)