解决Retrofit多BaseUrl及运行时动态改变BaseUrl(二)

原文地址: https://www.jianshu.com/p/35a8959c2f86

前言

我在之前的文章 《解决Retrofit多BaseUrl及运行时动态改变BaseUrl》 中，介绍了市面上能够解决此类问题的 4 个常见的解决方案，并开源了自己经过优化后的解决方案 RetrofitUrlManager，现在再为大家带来此系列的第二篇文章，这篇文章主要介绍 RetrofitUrlManager 针对 BaseUrl 替换逻辑的重大升级，因为这个升级对于 RetrofitUrlManager 足够重要，将使 RetrofitUrlManager 能够从容应对更多复杂的需求，所以单独写一篇文章让更多的人能够知道

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

为什么不使用多 Retrofit 实例的方案?

在上篇文章 《解决Retrofit多BaseUrl及运行时动态改变BaseUrl》 中，4 种方案的特点和不足我都描述的很清楚，建议没看过这篇文章的可以去看看这篇文章，扩宽知识面，在后面的时间里经常有人问我为什么不使用多 Retrofit 实例的方案，多个 Retrofit 实例看起来并不会占用多少资源啊?

在回答之前为了让看这篇文章的人能了解我在说什么，所以我再粘贴下 上篇文章 中关于这个方案的部分描述

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


我在这篇文章中重新回答下这个问题，为每个不同的 BaseUrl 都创建一个其他配置属性都一模一样的 Retrofit 实例不止会造成资源的浪费，还会造成接口管理成本的增加，这个才是最重要的一点, 举个例

我们平时项目中所有的 ApiService 都是使用同一个 Retrofit 实例的 Retrofit#create(ApiService) 方法进行实例化后开始接口的请求

但是当项目中出现多个 Retrofit 实例后，我们在开发中不光要区分哪些接口使用哪个 ApiService，还要区分哪些 ApiService 需要使用哪个 Retrofit 实例进行实例化，如果 ApiService 使用错误的 Retrofit 实例进行实例化，那这个 ApiService 的所有接口请求都注定完全失败

越复杂的项目，开发人数越多的项目，出错的风险就越大，并且扩展性也在大打折扣，后面一有变更将会十分痛苦，随着项目中接口的增加，以及 Retrofit 实例的增加 (BaseUrl 的增加)，这个管理成本会成几何倍的增加

使用多 Retrofit 实例的方案前期投入成本过高，可能会影响之前项目管理接口的方式，某些封装过 Retrofit 的项目，也可能需要大改，对于老项目的接入不利，而使用 RetrofitUrlManager 不仅