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，所以对运行不影响）。