我们先解释一下 外部依赖 和 本地依赖 是什么。
[](()外部依赖
外部依赖,顾名思义,就是从远程仓库拉取的依赖,也被称为常用的 三方库:
// 从远程仓库拉取的开源代码库
implementation ‘com.facebook.stetho:stetho:1.5.1’
implementation ‘io.reactivex.rxjava3:rxjava:3.0.0-RC0’
[](()本地依赖
本地依赖,也就是我们项目中常见的module,按照**《阿里Java开发手册》**中来描述,也叫做 一方库:
implementation project(‘:library’)
好的,现在我们了解了这两个基本概念,问题来了:
_3_知道这些有什么用?
有同学肯定会有这个困惑,这些概念我虽然都了解了,但实际开发过程中我并没有用到这些, 项目依然稳定的迭代和运行,那学习这些东西有什么用呢?
这些规则真的很有用,在实际开发过程中,我们肯定会遇到一些问题,这些问题我们通过baidu或者google的方式绕了过去,但是这真的解决了吗?
比如说 依赖冲突。
[](()1.根据某些条件对依赖进行替换
举个例子,很多UI三方库都会依赖RecyclerView,但这么多的依赖库,我们不可避免遇到版本不同导致依赖冲突的情况,一般情况下,我们是这么解决的:
// 将RecyclerView的依赖从这个三方库中排除掉
implementation “xxx.xxx:xxx:1.0.0”,{
exclude group: ‘com.android.support’, module: ‘recyclerview-v7’
}
将RecyclerView的依赖从这个三方库中排除掉,令其使用项目本身的RecyclerView版本,这样项目就可以正常运行了,看起来并没有什么问题。
JakeWharton 非常敏锐地点出了问题的所在——试想,如果项目的依赖比较复杂,也许我们要面对的将是这样的依赖配置:
implementation “libraryA:xxx:1.0.0”,{ exclude group: ‘com.android.support’, module: ‘recyclerview-v7’}implementation “libraryB:xxx:2.2.0”,{ exclude group: ‘com.android.support’, module: ‘recyclerview-v7’}implementation “libraryC:xxx:0.0.8”,{ exclude group: ‘com.android.support’, module: ‘recyclerview-v7’}
我们需要将每个依赖了RecyclerView的三方库都通过exclude的方式移除掉本身对应的依赖,这种缝缝补补式地乱堵,不正是在 打地鼠 么。
针对类似这种情况,我们可以在gradle的构建过程中强制指定依赖的版本,以笔者的项目为例, 《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》无偿开源 徽信搜索公众号【编程进阶路】 我们针对RxJava的版本依赖进行了统一:
现在,项目中所有RxJava相关的依赖,在构建过程中版本都统一使用了3.0.0-RC0,这样就 避免了依赖冲突,开发者再也不需要针对每一个有RxJava依赖的三方库进行额外的exclude了。
[](()2.本地依赖替换为外部依赖
本地依赖替换为外部依赖,最经典的场景就是SDK的发布测试,如果您有过开源项目的经历,对此一定不会陌生。
以笔者开源的 RxImagePicker 为例,日常开发过程中,sample代码依赖本地的module;新版本发布后,笔者的UI测试代码便需要通过依赖jcenter远程仓库的最新代码。
https://github.com/qingmei2/RxImagePicker
这种情况下,通过dependencySubstitution便可以非常方便对这两种场景进行切换:
useRemote只是定义在build.gradle文件中的一个变量,作为切换开发-测试环境的开关:
final boolean useRemote = true
当useRemote值为true时,sample依赖远程仓库,当值为false时,sample依赖本地module。
看起来代码量反而增加了,实际上,随着项目复杂度的提升,这种全局的配置优点显而易见。
[](()3.将外部依赖替换为本地依赖
该规则和2非常相似,只不过将依赖替换的双方调换了而已,下面是官方的示例代码:
configurations.all {
resolutionStrategy.dependencySubstitution {
substitute module(“org.utils:api”) because “we work with the unreleased development version” with project(“:api”)
substitute module(“org.utils:util:2.5”) with project(“:util”)
}
}