幾乎每一個講究的iOS項目都會有一個「網絡模塊」，大部分的網絡請求都是通過HTTP完成，使用成熟的第三方庫諸如AFNetworking很容易搭建一個功能簡易的網絡模塊。但這一模塊要優化好卻沒那麼簡單，是個曠日持久的工作，筆者根據自己多年的“填坑”經驗，總結一下深度優化iOS項目網絡模塊的方方面面，也給自己做下知識梳理。

預熱

網絡模塊的接口設計不在本文討論之列，設計思路有些偏個人口味，我只探討一些可以深度優化的硬性指標。在開始討論優化之前，需要讀者對網絡方面的理論基礎知識有一定的掌握。讀過TCP/IP協議詳解，RFC文檔就更佳。優化的東西對知識的深度和廣度都有相當的要求，各項目場景不一樣，依葫蘆畫瓢很可能會導致更多的問題，“優化”是個危險活。

關於HTTP推薦大家先閱讀下我之前的一篇總結性文章，涉及到的知識細節比較多，一一疏通之後再繼續下面的閱讀。

在開始優化之前，我們先建立樣例代碼，這樣討論起來才能有的放矢。假設我們定義這樣兩個請求類：

@interface PPRequestManager : NSObject

@end

@implementation PPRequestManager

@end
@interface PPRequest : NSObject

@end

@implementation PPRequest

@end

一個Manager負責管理Request，一個Request基類處理公共邏輯。

優化清單

DNS映射

無論是HTTP還是Socket長連接，第一步都是DNS解析。域名根據層級「主機名.次級域名.頂級域名.根域名」去解析，每一級緩存生命周期不同。在iOS設備上幾乎每次斷網重連，重啟設備都會使DNS緩存失效，觸發重新查詢。這一步的優化對請求的延遲來說至關重要，具體優化手段可參考我之前一篇關於DNS映射的文章，配有可用的demo代碼，這裡就不復述了。

請求壓縮

DNS查詢之後是TCP握手建立連接，並發送請求數據。對於TCP來說，單個IP包大小受限於MSS值，大部分用戶所處網絡環境下每個包的大小約在1.5KB，新建立的HTTP連接由於TCP的slow start特性，會導致本地的部分IP包本臨時緩存，從而增加了整體request的延遲。所以我們應該盡可能嘗試去壓縮我們的網絡請求業務數據，減少一個Request的IP包數量，或許可以讓用戶少經歷一個RTT，降低請求延遲的用戶感知。

請求合並

對於非關鍵性的業務數據，或者對實時性要求不高的請求來說，通過合並請求的方式可以減少和服務器交互的次數，一則降低服務器壓力，二則合並之後再壓縮能節約客戶端的流量。這類請求一般見於打點SDK，crash日志收集等非業務型請求。

請求的安全性

請求的網絡安全是個容易被忽視的話題，關於安全我之前也寫過一篇比較詳細的文章，建議細讀再配合使用HTTPS來做到基本的網絡安全，這裡也不再細述了。

合理的並發數

有些業務場景會出現多個Request集中產生的情況，此時我們需要設置一個合理的並發數。並發數如果太小，會導致“劣質”的請求block住“優質”的請求。如果並發數太大，帶寬有限的場景下，會增加請求的整體延遲，請求數量對於HTTP的影響我在之前的文章中也詳細的介紹過了。

可靠性保障

可靠性保障也是個容易被忽視的方面，在深入探討之前，可以先將Request按業務屬性分類。

• 第一類：關鍵核心的業務數據，期望能100%送達服務器。

• 第二類：重要內容請求，需要較高的請求成功率。

• 第三類：一般性內容請求，對成功率無要求。

之所以要將請求分為三類，是要在可靠性保障上做區分。理論上我們應該盡可能讓所有的請求成功率達到最高，但客戶端的流量，帶寬，手機電量，服務器的壓力等都是有限的資源，所以我們采取的策略是只對關鍵性的網絡請求做高強度的可靠性保障。

第一類請求類似大家用微信時發送的消息，消息數據一旦從輸入框發出，從用戶來的角度感知這個消息數據是一定會到達對方的。如果網絡環境差，網絡模塊會自動在後頭悄悄重試，一段時間後仍無法成功就通過產品交互的方式告知用戶發送失敗了，即使失敗，請求的數據（消息本身）一直存在客戶端。

對於這類請求的處理方式第一步不是通過網絡發送，而是持久化到Database當中。一旦入了DB，即使斷網，斷電，重啟，請求數據依然還在，只需在App重啟的時候還原請求數據，再次發送即可。我們用代碼來進一步闡釋。

