本文來自網易云社區

作者：王魯才

客戶端開發中不可避免的需要接觸到訪問網絡的需求，如何把訪問網絡模塊設計的更具有擴展性是每一個移動開發者不得不面對的事情。現在有很多主流的網絡請求處理框架，如Square公司的OkHttp，Google推出的Volley，還有在OkHttp基礎上進行封裝的Retrofit等，這些都是非常優秀的網絡處理框架。利用現有網絡處理框架，比從零開始設計、開發網絡請求節省很多開發時間，同時也避免了一些意想不到的問題。如果把這些框架直接拿來使用，不進行任何二次封裝，會使我們工程層次結構不清晰（數據存取、邏輯處理、UI展示），不利于擴展（替換成其他網絡框架）。所以選擇一個合適的網絡框架并進行封裝，這在開發過程中是非常必要的。

1. 概述

通常情況下，客戶端數據流遵循如下圖所述方式流動，UI層負責展示數據，接收用戶操作；邏輯處理層處理用戶操作，并將處理結果反饋給UI層進行展示；數據層負責數據存取，這里可能會涉及多種方式存取數據：本地緩存中存取數據，向服務器請求存取數據；網絡訪問層負責從服務器存取數據，數據返回后進行解析，并將結果返回給數據存取層。

2. 考拉Android客戶端網絡模塊設計

下面簡要介紹一下考拉Android客戶端網絡模塊設計的變遷歷程，在這個過程中我們也踩了不少坑，好在我們把這些坑都填平了，而且正在朝著更好的方向發展。

在考拉項目開始之初，我們對比了Volley、OKHttp等主流網絡處理框架，最終選擇了Volley作為考拉Android客戶端的網絡請求模塊。Volley是在2013年IO大會上Google推出的異步網絡請求框架（和圖片加載框架），特別適合數據量小，通信頻繁的網絡操作。

2.1 存在的問題

1. 封裝擴展性差（SPDY，HTTPS）；

2. 存在內存泄漏（Volley自己的問題）；

3. 數據解析在UI線程中進行，阻塞UI展示；

在這一版本的網絡請求封裝中存在一個比較嚴重的問題，數據解析在UI線程中進行，在最初的幾個版本中，請求的數據量較小，UI比較簡單，阻塞UI線程的這個問題還不是特別明顯，但是隨著UI越來越復雜，同時請求數據、解析數據的操作也越來越多，阻塞UI線程解析數據，存在丟幀問題。為了解決這個問題，引入了工作線程池，網絡請求回來以后，先將數據返回給調用者（UI線程），調用者在解析數據的時候，開啟工作線程，數據解析完成后再拋回UI線程，UI線程進行數據展示。在這個過程中，有多次線程切換，線程創建、切換、調度都是需要內存、時間開銷的。更要命的是，這個過程對調用者不透明，調用者必須知道當前操作是在哪個線程中進行的。

擴展性差這一點相信很多開發者都有比較痛的感悟。為了兼容不同服務器返回的不同數據格式，在網絡請求模塊中定義了很多不同參數的回調方法。在請求數據時，每一種回調接口都要對應一個具體的方法（傳入的回調接口不同），代碼寫的比較冗余，條理性、擴展性差，簡直要不能直視了。

2.2 重構

為了解決上面兩個問題，對網絡請求模塊進行了重構，引入了泛型數據，重新定義了網絡數據返回結構，新增了數據解析器。根據用戶傳入的不同解析器，將網絡返回數據解析成不同類型。在網絡數據返回后，直接將數據解析操作從UI線程中拋到工作線程中，這個過程對調用者是透明的。調用者只需要知道網絡請求操作和數據解析操作是在工作線程中進行的，回調接口在UI線程中執行就可以。

在這個網絡響應回調接口中，采用了泛型，調用者可以返回任意數據結構，為了提高兼容性，在錯誤回調方法中，不僅傳入了錯誤碼和錯誤原因，而且還額外增加了一個Object類型的數據，供調用者返回其他數據信息。

KoalaStringParser是通用數據解析接口，主要針對有特殊需求的數據解析；對于通用的、與服務器約定好的數據返回格式，可以繼承KoalaSimpleStringParser抽象類，實現onSimpleParse抽象方法解析數據。通用數據解析接口和抽象數據解析類，既保證了擴展性，又對通用數據格式有了統一處理。

