項目網絡層重構總結

1. 引入網絡抽象層，主要包括以下部分:

   • Request: 通用的Request的實現結構，承載如下職責:
     
     1. 網絡請求信息的承載和封裝。
     2. 爲Interceptor提供切面回調。
     3. 爲第三方庫的Request**具體實現提供橋接接口。**
   • Sender: 對網絡請求發送的抽象，爲第三方庫的發送請求(以及一些請求控制方法)提供實現接口。
   • Interceptor: AOP，對Request的各項回調進行intercept，可以支持動態掛接，網絡層的附加機制的實現將主要集中在這裏或者以這裏爲回調事件的分發點。

2. 通用Request可以實現和第三方網絡庫Request具體實現細節的解耦，並且當前很多作用於第三方網絡請求的代碼(如果認證加密)將被遷移爲針對通用Request的實現，通用Request將作爲項目代碼中網絡請求的唯一表現形式，第三方庫的具體請求將被隔離到最底層，只在Sender的具體實現中可見。通用Request會成爲架構中的一個對外網關協議，所有的網絡請求均以通用Request的形式發出，最後由Sender的具體實現翻譯/適配爲對應的請求實現。

3. 通用Request採用注入式的方式來和第三方具體實現進行協作，其本身只提供信息查詢接口和回調接口，並且不會維持對第三方具體實現的引用，反過來由第三方具體實現以擴展適配的方式來回調通用Request，第三方具體實現將會維護一個到通用Request的單向引用。

4. 通用Request本身不包含太多的邏輯處理細節，像認證加密等屬於網絡層附加機制的實現會放在Interceptor中。Interceptor可以支持動態插拔，Request回調Interceptor時會將自身傳入，儘量爲Request爲基本通信單位。目前的一個問題是一些附加機制需要在幾處回調都做部署，比較零碎。

5. 全局的網絡請求狀態將可以檢測，一個通用Request在被髮送後會保存在內部的RequestManager中，其生命週期持續到該Request結束爲止。附加機制的網絡請求隊列(如加密認證的重發隊列)會獨立於RequestManager，不同的隊列沒有直接的耦合關係。各自根據所需進行隊列的維護和修改。

6. 通用Request包含了兩種類型的信息:

   • 靜態信息: 如原始url, method, timeout等，這部分信息在Request被重發時並不會被改變(除非是特殊的需求)。
   • 動態信息: 如requestId， 真正的url(有這個是因爲一部分加密信息會附加在原始url上， 具有實時性)等，這部分信息在Request重發時應該重新生成，這樣才能區分出是一次新的Request(Request重發從網絡層的角度上講，應該是一個全新的Request，不過業務層不應該這樣的細節)。

   可以考慮動態和靜態信息進行類級別的分離。

7. 引入了ControlInfo，在發送請求時可以選擇性的代入，目前包括:

   • ViewId/ViewType: 該View對應的不是Android原生View，而是一個View抽象，因爲很多網絡請求的回調需要和界面發生互動（如請求成功後彈出提示對話框），而Android的特性決定了大多數互動都要有一個錨點(比如Activity), 這裏的View代表就是該錨點View，ViewId即請求發出時所在的界面的Id(Id本身是我們採用的另外一套View機制爲每個Activity/Fragemnt分配和維護的), ViewType則表示View的具體類型(不一定是actiivty/fragment,.可以從業務上面進行分類比如詳情頁/主頁)。
   • SessionId: 有這樣的應用場景，複數個連環網絡請求對應的是一次業務過程(比如先發一個查詢請求，成功的話再發一個領取請求，領取完再發一個登錄請求)，對於這一次業務過程中的網路請求，可以看做是同一個session中的網絡請求，通過sessionId來進行標記。
   • 一些控制信息，在上面介紹的Interceptor中會被用到。

8. 通用Request中的NetworkCallback是業務層能感知到網絡層的唯一途徑，可以通過攔截Callback的某些回調方法來屏蔽一些業務層不應該/不需要知道的網絡層細節。