遊戲陪玩系統移動端網路優化思路，一起了解一下

一.分析遊戲陪玩系統網路請求流程及耗時

1. 網路請求的過程

 發起請求 》 域名解析 》tcp三次握手 》 tls握手 》request 》 response 》json解析 》 業務

2. 耗時統計

在瞭解了遊戲陪玩系統網路請求的流程之後，我們可以先測試一下網路請求耗時分佈,對於iOS來說，獲取耗時最簡單的方式就是監聽NSURLSession的didFinishCollectingMetrics回撥方法

- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didFinishCollectingMetrics:(NSURLSessionTaskMetrics *)metrics API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
{
    if (@available(iOS 10.0, *)) {
        for (NSURLSessionTaskTransactionMetrics *sessionMetric in metrics.transactionMetrics) {
            NSInteger dom = ([sessionMetric.domainLookupEndDate timeIntervalSince1970] - [sessionMetric.domainLookupStartDate timeIntervalSince1970]) * 1000 ;
            NSInteger sec = ([sessionMetric.secureConnectionEndDate timeIntervalSince1970] - [sessionMetric.secureConnectionStartDate timeIntervalSince1970]) * 1000;
            NSInteger con = ([sessionMetric.connectEndDate timeIntervalSince1970] - [sessionMetric.connectStartDate timeIntervalSince1970]) * 1000;
            NSInteger req = ([sessionMetric.requestEndDate timeIntervalSince1970] - [sessionMetric.requestStartDate timeIntervalSince1970]) * 1000;
            NSInteger res = ([sessionMetric.responseEndDate timeIntervalSince1970] - [sessionMetric.responseStartDate timeIntervalSince1970]) * 1000;
            NSInteger tot = ([sessionMetric.responseEndDate timeIntervalSince1970] - [sessionMetric.fetchStartDate timeIntervalSince1970]) * 1000;
            NSString *locip = @"";
            NSString *remip = @"";
            if (@available(iOS 13.0, *)) {
                locip = [NSString stringWithFormat:@"%@", sessionMetric.localAddress];
                remip = [NSString stringWithFormat:@"%@", sessionMetric.remoteAddress];
            }
            NSLog(@"metric path:%@ 總耗時:%ldms, 域名解析:%ldms, 連線耗時:%ldms(包括TLS:%ldms), 請求:%ldms, 回撥:%ldms l:%@ r:%@",sessionMetric.request.URL.lastPathComponent,tot,dom,con,sec,req,res, locip, remip);
        }
    }
}

獲取的資料類似下圖：

二.優化思路

1.域名解析耗時

我們常用的HTTP請求，底層基於TCP連線，需要有IP和埠資訊。由於IP是可變的，且不好記憶，所以有了域名這樣一個字串幫助人們進行記憶。字串到IP需要經過遊戲陪玩系統的DNS伺服器來進行獲取，這一過程使用的UDP方式，這一過程的快慢取決於網路質量以及域名對映關係存放的DNS伺服器跟你所在地跨越的層級。甚至有一些不可控的情況會導致域名解析出來一個錯誤的IP地址。
為了提高遊戲陪玩系統域名解析速度，以及減低域名汙染風險，我們可以使用HTTPDNS的方式來進行IP獲取。也可以設計一套IP直連方式獲取域名IP池機制，遊戲陪玩系統啟動後檢查更新DNS服務IP的更新，域名IP池的更新，以及對IP池中的IP進行測速，選擇網速較好的IP。在使用IP直連請求時，需要修改request的host，以及證照校驗的host。

2.連線耗時

建立連線需要的耗時較長，如果能夠利用長連線可以保持的特性，那麼這塊的耗時優化非常可觀。優化這塊需要遊戲陪玩系統後端支援，我們可以設計一個通道API，將多個域名的請求放在同一個連線中進行請求，這塊需要網路庫層和後端進行協議開發，遊戲陪玩系統業務端可以普遍享受到增益。當然，我們也要考慮在通道不可用時，及時採用常規請求方式的策略。以及HTTP1.1存在隊頭阻塞問題，需要在HTTP2.0上才能真正起到優化效果。

3.request及response(download)優化
request耗時一般是在遊戲陪玩系統服務端，如果遇到耗時較長的情況需要找一下服務端同學排查一下是否有耗時邏輯。response耗時較長一般是網速慢或者資料體積大導致的，體積大這個問題可以通過刪減冗餘資料，開啟gzip，資料分頁等方式進行優化。

4.json解析

json解析在資料量不大的情況下一般耗時不會太多，如果遇到資料量特別大的情況可能就需要考慮怎麼降低資料量，採用解析效率更高的庫，可以參考如下網圖。YYModel原理和MJExtension類似，都是基於runtime進行動態獲取屬性進行賦值。前者使用了CoreFoundation更底層的方法以及行內函數的應用所以效率上得到了大幅提高。

5.業務側優化

5.1 網路請求優先順序排布，通過對遊戲陪玩系統業務程式碼梳理，在啟動階段進行高優先順序介面請求，對可以合併的介面進行合併，落地點銷燬的請求及時取消請求。
5.2 升級HTTP2.0，利用其二進位制分幀，頭部壓縮，head block優化的特性，降低請求資料量，提高併發請求效率。

6.弱網優化

弱網環境是遊戲陪玩系統經常需要面對的問題，地鐵，人員密集區域，運動，都有可能導致網路請求不穩定，失敗等問題。HTTP1.1，2.0都是採用的TCP連線方式，而TCP需要三次握手，斷開後需要重新握手，這些會導致在弱網,運動環境持續請求失敗。QUIC協議是谷歌提出的基於UDP的資料傳輸協議，HTTP3.0就是採用的QUIC實現機制。使用HTTP3.0進行網路請求可以享受到如下這些進步，當然這得遊戲陪玩系統服務端和客戶端共同配合才能完成。

更好的連線建立方式
更好的擁塞控制
沒有隊頭阻塞的多路複用
前向糾錯
連線遷移

以上便是“如何實現遊戲陪玩系統移動端的網路優化？”的全部內容，希望對大家有幫助。

本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
原文連結：