本文翻译于 Bedanta Bikash Borah 的文章,原文链接如下:
当我们在Android项目中使用 Gradle 3.0 及以上版本的插件,你一定会注意到 compile
关键字已经被弃用来支持 implementation
和 api
。让我们借助一个例子来了解它们。
示例应用 (Kotlin) 可以在这里找到。
让我们假设有一个 Android 项目包含以下四个 library module:
- LibraryA
- LibraryB
- LibraryC
- LibraryD
它们之间的依赖关系如下所示:
每个 Library module 都包含一个简单的类。
LibraryD:
class ClassD {
fun tellMeAJoke():String{
return "You are funny :D"
}
}
LibraryC:
class ClassC {
fun tellMeAJoke(): String {
return "You are funny :C"
}
}
LibraryB:
class ClassB {
val b = ClassD()
fun whereIsMyJoke(): String {
return b.tellMeAJoke()
}
}
LibraryA:
class ClassA {
val c = ClassC()
fun whereIsMyJoke(): String {
return c.tellMeAJoke()
}
}
从上面这些类文件中可以看到 LibraryA 和 LibraryB 分别依赖于 LibraryC 和 LibraryD。因此,需要将它们之间的依赖关系添加到 build.gradle
文件当中。
Compile (2.0) or Api (3.0):
3.0 中新的 api
关键字与之前版本的 compile
关键字意义完全相同。因此,如果项目中所有 compile
关键字被 api
所取代,这完全可以正常工作。现在,让我们在 LibraryB 中通过 api
关键字来依赖 LibraryD:
dependencies {
. . . .
api project(path: ':libraryD')
}
同样地,将 LibraryB 添加到 app 模块中:
dependencies {
. . . .
api project(path: ':libraryB')
}
现在,我们可以在 app 模块中访问到 LibraryB 和 LibraryD。在示例应用中,两个库的访问形式如下:
Implementation (3.0):
现在是时候来找出 implementation
和 api
之间的不同之处了。再次回到上面这个例子,现在让我们在 LibraryA 中通过 implementation
关键字引入 LibraryC:
dependencies {
. . . .
implementation project(path: ':libraryC')
}
App 模块同理:
dependencies {
. . . .
implementation project(path: ':libraryA')
}
现在,如果我们在 app 模块访问 LibraryC,Android studio 将会抛出一个错误:
这意味着如果我们使用 implementation
关键字代替 api
,LibraryC 将无法在 App 模块中被访问。那么 implementation
这样做有什么好处呢?
Implementation vs api:
在第一个场景中,LibraryD 是通过 api
关键字来编译的。一旦 LibraryD 中的实现做了任何改动,那么 gradle 都需要重新编译 LibraryD,LibraryB 和所有其他引入 LibraryB 的模块一样可能使用的是 LibraryD 中的实现。
但在第二个场景中,如果更改了 LibraryC 中的代码实现,那么 Gradle 只会重新编译 LibraryC 和 LibraryA,因为其他任何没有直接依赖 LibraryC 的类都无法使用其中任何实现。
如果你正在开发具有多个模块的项目,那么这种策略可以显著加快构建过程。我在示例程序中进行了尝试,几秒钟后就有了一些改进。以下是所有方案的构建报告。
全量构建:
变更 LibraryD:
变更 libraryC
总结
Android Gradle 插件版本升级至3.0之后,我们只需要将所有 compile
替换为 implementation
关键字并尝试构建项目。如果可以构建成功,那么很好。否则,请查找任何你可能正在使用的遗漏的依赖库,并找到宿主 library 换用 api
关键字引入这些 library。