Android Gradle的依赖方式
一、Android Studio2.X与3.X依赖对比
二、Android Studio2.x依赖说明
PS：括号内为对应3.X版本的依赖
- compile（api）
使用compile依赖方式依赖的库将会参与编译和打包。 - provided（compileOnly）
只在**编译时有效，不会参与打包，**可以在自己的module中使用该方式依赖。比如com.android.support、gson等常用的库，避免冲突。 - apk（runtimeOnly）
只在生成apk的时候参与打包，编译时不会参与。 - androidTestCompile（androidTestImplementation）
androidTestCompile只在单元测试代码的编译以及最终打包测试apk时有效。 - debugCompile（debugImplementation）
debugCompile只在debug模式的编译和最终的debug apk打包时有效。 - releaseCompile（releaseImplementation）
releaseCompile仅仅针对Release模式的编译和最终的Release apk打包。
三、3.x新依赖引入的原因
Android Studio3.X引入新的依赖方式的原因：
首先，假设这样一种情况：
一个App工程往往是由许多互相依赖的module所组成，对于处于最底层、最基础的module有两种可能的变化：
Implementation change：内部代码变更，但是模块的外部接口不变。
Application binary interface（ABI） change：外部接口修改。
- Implementation change
因为module的外部接口没有改变，所以Gradle只会重新编译变更的module，其他依赖它的module则不会编译，如图所示（其中红色的module表示需要重新编译的module）：
- ABI change
如果模块的外部接口发生了改变，那么所有依赖了该module的其他module都需要重新编译，这使得编译时间变长。
Android Gradle 2.X中的compile处理的情况属于后者，即使用compile依赖方式，那么当一个module改变的时候，依赖于该module的所有module都需要重新编译；而3.X版本中引入了一个新的依赖方式——Implementation，使用该依赖方式只在内部使用了该module，不会向外部暴露其依赖的module内容。
四、Implementation、api与compile的关系与区别
Implementation：使用了该命令编译的依赖，对该项目有依赖的项目将无法访问到使用该命令编译的依赖中的任何程序，也就是将依赖隐藏在内部，不对外部公开。
三者的关系：compile和api对应，效果相同；implementation的区别在于对外可见性，而且可以加快编译速度（原理在于减少不必要的重复编译过程）。
五、关于compileOnly与annotationProcessor的注意点
在使用依赖中，还有一个依赖方式annotationProcessor，该依赖与compileOnly类似，都是只编译并不打包入apk。
区别：
annotationProcessor的作用是编译时生成代码，编译完就不需要该依赖。
compileOnly作用于用重复的库的情况，目的为避免库的重复冲突，最终在apk打包中实现包含的该依赖不重复，即该依赖是需要的。
参考资料：理解Android新的依赖方式
Android依赖导入全攻略
Android Studio 3.0中dependencies依赖由compile变为implementation的区别
Android gradle provided、implementation等指令注意点