原文地址: https://juejin.cn/post/6844903488833454093

前言

Hello,我是 JessYan,作为一个喜欢探索新颖解决方案的我,在上篇文章中,向大家介绍了怎样通过一行代码即可实现上传下载以及 Glide 进度监听,现在又给大家带来了另一项大家都很期待的问题的解决方案,这个问题起源于 MVPArms 的一个 Issues ,当然使用 Retrofit 时,多个 BaseUrl 以及动态切换 BaseUrl 这两个需求,在其他地方也经常被讨论,那么下面就来讲讲我的思路和解决方案

Github : 你的 Star 是我坚持的动力 ✊

需求出现的场景

也许在日常开发中有些人已经遇到了这两个需求的场景,但为了让一些之前没遇到这些场景的朋友,也能看懂这篇文章,所以先在前面提一提

多个 BaseUrl 的需求场景

如果项目是聚合型 App ,比如像一些新闻资讯类客户端,可能数据源来自于多个平台,比如说知乎啊,豆瓣啊,今日头条啊,所以这样就会涉及到多个 BaseUrl

如果项目使用到多个三方服务提供商,比如图片的读取使用到一个服务商,文件的存储又使用到另一个服务商,这个也会存在一个 App 出现多个 BaseUrl

动态改变 BaseUrl 的需求场景

如果项目的 BaseUrl 会在 App 启动时,请求服务器,根据服务器的返回结果,来确定项目最终的 BaseUrl,就会涉及到运行时动态切换 BaseUrl

如果项目的某个三方服务提供商,并不是固定的,也许会出现变更的情况,比如存储服务从七牛迁移至其他云存储,那我们为了避免更改代码导致重新打包以及发版,就会从服务器获取三方服务提供商的 BaseUrl ,然后在运行时动态改变这个 BaseUrl

解决方案

其实官方 Api 早已经提供了解决方案来支持多个 BaseUrl 以及运行时动态改变 BaseUrl ,民间也同样有很多解决方案

官方静态解决方案

熟悉 Retrofit 的开发者应该知道 @Get , @Post 这些标注到每个接口方法上的注解不仅可以传相对路径,还可以传全路径,这样我们就可以做到不同的接口使用不同的 BaseUrl ,从而达到使用多个 BaseUrl 的需求,但是注解上的值只能是 Final 的常量,不能动态改变,所以我称这个解决方案为静态解决方案

官方动态解决方案

熟悉 Retrofit 的开发者也同样知道 @Url 这个标注到每个接口方法参数上的注解,它可以将全路径作为参数传进接口作为每次请求的 Url 地址,每次请求接口都可以将不同的全路径作为参数,从而达到支持多个 BaseUrl 以及在运行时动态改变 BaseUrl ,所以很多请求图片等资源的接口都是使用这个方案(咦,看样子这个官方解决方案不是同时解决我提到的这两个问题吗,别急,先往后面看!)

民间常用解决方案

之前也看过很多开源的聚合类 App 源码,像一些整合知乎 , 豆瓣 , Gank 等多个平台数据的 App ,因为各自平台的域名不同,所以大多数这类 App 会给每个平台都各自创建一个 Retrofit 对象,即不同的 BaseUrl 使用不同的 Retrofit 对象来创建 ApiService 进行请求,这样只要新增一个不同的 BaseUrl ,那就需要重新创建一个新的 Retrofit 对象

这样也可以同时实现,支持多个 BaseUrl 以及运行时动态改变 BaseUrl 这两个需求,但是以个人的观点,创建多个其他配置属性一模一样,只是 BaseUrl 不一样的 Retrofit 对象,太过于浪费资源

民间大牛解决方案

之前偶然看到了一个 Retrofit 维护者, Square 公司的大牛的解决方案,用来解决运行时动态改变 BaseUrl ,其实也算半官方的解决方案

