當我們開始關(guān)注 App 的用戶體驗后，網(wǎng)絡(luò)通暢性和界面的流暢性是保證 App 好用的重要指標。近期對項目中的網(wǎng)絡(luò)數(shù)據(jù)進行了簡單的分析，又對業(yè)界的一些方案做了調(diào)研，故寫此文做一下知識梳理。

在使用 App 時，如經(jīng)常遇到加載失敗或者小圈轉(zhuǎn)個不停的情況，那么很可能 App 的網(wǎng)絡(luò)性能出現(xiàn)了問題，急需研發(fā)同學來進行優(yōu)化。而對于開發(fā)人員來說，定位網(wǎng)絡(luò)問題又是十分艱難，因為出現(xiàn)網(wǎng)絡(luò)問題的用戶往往遙在天邊，你沒辦法進行調(diào)試定位。那么建立完善的網(wǎng)絡(luò)監(jiān)控體系就顯得十分重要，通過海量數(shù)據(jù)的分析來對網(wǎng)絡(luò)問題精確定位。

通過對數(shù)據(jù)的分析以及調(diào)研、用戶反饋，發(fā)現(xiàn)移動端網(wǎng)絡(luò)常常存在如下的問題：

• 網(wǎng)絡(luò)成功率低，經(jīng)常請求失??；
• 用戶反饋 DNS 劫持，數(shù)據(jù)被篡改，出現(xiàn)廣告和請求超時等情況；
• 網(wǎng)絡(luò)延遲較長，且存在較多的長尾數(shù)據(jù)；
• 經(jīng)過數(shù)據(jù)分析，發(fā)現(xiàn)長連的時間明顯比短連的時間少 100ms 左右（短連指的是，經(jīng)過DNS解析、TCP 握手、 SSL 握手等一系列的過程建立連接，長連指的是直接復用前者的連接通道）；
• 網(wǎng)絡(luò)經(jīng)常出現(xiàn)抖動，本來大部分請求都是 100ms 左右，突然冒出來一兩千毫秒的，甚至有10、20秒的延遲情況
• HTTP 1.1 的 head of blocking 情況存在，一個網(wǎng)絡(luò)抖動，很容易影響后續(xù)的請求，導致一連串的延遲較高請求（head of blocking：指的是在 HTTP 1.1 中，如果你發(fā)出1、2、3 三個網(wǎng)絡(luò)請求，那么 Response 的順序 2、3 要在第一個網(wǎng)絡(luò)請求之后）；
• 傳輸?shù)?Payload 太大，延遲高，易超時；
• 蘋果要求HTTPS ，此時加入的 SSL 握手較耗時。

針對上面一系列的問題，業(yè)界已經(jīng)有很多解決方案，我在這里簡單列舉一些。

面對這樣的網(wǎng)絡(luò)，如何解決？

對于 DNS 劫持的情況，業(yè)界的主要做法是 HTTPDNS 或者內(nèi)置 Server IP 列表?？蛻舳酥苯釉L問 HttpDNS 接口，獲取業(yè)務(wù)在域名配置管理系統(tǒng)上配置的訪問延遲最優(yōu)的IP，獲取到IP后就直接往此IP發(fā)送業(yè)務(wù)協(xié)議請求，不需要使用本地運營商解析域名，所以從根本避免了劫持問題，同時可以降低網(wǎng)絡(luò)延遲，提高連接成功率。而建立 Server IP 列表，是在本地緩存一個 IP 的映射表，此表可在App啟動時動態(tài)下發(fā)更新，訪問服務(wù)器時直接拿出 IP 發(fā)出請求。

傳輸?shù)?Payload 也直接影響了延遲，并且對成功率有影響，對于數(shù)據(jù)的壓縮，業(yè)界很多公司已經(jīng)開始使用 ProtoBuf 協(xié)議，對于優(yōu)化的百分比我還沒有準確的說數(shù)據(jù)結(jié)論，但是從大家的反饋來說，優(yōu)化效果明顯。對于數(shù)據(jù)的壓縮，還可以考慮接入 HTTP 2.0，畢竟這是一個趨勢，也有較多公司已經(jīng)加入 HTTP 2.0，HTTP 2.0 通過頭部壓縮等方式也幫你減小了傳輸?shù)?Payload。

上面的問題其實很多是涉及到長連與短連的問題，對這個問題有較多的問題可以考慮。

• 域名合并：淘寶、美團等公司公布的方案中都有提到，就是將公司原來很多域名的情況，合并為較少的幾個域名，為什么這么做呢？HTTP 的通道復用是基于域名劃分的，如果域名只有幾個，那么多數(shù)請求都可以在長連接通道進行，這樣就可以降低延遲、增加成功率；
• 盡早建立長連接，這樣其他的業(yè)務(wù)請求就可以復用長連接通道，加快訪問速度。對于建立連接的時機，可以考慮多個方面，比如冷啟動，前后臺切換、網(wǎng)絡(luò)切換等；
• 考慮接入 HTTP2.0，他們兩個都解決了 HTTP 1.1 的head of blocking，降低了網(wǎng)絡(luò)延遲，提供了更強大的多路復用技術(shù)，還加入了流量控制、新的二進制格式、Server Push、請求優(yōu)先級和依賴等特性?；蛘呓尤?SPDY ，但是目前覺得好像直接上 HTTP 2.0 比較合適；
• 建立多通道，比如攜程、美團等公司都有自己TCP、UDP通道，具有多域名共用通道，成功率三個九等誘人的功效。同時各大廠也對新的網(wǎng)絡(luò)協(xié)議，比如 QUIC，進行嘗試。Facebook還出一分享，對 QUIC 改進，實現(xiàn) TLS 的 0-RTT。

再者還有一些其他可以考慮的點：

• 加入 CDN 加速，動靜資源分離；
• 對于埋點的數(shù)據(jù)，也可以合并請求，減少流量；
• App 網(wǎng)絡(luò)診斷；
• 根據(jù)網(wǎng)絡(luò)情況，動態(tài)設(shè)置超時時間等。

網(wǎng)頁標題：移動APP網(wǎng)絡(luò)問題以及優(yōu)化方案
本文網(wǎng)址：http://m.rwnh.cn/news0/170950.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、品牌網(wǎng)站制作、企業(yè)建站、網(wǎng)站制作、建站公司、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)