Android Studio 依赖方式 implementation 与 compile（API dependency）的区别

前言

在android studio 3.0 版本之前，第三方库或者module的依赖方式有compile、implementation。android studio 3.0 版本之后，compile被取代，改用API dependency，实质完全等同于compile。

implement

概念 : 将该依赖隐藏在内部，而不对外部公开。

理解 : 在 app mudule 中使用 implement 依赖的第三方库, 在其他 mudule 是无法调用的.

举例 : 此时项目中有一个 mudule 是 ImageLoader ,其内部用 implement 指令依赖了 glide 这个库, 那么此时我们在 app mudule 中无法调用 glide 库中的方法.

compile

概念: android studio 3.0 版本后废弃该指令 改用 api 代替, api 完全等同于之前的 compile 指令, 也就是普通的依赖, 第三方库在 mudule 中依赖后其他 mudule 都可以使用该库.

官方推荐在不影响的前提下优先使用 implement 指令依赖.

compile-->api 

对比Implementation 变化 & compile 变化 ：

Implementation 变化 

当本module依赖的ib(也可以是module)发生变化时，由于本module对外暴露的接口并不发生变化，在构建工程时gradle将会只重新编译本module，所有依赖于本module的module并不会发生编译。这种情况是没什么问题的。如图所示。

compile 变化 

当本module依赖的lib(也可以是module)发生变化时，本module向外暴露的接口发生了变化，那么所有直接依赖于本module的module将不得不重新编译。

接下来，这些上层module可能通过其本身的接口对外暴露了底层module的部分内容，即意味着本module暴露的接口也发生了变化，这会使得依赖于上层module的上上层module也需要重新编译。这就导致了一个连锁效应，因此，为了绝对的安全起见，gradle将不得不重新编译整个工程，使得编译时间变得较长。如图所示。

那么重点来了：一点代码的改动可能会引起整个工程的重新编译，这将是多么悲催，而实际上我们之前的gradle插件2.0版本系列的确如此，根本原因就是gradle压根不知道暴露的接口可以通过一个接一个的依赖传递影响整个工程。

• Android Gradle plugin 3.0带来了解决方案 
  最新版的Gradle plugin需要你指出一个module的接口是否对外暴露其依赖lib的接口。基于此，可以让项目构建时，gradle可以判断哪个需要重新编译。因此，老版本的构建关键字compile被废弃了，而是改成了这两个：
• api：同compile作用一样，即认为本module将会泄露其依赖的module的内容。
• implementation：本module不会通过自身的接口向外部暴露其依赖module的内容。 
  由此，我们可以明确的告诉gradle去重新编译一个module，若是这个使用的module的接口发生变化的话。

• dependencies {
  //当legofy接口发生变化时，需要重新编译本module以及所有使用本module的module
  api project(':legofy') 
  // 仅当landscapevideocamera发生变化时，重新编译本module
  implementation project(':landscapevideocamera:1.0.0')
  }

  
  

• 迁移指南 
  理论上，你可以将原来工程中的compile完全替换为现在的api，但是一旦依赖发生变化，将会使所有的module重新编译，造成编译过长。

所以更好的方式就是使用implementation来进行依赖，这会大大改善工程的构建时间。只有你明确要向外部暴露所依赖lib的接口时，才需要使用api依赖，整体来说，会减少很多重新编译。这一点，在官方指南中说的比较明确。