提到这个解决方案时,不得不讲一个趣事,其实之前 Retrofit 默认是支持运行时动态改变 BaseUrl 的,以前是有一个名为 BaseUrl 的接口,而 Retrofit.Builder#baseUrl(BaseUrl) 方法当时传的参数就是这个 BaseUrl ,而不是现在的 HttpUrl ,这个接口内部就有一个方法返回 HttpUrl ,那时候只要实现 BaseUrl 后,动态改变这个方法的返回值,就可以实现动态改变 BaseUrl

但是这位大牛认为这样的做法不安全,所以提了一个 Pull Requests ,删掉了这个 BaseUrl 接口,并用上面的解决方案替代之,而亲爱的 JakeWharton 同意了他的观点,并合并了这个 PR 于是才有了现在的 Retrofit.Builder#baseUrl(HttpUrl) 这个不能动态改变 BaseUrl 的 Api

用 Retrofit 比较早的老鸟,应该知道以前有一个这个 Api,我是说后来的版本怎么没了,原来毁在了这位兄台手上

这个方案也就是利用 Interceptor 拦截器,动态改变每个 Request 的 Url 从而实现动态改变 BaseUrl,但他这个解决方案不能支持多 BaseUrl ,只要 host 一设置,直到下一次改变 Host 之前,后面的所有 Request 都必须使用同一个 Host ,还有一些弊端后面一起分析

几个方案的对比与分析

淘汰含有明显缺陷的方案

4个方案中,我首先淘汰的就是 民间常用解决方案 ,在前面已经明确了我的观点,因为我个人认为创建多个其他配置属性一模一样,只是 BaseUrl 不一样的 Retrofit 对象,太过于浪费资源,所以就算他能满足我的所有需求,除非真的没有更好的解决方案,否则我是不会选择它的

剩下的三个方案中, 官方静态解决方案 只能解决,2个需求中的支持多个 BaseUrl ,而对于动态改变 BaseUrl ,由于注解的 Value 只能为常量,所以对这个需求也是无能为力的(两个需求都满足,才表示可行)

谁是最优方案?

其实在前面已经说了 官方动态解决方案 就已经可以同时实现多 BaseUrl 和运行时动态改变 BaseUrl ,那为什么我不直接选择这个方案,还要继续分析呢?

答案也很简单,我认为这个方案,虽然灵活,但是灵活却给它带来了使用上的繁琐,每个接口每次调用都必须传入全路径作为参数,不仅繁琐而且接口一多还不好管理

那 民间大牛解决方案 可行? 但是我在前面已经说了这个不可行啊?

这个方案虽然可以支持运行时动态切换 BaseUrl 但是它是全局处理,一经使用改变的是所有请求的 Url ,所以它并不支持多 BaseUrl

并且更可怕的是,这个方案不仅不支持多 BaseUrl ,还会影响 官方静态解决方案 和 官方动态解决方案 这两个支持多 BaseUrl 的方案,因为不管你注解里面声明的是什么全路径,它的 Interceptor 拦截器,都会强行将这个请求的 Url 改成它的 BaseUrl ,所以这个方案注定只适合只有一个 BaseUrl 但需要动态改变的项目

那岂不是 4 个解决方案都不可行?说这么久说个毛线啊?

方案全部淘汰?散会？

等等别急啊,虽然我站在我的角度, Pass 了文中提到的所有已存在的解决方案

但是大家仔细想想,如果网上已经存在完美的解决方案,那我还写这篇文章有什么意义?必定是没有我满意的解决方案,我才会自己动手去解决并分享啊,毕竟我是一个不愿意写重复内容的有为青年,只要是我写的内容肯定是会让大家学到不一样的知识三 ✊,不然不是砸自己招牌

好了,不逗大家了,开整!

别急,还有大招!

虽然在已有的解决方案当中没有找到让我满意的,但是在遇到问题时,冷静分析现有解决方案是很有必要的,理解前人的思路后才会对整个问题理解得更透彻,我的很多文章也都是以分析和解决思路为主,授人以鱼不如授人以渔,所以我不会直接告诉你答案,先分析一波,理清思路

这不,在分析民间大牛解决方案时,虽然最后发现这不是自己想要的解决方案,但是作为有发散思维的我,又是灵机一动,借助原有解决方案在上面这样一改不是就可行了?

