Android Gradle 4.1以上依赖变化:compile->api和implementation

环境准备

升级Gradle插件至3.0.0及以上

1
2
3
dependencies {
classpath 'com.android.tools.build:gradle:3.1.3'
}
  • Gradle版本升级到4.1及以上
  • gradle-plugin版本升级到3.0.0及以上

依赖使用api和implementation,废弃compile

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

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

![Gradle implementation编译期访问隔离](http://www.yezhou.me/AppBlog/images/Android/Gradle implementation编译期访问隔离.jpg)

implementation的“访问隔离”只作用在编译期。什么意思呢?如果lib C implementation依赖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接口修改后重新编译时,会重新编译lib A B C(即使lib C中并没有用到修改的libA的接口)。如果使用implementation依赖,因为“编译期隔离”的原因,不相关的lib就不会进行重新编译。

如果项目中都是aar依赖,编译减少时长这个优点就没有了(因为aar已经是编译好的字节码)。那么还有什么用呢?还是以上图为例。之前我们都是compile依赖,如果lib B已经依赖了lib A,那么在lib C的build.gradle中就不用写lib A的依赖了。但这样会有问题:

  • 从lib C的build.gradle的依赖列表中不能完整的知道lib C都需要依赖哪些lib。
  • 假设项目中依赖的lib A的最高版本是2.0,那么app运行时就是使用的这个2.0版本的lib A。这时候需要打一个lib C的aar。lib C如果通过compile传递依赖了lib A,此时从lib C的build.gradle中不知道lib C 编译时依赖的是哪个版本的lib A。如果lib C 打包aar(编译)时,依赖的仍然libA 1.0,可能这个aar就有问题。
    所以使用implementation是一种比较规范的依赖做法。虽然可能需要多写一写依赖,但是项目的可读性是有很大好处的(虽然多写一些依赖,apk打包运行时仍然是采用最高版本的lib,所以对运行不影响)。

Powered by AppBlog.CN     浙ICP备14037229号

Copyright © 2012 - 2020 APP开发技术博客 All Rights Reserved.

访客数 : | 访问量 :