随着 AndroidStido3.0 的发布，更新，我们会发现项目之前使用的 compile 以及被弃用了，而被取代为 implementation。下面就介绍一下 AS3.0 + 版本中各种依赖关系的使用.
# 在 Android studio3.0 中，compile 依赖关系已被弃用，被 implementation 和 api 替代，provided 被 compile only 替代，apk 被 runtime only 替代，剩下的看名字就知道了。
假如你的现有项目是运行在 AS 2.0 + 的，在你的 AS 升级到 3.0 + 后，会出现如下错误:
当然，只需要将原先的依赖关系根据提示替换为新的依赖关系就好了，但是，现在市场上大型 app 由于业务繁多，大多采用组件化的方式，这时候就需要新建多个 moudle，moudle 之间都是依赖的。例如下图分 moudle 的方式:
主要的 pppcar 依赖其它 basemodule 和 my_library 等；
我们先来看看 implementation 和 api 的区别：
#####api：跟 2.x 版本的 compile 完全相同
#####implementation：只能在内部使用此模块，比如我在一个 libiary 中使用 implementation 依赖了 gson 库，然后我的主项目依赖了 libiary，那么，我的主项目就无法访问 gson 库中的方法。这样的好处是编译速度会加快，推荐使用 implementation 的方式去依赖，如果你需要提供给外部访问，那么就使用 api 依赖即可
### 还不熟悉 2.x 版本依赖的可以看看下面的说明，括号里对应的是 3.0 版本的依赖方式。
##compile（api）
这种是我们最常用的方式，使用该方式依赖的库将会参与编译和打包当我们依赖一些第三方的库时，可能会遇到 com.android.support 冲突的问题，就是因为开发者使用的 compile 依赖的 com.android.support 包，而他所依赖的包与我们本地所依赖的 com.android.support 包版本不一样，所以就会报 All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes 这个错误。
##provided（compileOnly）
只在编译时有效，不会参与打包可以在自己的 moudle 中使用该方式依赖一些比如 com.android.support，gson 这些使用者常用的库，避免冲突。
##apk（runtimeOnly）
只在生成 apk 的时候参与打包，编译时不会参与，很少用。
##testCompile（testImplementation）
testCompile 只在单元测试代码的编译以及最终打包测试 apk 时有效。
##debugCompile（debugImplementation）
debugCompile 只在 debug 模式的编译和最终的 debug apk 打包时有效
##releaseCompile（releaseImplementation）
Release compile 仅仅针对 Release 模式的编译和最终的 Release apk 打包。
看了上面的介绍我们就可以找到对应的依赖关系了
# 谷歌为什么要把 compile 改成 implementation？
# 1. 使 moudle 之间解耦，不相互依赖。
我们都知道组件化，单个 moudle 是可以直接运行的，我们想单独运行 moudle-prod 模块，如果使用的是 compile 的话，编译的时候 app moudle 也需要重新编译，但是使用 implementation，app moudle 就不会编译了。间接提高了编译速度。