2.3 數據緩存

如果不考慮數據緩存的話，上面對網絡請求的封裝基本也能滿足我們的要求了。但是如果沒有數據緩存，每次都向服務器請求數據，啟動新頁面，會有時間長短不一的加載過程，沒有網絡或者網絡不好時，會顯示一個空白頁面告訴用戶網絡不可用，這降低了用戶體驗。為了提升用戶體驗，減少啟動頁面的等待時間，增加數據緩存是一件很有必要的事情。緩存可以與服務器配合，使用HTTP的緩存機制，也可以在客戶端單獨使用。因為現在考拉服務器還沒有支持緩存，現階段只能在客戶端添加緩存。

上面是在沒有服務器支持的情況下，客戶端支持的緩存。在啟動頁面請求數據時，先判斷是否允許讀取緩存數據。允許讀取緩存數據，檢查是否存在緩存數據，存在緩存數據，將數據從本地緩存中讀取后直接返回給調用者；不存在緩存數據，不做任何處理。在檢查緩存數據時，同時向服務器發送請求，獲取數據，數據返回后更新緩存數據。這里需要注意的是，回調接口可能會被調用兩次，一次是從緩存讀取數據的回調，一次是從服務器讀取數據的回調。出現兩次回調的問題，需要調用者進行區分，在回調方法中添加了當前回調是從本地讀取數據的回調還是從網絡讀取數據的回調標示。

服務端不支持緩存，只在客戶端對數據進行緩存處理，在一定程度上提升了用戶體驗，避免用戶多次請求相同頁面時出現多次重復加載、長時間等待的問題。這種緩存方式并不能節省用戶流量。

2.4 切換到OkHttp

前一段時間項目組提到考拉可能會引入SPDY來優化性能，后面為了解決劫持問題，還可能會上HTTPS，考慮到OkHttp已經內置了對SPDY的支持，而且對HTTPS的封裝比較好，未雨綢繆，我們決定從Volley轉投OkHttp了，因為之前已經對網絡請求進行了封裝，所以切換到OkHttp還是比較容易的。

OkHttp具有如下優點：

1. 支持SPDY，共享同一個Socket來處理同一個服務器的所有請求；

2. 如果SPDY不可用，則通過連接池來減少請求延時；

3. 無縫的支持GZIP來減少數據流量；

4. 緩存網絡數據，減少重復網絡請求；

5. 支持HTTP2；

使用OkHttp既可以在工作線程中請求數據，也可以在UI線程中請求數據，這與Volley只能在工作線程中請求數據不同。在工作線程中請求數據，數據返回后不需要重新開啟線程解析數據，數據在請求線程中解析完后，直接拋到UI線程中進行展示。

3. 總結

在設計開發功能模塊時，往往為了快速完成功能，忽略了模塊的擴展性，當后續功能越來越復雜時，之前設計的功能、接口已經不能滿足需求時，就要重新審視模塊是否需要重構、優化，不能總在舊的代碼上打補丁，造成代碼難以閱讀、維護。

4. SPDY簡介

SPDY是Google開發的基于傳輸控制協議（TCP）的應用層協議，用以最小化網絡延遲，提升網絡速度，優化用戶的網絡使用體驗。SPDY并不是一種用于替代HTTP的協議，而是對HTTP協議的增強。新協議的功能包括數據流的多路復用、請求優先級以及HTTP報頭壓縮。SPDY協議在性能方面對HTTP做了很大的優化，語義方面并沒有做太大的修改。具體來說是，SPDY使用了HTTP的方法和頁眉，但是刪除了一些報頭并重寫了HTTP中管理連接和數據轉移格式的部分，基本上兼容HTTP。

網易云免費體驗館，0成本體驗20+款云產品！

更多網易研發、產品、運營經驗分享請訪問網易云社區。

相關文章：
【推薦】 知物由學|你的網絡安全問題背后的真正原因
【推薦】 非對稱加密與證書（上篇）

總結

以上是生活随笔為你收集整理的网易考拉Android客户端网络模块设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。