但是對于大型的App來說，僅僅是使用這些是不夠的，它太機械，不能幫我們處理復雜多變的網絡情況。

在我的上個公司，智能設備的網絡連接是老大難問題，有時候設備連不上Wifi的情況下，開發人員去跟進，到最后總會丟出一句：“設備就是Ping不通網絡啊” 以此把鍋甩在了網絡上。而這些客戶，家里同時存在多種同類型的設備，競品設備的連接卻毫無問題…

所以無論是哪一端，當用戶量變多時，網絡的性能優化都是不可忽視的點，雖然網絡確實有其獨特的不可控性和復雜性，但是每一端都可以盡自己所能去優化到一個較好的情況。

這個“較好的情況”有下面幾個標準：

• 避免重復的上傳、下載

• 富媒體、JS/CSS/HTML 都有壓縮

• 對于選擇壓縮算法，優化到最適合業務的情況

• 請求合并

• 網絡請求失敗的重試必須有明顯的結束條件

• 有連接建立兜底的能力

• …

[](()2. 關于網絡優化的主要問題

================================================================================

網絡性能優化，是性能優化專題中不可忽視卻又不可控的一點。

之所以不可控，是因為 網絡 和CPU、磁盤、內存這些本地資源相比，網絡是外部資源，它有自己獨特的性能瓶頸，程序員突破不了這些瓶頸，令人困擾。

為了盡可能優化網絡性能，總結出下面幾大問題，可以從這些問題入手，來進行優化：

• 業務成功率

• 業務網絡延時

• 業務寬帶成本

• 業務安全性

[](()2.1 業務成功率

---

下面有兩個場景是用戶真實可以遇到的：

當發消息的時候走進了電梯

在演唱會時分享朋友圈

上面兩個場景就體驗來說，是最有可能出現發送失敗的地方。

而正好，這兩個場景分別代表了兩種典型的網絡差的場景，進電梯代表了網絡信號差，而演唱會則代表了擁塞網絡，程序如果處理不當都會直接影響業務的成功率。

[](()2.1.1 弱信號 / 弱網

可以簡單的看成手機信號只有一格的時候，這時不僅僅是信令（無線網絡其實通信的時候都是一個個信令）發出去困難，而且還有可能導致不斷切換網絡、切換基站。App能做的，就是在應用層做重試，因為很大概率這個弱信號只是一時的。

[](()2.1.2 擁塞網絡

這個我們熟悉，當我們把網絡的消息傳輸看成是一個 生產消費者模型，就 《Android學習筆記總結+最新移動架構視頻+大廠安卓面試真題+項目實戰源碼講義》無償開源 徽信搜索公眾號【編程進階路】 是一端在不斷發消息，一端在處理消息，

擁塞網絡的本質就是： 生產者生產消息的速度大于消費者處理消息速度，這時候網絡狀態就過載了。

如果我們App不斷重試，只會導致擁塞更為嚴重。這個時候能做的就是讓自己的非核心業務不要搗亂，不要排隊，讓核心業務的數據量更少，協議來回更少。

[](()2.2 業務網絡延時

---

成功率直接代表了業務的成功和失敗。

而網絡延時相比起來沒那么直接，但是 慢 會帶來不爽，按我們公司的話來說，就是“等待時焦慮”，也是會流失用戶的。

這個慢，就必須從一個數據包的發送歷程開始說起，可以參考下圖：

[](()2.2.1 DNS解釋

域名換ip。這一步看似簡單卻充滿陷阱，10分鐘的DNS的Cache過期時間，200~2000ms不等的DNS耗時，坑了無數應用。

解決無非有三個策略：

• ip直連

• 域名重用

• HttpDNS（利用云服務器，通過自定義的協議獲取域名對應的IP地址，甚至是列表）

[](()2.2.2 建立連接

大多數應用都是基于TCP，所以就是三次握手建立TCP連接。這一步的耗時，如果是長連接的話就是一次消耗，但是短連接的話就是多次消耗（因為Http的無狀態性）。要維護的化就需要心跳包，心跳包多，會耗電，特別是當心跳間隔等于移動網絡狀態機Active-Idle切換間隔時，簡直就是悲劇。

同時對于移動網絡來說還會增加信令通道的負擔，著也是當年那個轟動一時的微信信令風暴的部分原因。（信令風暴：就是發送心跳包過多或者過快，超過了服務器的處理速度，最終會導致大量占用網絡資源、服務器不可用）。

而心跳包少了，會讓連接在NAT中超時，導致長連接斷開。在建立連接的過程中，TCP會進行一些商定，其中影響網絡時延最明顯的就是窗口。

[](()2.2.3 接受窗口

用于擁塞控制。

客戶端同一時間發送多少TCP數據包，當前的寬帶有沒有被充分利用，直接影響發送的速度。而讓窗口太少的原因無非有幾個：

服務器的Receive Buffer較小

因為慢啟動，而包又太小，剛剛連接，慢啟動會逐步放大窗口，沒有等放大完，數據就發完了

Window size scaling factor失效，這里最有可能的原因是網絡代理，失效的結果就窗口最大只有65536字節。

窗口本身就是Tcp擁塞控制的一部分，但有時App為了能自己控制，也是想盡了辦法。利用應用層分片大小可以做更嚴格的擁塞策略；多連接和長連接一定程度上可以繞過擁塞策略中的慢啟動。

在云時代，已經有各種各樣的提升業務成功率和網絡延時的優秀組件，比如 QQ的MSF，QZONE的WNS~

[](()2.3 業務寬帶成本

---

如果將流量列入到影響網絡的原因中，那么就必須要思考應用的業務寬帶成本了。

對于視頻、圖片這些富媒體業務，每天在寬帶成本上的投入，跟燒錢沒有什么區別。

如何在降低這些成本的同時，不會影響用戶體驗呢？策略有： 壓縮、增量、去重復三種。

[](()2.3.1 壓縮

• 圖片用WebP壓縮、PNG壓縮，還可以使用像 progressive jpeg的不同程度壓縮來替代大中小圖

• 視頻用H264、H265壓縮

• 文本是用gzip和其他ZIP壓縮

• 傳輸數據使用 json、 protobuf等。

除此之外還有一些細節，例如

圖片的尺寸在不同分辨率的上要下載不同的尺寸，設計時要注意

WebP圖片的編碼和解碼對于手機是有壓力的，CPU消耗是JPEG的3倍以上，編碼耗時也比JPEG長不少。所以不要在性能壓力大的時候使用，建議解碼后在本地保存成JPEG，以降低下次解碼的壓力。

對于文本，也有通過改變編碼方式來降低流量，UTF-8、UTF-16、GBK都有不同的編碼方式，雖然現在Unicode流行于編碼界，但是了解這些編碼的發展歷史、編碼算法，可以利于我們對優化流量有一定的幫助。

[](()2.3.2 增量

即增量更新。常見于列表上拉加載、下拉更新、左滑刪除。

所以這明顯是要看場景使用的，當你的RecyclerView懟滿了2000個item時，一次性加載那就是災難，而最多只有20個item時還做增量，就會導致我們的協議復雜度增加，得不償失。

[](()2.3.3 去重復

該問題很簡單，而且很常見，比如地圖SDK重復下載地圖塊、橫豎屏幕切換WebView的內容，重復下載，這些都比較常見。

而像 壓縮包里面的圖片和沒有壓縮的內容重復、CSS里面的內嵌圖片與壓縮包里的圖片重復這些問題則較為隱蔽，一般也沒有這個精力去查問題。

[](()2.4 業務安全性

---

怎樣防止被第三方竊聽/篡改或冒充，防止運營商劫持，同時又不影響性能？

總結

以上是生活随笔為你收集整理的Android 网络性能优化（1）概述的全部內容，希望文章能夠幫你解決所遇到的問題。

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