//定義請求可靠性類型
typedef enum : NSUInteger {
    PPRequestReliability_PersistentToDB,
    PPRequestReliability_Retry,
    PPRequestReliability_Normal,
} PPRequestReliability;

//增加持久化接口
@interface PPRequest : NSObject

@property (nonatomic, assign) PPRequestReliability    reliability;

@property (nonatomic, strong) NSNumber*               rowID;

@property (nonatomic, strong) NSNumber*               reliabilityStatus;

- (PPRequestRecord*)serializeToRecord;

- (PPRequest*)deserializeFromRecord:(PPRequestRecord*)record;

@end

第一類請求是PPRequestReliability_PersistentToDB，新增了rowID用作存儲DB時的唯一標識，reliabilityStatus表示請求的當前狀態（成功 or 失敗 or 取消 or 進行中），我們再看下發送請求的流程。

@implementation PPRequestManager

- (void)sendRequest:(PPRequest*)req withDelegate:(id)delegate
{
    if (req.reliability == PPRequestReliability_PersistentToDB) {
    
        PPRequestRecord* record = [req serializeToRecord];
        
        //save record to database
    }
    
    //send request
}

- (void)onRequestSucceed:(PPRequest*)req
{
    //add to resend queue
    
    [_resendQueue addObject:req];
    
    //remove from db
}

- (void)onRequestFail:(PPRequest*)req
{
    //add to resend queue
    
    [_resendQueue addObject:req];
}
@end

如果判斷為第一類請求，第一步我們先將請求持久化到DB當中。

第二步發送請求，如果請求失敗則將請求加入重試隊列，成功則從重試隊列中移除。重試隊列背後也需要一套通用機制，比如多久重試一次，重試幾次之後放棄。

遇到最惡劣的場景，請求發送失敗之後，App被kill。我們需要在App重啟之後從DB當中重新load所有失敗的請求再次重試。

- (void)resendPreviousFailedRequest
{
    //load from db
    //send requests
}

通過上述幾步基本上可以使請求的可靠性得到極大的保障。但100%是無法實現的理想，失敗的時候用戶重裝App，所有持久化的數據丟失，請求數據也就丟了，不過這種極端的場景非常少。

第二類請求的可靠性為PPRequestReliability_Retry，這類請求的例子可以是我們App啟動時用戶看到的首頁，首頁的內容從服務器獲取，如果第一次請求就失敗體驗較差，這種場景下我們應該允許請求有機會多試幾次，增加一個retryCount即可。

//PPRequest.h
@property (nonatomic, assign) int                     retryCount;

一般3次的重試基本可以排除網絡抖動的情況。三次失敗之後即可認為請求失敗，通過產品交互告知用戶。

第三類請求的重要性最低，比如進入Controller的UV采集打點。這類請求只需要做一次，即使失敗也不會對產品體驗產生什麼負面影響。

多通道

現在不少有技術條件的團隊都有自己的tcp長連接通道，技術再硬點的甚至配有UDP通道，UDP在丟包率高的網絡環境下能極大的提高請求成功的概率。如果能同時具備HTTP，TCP，UDP三條網絡通道，在某些場景下，如果不考慮流量（比如wifi），可以針對某個網絡請求，兩通道或者三通道齊發，對請求成功的速度和可靠性有明顯的療效，不過客戶端和服務器都需要針對業務場景做去重。我工作過的一個IM App在發送消息的時候，就是Socket配合HTTP雙通道工作。UDP在VOIP服務當中使用較多，不過據說淘寶這類大廠也部分啟用了UDP。

網絡環境監控

現在網絡環境雖然越來越好，Wifi，4G，3G在一二線城市都有很好的普及，但還是有不少場景會導致網絡狀態突然變差，比如進電梯，做火車，人多的集會場所，從公司回家4G切Wifi等等，這些場景在生活當中並不少見，健壯的網絡模塊需要仔細的檢測網絡的變化，針對性的做請求重試。

請求成功率監控

網絡模塊應該能監控當前App的網絡請求成功率，對於失敗率較高的請求，帶上業務數據，手機網絡環境，系統參數等等，在用戶不活躍的時候能打包上報給server端，一則能找出更多需要優化的業務場景，二則能實時監控server端的健康狀態，三則能從數據層面精確判斷每一次網絡優化是否有成效。

以上是做項目當中容易遇到的優化點，有些方面只是提到，要實際操作深入優化還有很多可以細說，後續如果想到更多再補充。