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

环境准备

升级Gradle插件至3.0.0及以上

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以上最大的区别是依赖方式的改变：


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