标签：工程   组合   pretty   res   src   test   provided   技术分享   ati   

原文链接：
https://jeroenmols.com/blog/2017/06/14/androidstudio3/

https://blog.csdn.net/lonewolf521125/article/details/78482880

更新到 Android Studio 3.0 之后，构建多 module 结构的项目速度有很大的提升，但不幸的是这同样意为着 Gradle 插件的 API 也做了修改.

本文将详细的介绍本次改变的优点，以及使你能够顺畅应用升级。

目前的问题

为了理解 Gradle plugin 2.0 编译系统的限制，现在考虑下面这个拥有多层引用 module 的工程：

现在请考虑一下最下面的 module A，对 module A 一般来讲会有两种变化：

1. Implementation change（内部实现的更改）：
   内部更改，未涉及到对外的接口变更
2. ABI change（Application binary interface change；对外接口的更改）：
   module A 对外的接口做了修改

注意：下文中，所有重编译的 module 都会用红色高亮显示。

Implementation change

既然 module A 的对外接口未做更改，那么 Gradle 自然也只对 module A 做重编译。所有 module A 的消费者（实际就是直接或间接引用到 module A 的其他 module）都不会受到影响。

在此场景下没有什么问题。

ABI change

当 module A 的对外接口做更改的时候，module A 的直接消费者 B1、B2、B3（也就是直接引用到 module A 的其他 module）也需要重编译。

但是 A 的直接消费者们（B1、B2、B3)有可能通过自己( B1、B2、B3 )的接口将 A 暴露出去!所以为了保险起见，这些引用到 B1、B2、B3 的 module （C1、C2、C3） 也需要从编译。同样的引用到 C1、C2、C3 也一样需要重新编译…

因此 Gradle 实际上需要对所有的 module 进行重编译。

现在我们遇到了一个大问题：

一个代码的更改引发了所有 module 的重编译。
本问题最根本的原因是 Gradle 并不知道你是否通过一个 module 将其引用到的另一个 module 接口给泄露出去了（例如 Gradle 并不知道你是否在 module B1 中将 A module 的接口暴露给了 App）。

救星来了（Android Gradle plugin 3.0）

现在最新一版的 Android Gradle 插件需要你明确的指出你是否要将某 module 的接口暴露出去。基于此它可以在判断某 module 是否需要重编译时做出正确的选择。

compile 已被弃用，并由两个新的替代：

• api：通过你自己的接口将你引用到的 module 接口暴露出去供其他 module 使用，含义上实际与 compile 一致

  比如：对于 B1 module ，如果其引用 A module 时使用了 api ，那么 C1 就可以使用到 A module 的接口

• implementation：仅仅将你引用到的此 module 在内部使用，而不将其接口暴露给外部

  比如：对于 B1 module，如果其引用 A module 时使用了 implementation，那么 C1 无法使用到 A module 的接口

基于以上，现在你就可以明确的告诉 Gradle 某个 module 在它引用的 module 更改时进行重编译，在它引用的 module 未更改时不做重编译。

示例如下：

dependencies {

  //当 legofy 对外接口更新时，重编译本 module 以及所有引用此 module 的 module
  api project(‘:legofy‘)

  //当 landscapevideocamera 对外接口更新时，仅仅重编译本 module
  implementation project(‘:landscapevideocamera:1.0.0‘)
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

迁移指南

（废弃 compile 改用 api 和 implementation 形式的操作指南）

理论上你可以将所有的 compile 都修改为 api（运行上不会报任何错误），但是这种方式还是可能会因为一个代码的变动引发所有 module 的重编译：

所以最好的方式是尽量使用 implementation 替换 compile ，当且仅当想将你引用的 module 暴露出去的时候再用 api，按照这种方式会减少很多重编译。

希望这篇文章能尽量阐明 api 与 implementation 之间模糊的含义
（至于官方的迁移文档，呵呵哒）

其他的依赖配置

团队也利用这次变更最终给予其他配置以适当的名称：

• provided 配置现在改成了 compileOnly
• apk 配置现在改成了 runtimeOnly

就像之前一样，你可以将配置与 variants 进行组合：debugApi、testImplementation 等

#其他的迁移项目
~~Android Studio 3.0 包含了许多终于得到解决的其他改进，我最喜爱的是：~~
* 所有的 google dependencies 在 Maven 在线仓库中都可以被访问到
~~。。。~~

详细信息：
https://developer.android.com/studio/preview/features/new-android-plugin-migration.html

总结：

为了提升多项目结构的构建速度， Android Gradle plugin 需要一个突破性的提升。尽量使用 implementation （因为它会引发更少的 module 重编译）

--------------------- 本文来自 杨筱毅 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/lonewolf521125/article/details/78482880?utm_source=copy 

[Android] Implementation vs API dependency

标签：工程   组合   pretty   res   src   test   provided   技术分享   ati   

原文地址：https://www.cnblogs.com/0616--ataozhijia/p/9753948.html