如何改善原有方案？

上面的分析已经说了民间大牛解决方案 ,可以在 Interceptor 拦截器中设置一个全局的 Host(Host 可以理解为 BaseUrl) ,拦截器会强行将这个 Host 应用到所有的请求上,改变该请求原有的 Url,这样导致了只会同时存在一个 Host

所以我在想,将这个唯一的 Host 变量改为集合,以存储多个 Host ,在将不同的 Host 应用到不同的请求上,不就可以支持多 BaseUrl？

实践想法

说干就干,于是我自己建了一个全局的容器来存储多个 Host,这样我就可以在 App 运行时的任何时间,任何地点随意新增,修改,删除 Host

遇到问题

但是问题来了,我想要将不同的 Host 应用到不同的请求上,但我怎么知道什么请求需要什么样的 Host ,每个请求总要有个标记,让我知道他需要什么样的 Host 吧

于是我就在想 Retrofit 有什么方法,可以在请求之前给每个请求加上不同的字符串标记,于是我很自然的想到了 Header ,Retrofit 正好有 @Headers 这个注解,可以给每个接口方法上加入自定义 Header

再次解决难点

我给需要不同 BaseUrl 的接口方法上加入了自定义的 Header ,以标明每个接口需要的 Host 的 Name ,而这个 Name 对应的值就是 Host,但这个值不是在 @Headers 中被指定的,它是可以动态改变的

存储 Host 的容器是一个 Map, key 就是这个 Name ,value 才是 Host ,拦截器每次拦截到请求时,会判断这个请求是否有这个自定义 Header, 有的话,拿到这个 Header 中标注的 Name,然后用这个 Name ,去那个存储 Host 的全局 Map 中 get(name),拿到对应的 Host 再应用到请求上不是就达到支持多个 BaseUrl 了?

如果想动态改变某个 Host 也简单,将新的 Host 以同样的 Name put(name) 进这个全局 Map ,到时候拦截器,使用这个 Name get(name) 出来的值,就已经是改变后最新的 Host ,在将这个 Host 应用到请求上不是就达到动态改变 BaseUrl 了？

这不,两个需求同时满足!

优化方案

这个方案就两步,给需要不同 BaseUrl 的请求设置 Header (想用 Retrofit 默认 BaseUrl 的接口,或者使用 官方静态解决方案, 官方动态解决方案 就不需要设置),在通过全局容器来管理 BaseUrl

针对于那种只有一个 BaseUrl 但需要动态改变的项目,本框架提供了一个 GlobalDomain 来优化这个场景,不需要给接口加 Header ,只需要一步,向全局容器 put(GlobalDomain) 你想要改变的 BaseUrl 就可以了

比 官方动态解决方案 给每个接口传全路径作为参数,要简单的多, 官方动态解决方案 注定只适合那种只有一两个需要动态改变 BaseUrl 的接口

总结

以上提到的解决方案,已经优化并封装成了三方库并上传至 Jcenter,方便大家使用

本解决方案主要适合,需要同时具备多 BaseUrl 以及动态改变 BaseUrl 的项目,或者只有一个 BaseUrl ,但需要动态改变 BaseUrl 的项目

如果对于只需要多 BaseUrl 不需要动态改变 BaseUrl 的项目,其实用 官方静态解决方案 就已经足够了,但我还是推荐用我的这个解决方案,因为需求都是会变的,如果一旦要加入动态改变 BaseUrl 的需求,如需要动态切换生产环境和开发环境 ,那这时怎么办,一个个改掉每个接口注解里面的全路径?

Github : 具体使用看 Demo ,记得 Star !

公众号

扫码关注我的公众号 JessYan，一起学习进步，如果框架有更新，我也会在公众号上第一时间通知大家

Hello 我叫 JessYan，如果您喜欢我的文章，可以在以下平台关注我

个人主页: http://jessyan.me
GitHub: https://github.com/JessYanCoding
掘金: https://juejin.cn/user/976022014539326
简书: http://www.jianshu.com/u/1d0c0bc634db
微博: http://weibo.com/u/1786262517

-- The end