安卓工程依赖新方式：Implementation vs API dependency

内容简介：安卓工程依赖新方式：Implementation vs API dependency

升级到 Android studio 3.0版本会使多Module工程的构建速度加快很多。不幸的是，这也带来了Gradle 插件版本API的较大变化。本文将会详细指出这个变化带来的好处，并且指导读者怎么去升级。

ps: Android plugin 3.0.0搭配Gradle 3.4版本以上

原英文文章链接

• 问题现状

为了理解老版本Gradle plugin 2.0构建系统的限制，这里假设有个工程使用了多层module依赖方式。请看下图。

本module指的是调用dependency的module

注意，所有需要重新编译的module将会用红色标出。

• Implementation 变化

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

  

• ABI变化当本module依赖的ib(也可以是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依赖，整体来说，会减少很多重新编译。这一点，在官方指南中说的比较明确。

• 其它的变化

  既然有了比较大的改变，索性官方团队利用此机会改了更多配置属性的名字，

  比如provided改成了compileOnly，apk改成了runtimeOnly

大体如上，详情可参考 官方迁移指南

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• Swift 中几种不同的依赖注入方式
• Spring依赖注入的三种方式实例详解
• 从Hessian RPC 注解方式看Spring依赖注入
• ASP.NET Core应用的7种依赖注入方式
• Gradle的依赖方式——Lombok在Gradle中的正确配置姿势
• 浅析依赖倒转、控制反转、IoC 容器、依赖注入。

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。