本文篇幅较长,仅想看教程的朋友请点击电梯直达
在讲述本文之前,先抛出个问题:为什么做Maven代理服务器?
我认为有如下几个原因 ~~~
why 1. jcenter和google等国外maven库下载慢我们在使用Android Studio开发项目时常常需要下载些依赖库,这些库往往因为我大华夏族的wall变得难以下载(0.xxB/s的速度能下到你怀疑人生)或者索性连接不上,像酱紫:
于是,添加一些国内代理镜像服务器的骚操作孕育而生,比如添加个阿里云maven库,此时你的gradle maven地址脚本可能是酱紫的:
repositories {
// 添加阿里云 maven 地址
maven { url 'http://maven.aliyun.com/nexus/content/groups/public/' }
jcenter()
google()
}
它香吗?是真的香!那种流畅下载的快感真是绝了…
然而他的缺点也有很多,比如依赖库源稀少,依赖库版本同步缓慢,而且阿里云经常宕机和连接超时,有时候还不如直接用
jcenter
和google
库的好。
嗯哼,这样的操作仿佛并没有多少改观现状。
2. 各个maven库资源不尽相同,做不到统配资源就上文而言,我们已经看到有3个maven库了:
aliyun
、jcenter
和google
。
实际开发过程中我们可能需要Gayhub上一些优秀的库,那么就要堆这个地址:
maven { url 'https://jitpack.io' }
有时候我们可能需要使用友盟相关服务sdk,我再堆:
maven { url 'https://dl.bintray.com/umsdk/release' }
有时候我们可能需要使用mob相关服务sdk,我继续堆:
maven { url "http://mvn.mob.com/android" }
有时候。。。给我使劲往里堆。。。最终你的库地址脚本可能是酱紫的:
repositories {
// 添加阿里云 maven 地址
maven { url 'http://maven.aliyun.com/nexus/content/groups/public/' }
jcenter()
google()
maven { url 'https://jitpack.io' }
maven { url 'https://dl.bintray.com/umsdk/release' }
maven { url "http://mvn.mob.com/android" }
aaa...
bbb...
......
}
我要哭了,这么多,脑子都炸了
3. 无法应对gradle频繁性的刷新本地依赖缓存由于gradle机制的特性,在开发过程中改变编译策略或者一些改变gradle配置的举动以及gradle缓存时效性的触发都会导致gradle频繁性的下载和更新本地依赖库缓存。
一提到下载,一阵酸爽的味道扑面而来。。。
4. 开发伙伴间无法共享现成的依赖库比如A伙伴添加了一个流弊的控件库niubility-widget-library到项目中,还可能需要引用某maven地址:http://mvn.niubility.com/ ,此时你的project下的build.gradle脚本是酱紫的:
repositories {
bbb...
......
// 某流弊的控件库 maven 地址
maven { url 'http://mvn.niubility.com/' }
}
需要使用的某module下的build.gradle脚本是酱紫的:
dependencies {
......
// 某流弊的控件库引用id
implementation 'com.niubility:niubility-widget-library:1.0'
}
配置完后在就要
sync
一下,然后gradle就会进行令人窒息的下载依赖库操作,emm…
之后同项目组的B伙伴同步了A伙伴的代码,也得
sync
一下,然后。。。emm…
有一天另一个项目组的C伙伴觉得这个控件很流弊,于是找了A或B同事要了相关配置并集成到自己的项目,仍得
sync
一下,然后。。。emm…
我吐了! 每个人都要艰难得下载一遍,效率也忒差了吧!为啥不能直接共享来自源头A伙伴已下载好依赖库呢?
嗯哼,既然有这么多令人头大的烦恼,也便有了迫切解决烦恼的需求,有了需求就得满足,滋滋滋ZZZzzz…
话到这份子上了,要上教程了?不要着急,先分析一波工作原理 ~~~
what 1. 日常开发拉取依赖库流程a.
AS(Android Studio) Gradle
需要拉取某流弊依赖库:niubility-widget-library:1.0
b. 按build.gradle添加maven地址的顺序先向
aliyun
远程库请求拉取
c. 发现没有该依赖,继而转向
jcenter
拉取
d. 也没有,继续转… 直到
niubility
远程库
e. 有,于是愉快地将依赖库响应给
Gradle
下载,拉取结束
假设
niubility
也没有,且已经是最后一个仓库了,那么流程会是这样的
f. 没有,
Gradle
结束本次拉取并绝望地告诉你“Resource not found!”
2. 使用代理服务器的拉取依赖库流程
a.
AS Gradle
需要拉取某流弊依赖库:niubility-widget-library:1.0
b. 向代理服务器请求拉取
c. 代理服务器按添加代理maven库的顺序先向
aliyun
代理库拉取
d.
aliyun
代理库先询问本地缓存库有没有
d. 没有,则向
aliyun
远程库请求拉取
d.
aliyun
远程库也没有,继而转向jcenter
代理库拉取
e. 折腾一波也没有,继续转… 直到
niubility
仓库
f. 本地缓存库有,于是愉快地将缓存依赖库响应给
Gradle
下载,拉取结束
假设
niubility
本地缓存库没有,则向niubility
远程库请求拉取
g. 有,于是愉快地将依赖库响应给
niubility
代理库下载并缓存本地,然后响应给Gradle
下载,拉取结束
再假设远程库也没有,且已经是最后一个代理仓库了,那么流程会是这样的
d. 没有,告诉
Gradle
没有,Gradle
结束本次拉取并绝望地告诉你“Resource not found!”
额,语言描述有些苍白,那就贴图加持吧:
3. 总结Maven代理服务器的原理和优势分析上文1和2两个流程可以看出:
Maven代理服务器接替并简化了
AS Gradle
同各个Maven远程库繁杂的注册和交互工作,其不需要再关心需要配置哪些Maven库,以什么方式拉取依赖库,所需即所得。解决了why–>2的问题。
Maven代理服务器每向远程库拉取依赖库的同时会缓存至服务器本地,以便于
AS Gradle
的快速拉取。解决了why–>3和why–>4的问题,缓解了why–>1的问题。
别啊,涨粉不易啊亲,这就开始 ~~~
how 1. Nexus Maven服务器搭建篇参考此前文章《基于Nexus 3.x搭建Gradle Maven本地私有仓库》的“一”和“二”步骤即可。 已搭建过的童鞋请骂骂咧咧地退出本步骤 ~~~
2. Maven代理服务器构建篇 创建代理maven仓库,本文以aliyun
为例
新建仓库:
选择
maven2 (proxy)
:
任起仓库名称,填入
aliyun
远程仓库地址,其它默认直接创建:
同样,再创建
jcenter
等代理仓库
创建代理maven仓库组
参考上文流程,新建仓库,选择
maven2 (group)
。
任起仓库名组称,选择需要加入组的代理仓库,其它默认直接创建:
创建完成后,返回到仓库列表界面,找到刚创建的“android-repos”仓库组一栏,点击“copy”按钮复制地址,本文为:http://localhost:8081/repository/android-repos/
嗯哼,大功告成!你的gradle maven地址仅需一个代理库组地址即可,其它地址可以全部拜拜了~
repositories {
// 代理库组地址
maven { url 'http://localhost:8081/repository/android-repos/' }
}
如此简洁的配置,你不心动吗?如此高效的资源共享,你不心动吗?如此6得飞起的下载速度,你不心动吗?动手吧,骚年~
作者:皓煙