深度優化 iOS 網絡???/div>

幾乎每一個講究的iOS項目都會有一個「網絡??欏?,大部分的網絡請求都是通過HTTP完成,使用成熟的第三方庫諸如AFNetworking很容易搭建一個功能簡易的網絡???。但這一??橐嘔萌疵荒敲醇虻?,是個曠日持久的工作,筆者根據自己多年的“填坑”經驗,總結一下深度優化iOS項目網絡??櫚姆椒矯婷?,也給自己做下知識梳理。

預熱

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

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

@interface PPRequestManager : NSObject
@end
@implementationPPRequestManager
@end
 
@interface PPRequest : NSObject
@end
@implementationPPRequest
@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住“優質”的請求。如果并發數太大,帶寬有限的場景下,會增加請求的整體延遲。

可靠性保障

可靠性保障也是個容易被忽視的方面,在深入探討之前,可以先將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 進行中),我們再看下發送請求的流程。

@implementationPPRequestManager
 
- (void)sendRequest:(PPRequest*)reqwithDelegate:(id)delegate
{
    if (req.reliability == PPRequestReliability_PersistentToDB) {
        PPRequestRecord* record = [reqserializeToRecord];
        //save record to database
    }
    
    //send request
}
 
- (void)onRequestSucceed:(PPRequest*)req
{
    //add to resend queue
    [_resendQueueaddObject:req];
    
    //remove from db
}
 
- (void)onRequestFail:(PPRequest*)req
{
    //add to resend queue
    [_resendQueueaddObject: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等等,這些場景在生活當中并不少見,健壯的網絡??樾枰邢傅募觳饌緄謀浠?,針對性的做請求重試。

請求成功率監控

網絡??橛Ω媚薌囁氐鼻癆pp的網絡請求成功率,對于失敗率較高的請求,帶上業務數據,手機網絡環境,系統參數等等,在用戶不活躍的時候能打包上報給server端,一則能找出更多需要優化的業務場景,二則能實時監控server端的健康狀態,三則能從數據層面精確判斷每一次網絡優化是否有成效。

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


上一篇: 今日頭條iOS客戶端啟動速度優化

下一篇: 想學iOS開發先來聽聽這些建議

分享到: 更多
幸运北京pc28预测大小 高频彩分析app 一肖一码中特吗 7m篮球即时比分直播 推二八杠顺口溜 重庆时时赢面大赌法 2019彩票赚钱计划 北京pk10定位胆技巧 助赢幸运飞艇资料计划软件 不倒翁投注法新法整理 时时彩开奖结果 pk10免费永久计划 3d打一个胆多少钱 欢乐斗地主二人官方版 重庆时时彩代理注册 极速赛车冠亚稳赚玩法