解決 Retrofit 多 BaseUrl 及執行時動態改變 BaseUrl ?

JessYan發表於2019-03-01

原文地址: https://juejin.im/post/5978567d51882517921cdcfd

前言

Hello,我是 JessYan,作為一個喜歡探索新穎解決方案的我,在 上篇文章 中,向大家介紹了怎樣通過一行程式碼即可實現上傳下載以及 Glide 進度監聽,現在又給大家帶來了另一項大家都很期待的問題的解決方案,這個問題起源於 MVPArms 的一個 Issues ,當然使用 Retrofit 時,多個 BaseUrl 以及動態切換 BaseUrl 這兩個需求,在其他地方也經常被討論,那麼下面就來講講我的思路和解決方案

Github : 你的 Star 是我堅持的動力 ✊

gif

需求出現的場景

也許在日常開發中有些人已經遇到了這兩個需求的場景,但為了讓一些之前沒遇到這些場景的朋友,也能看懂這篇文章,所以先在前面提一提

多個 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，一起學習進步，如果框架有更新，我也會在公眾號上第一時間通知大家

解決 Retrofit 多 BaseUrl 及執行時動態改變 BaseUrl ?

Hello 我叫 JessYan，如果您喜歡我的文章，可以在以下平臺關注我

-- The end

相關文章