Android 性能優化（八）之網絡優化

一、 前言

移動互聯網發展到如今，用戶的聯網方式已經完成了由流量依賴到Wifi依賴的轉變。雖然網絡環境在變好，但也對網絡的應用提出了更高的要求，同時開發人員對網絡的重視度卻在降低。確實Wifi場景下用戶的網絡質量變好了，並且用戶對網絡流量消耗的敏感度也在降低。可是對網絡問題的忽視，在網絡狀態很差的場景下，會表現的很明顯。

二、 網絡問題

2.1 流量耗費

過多以及沒有通過處理的網絡請求，會消耗用戶的網絡流量。Android用戶通常都會安裝手機管理類App，能夠方便清楚查看到每一個App耗費的流量，高流量消耗會致使常常處於非Wifi場景下的用戶卸載。

2.2 電量消耗

與第一條流量消耗相似，耗電也會致使用戶最終的卸載。

2.3 用戶體驗差

網絡請求耗時會給用戶帶來卡頓的產品體驗，雖然可使用Loading提高用戶體驗，但屬於治標不治本。例如最近我在使用某火爆單車App，每次網絡請求都能超出個人耐心，因而我就轉投另外一款單車App！

2.4 其它

• 應用Apk更新，Apk下載的快慢確定會影響到應用更新流程的轉換率；
• 類如熱修復Patch包、Hybrid資源包等的下載，確定是越早下載到本地越好；

三、 網絡監控

3.1 Network Monitor

Android Studio自帶的Network Monitor簡單直觀，能夠看出時間段以內的網絡請求數量及訪問速率；

Network Monitor指南

3.2 Charles、Fiddler等抓包工具

使用Charles、Fiddler等抓包工具一樣能夠實現Network Monitor的功能，並且更增強大。

Charles使用

3.3 Stetho

Stetho是Facebook出品的一個Android應用的調試工具。無需Root便可經過Chrome，在Chrome Developer Tools中可視化查看應用佈局，網絡請求，sqlite，preference等。一樣集成了Stetho以後也能夠很方便的查看網絡請求的各類狀況。

Stetho查看網絡請求

四、 網絡優化

網絡優化主要從三個方面進行：1. 速度；2. 成功率；3. 流量。

4.1 Gzip壓縮

HTTP協議上的Gzip編碼是一種用來改進WEB應用程序性能的技術，用來減小傳輸數據量大小，減小傳輸數據量大小有兩個明顯的好處：

• 能夠減小流量消耗；
• 能夠減小傳輸的時間。

4.2 IP直連與HttpDns；

DNS解析的失敗率佔聯網失敗中很大一種，並且首次域名解析通常須要幾百毫秒。針對此，咱們能夠不用域名，才用IP直連省去 DNS 解析過程，節省這部分時間。

另外熟悉阿里雲的小夥伴確定知道HttpDns：HttpDNS基於Http協議的域名解析，替代了基於DNS協議向運營商Local DNS發起解析請求的傳統方式，能夠避免Local DNS形成的域名劫持和跨網訪問問題，解決域名解析異常帶來的困擾。

4.3 圖片處理

4.3.1 圖片下載

• 使用WebP格式；一樣的照片，採用WebP格式可大幅節省流量，相對於JPG格式的圖片，流量能節省將近 25% 到 35 %；相對於 PNG 格式的圖片，流量能夠節省將近80%。最重要的是使用WebP以後圖片質量也沒有改變。
• 使用縮略圖；App中須要加載的圖片按需加載，列表中的圖片根據須要的尺寸加載合適的縮略圖便可，只有用戶查看大圖的時候纔去加載原圖。不只節省流量，同時也能節省內存！以前使用某公司的圖片存儲服務在原圖連接以後拼接寬高參數，根據參數的不一樣返回相應的圖片。

4.3.2 圖片上傳

圖片（文件）的上傳失敗率比較高，不只僅由於大文件，同時帶寬、時延、穩定性等因素在此場景下的影響也更加明顯；

• 避免整文件傳輸，採用分片傳輸；
• 根據網絡類型以及傳輸過程當中的變化動態的修改分片大小；
• 每一個分片失敗重傳的機會。

備註：圖片上傳是一項看似簡單、共性不少但實際上覆雜、須要細分的工做。移動互聯網的場景和有線的場景是有不少區別的，例如移動網絡的質量/帶寬常常會發生「跳變」，但有線網絡倒是「漸變」。

圖片上傳其它細節請參見《移動App性能評測與優化》一書。

4.4 協議層的優化

使用最新的協議，Http協議有多個版本：0.九、1.0、1.一、2等。新版本的協議通過再次的優化，例如：

• Http1.1版本引入了「持久鏈接」，多個請求被複用，無需重建TCP鏈接，而TCP鏈接在移動互聯網的場景下成本很高，節省了時間與資源；
• Http2引入了「多工」、頭信息壓縮、服務器推送等特性。

新的版本不只能夠節省資源，一樣能夠減小流量；我對Http2並無實際接入經驗，此處僅從原理進行分析。

4.5 請求打包

合併網絡請求，減小請求次數。對於一些接口類如統計，無需實時上報，將統計信息保存在本地，而後根據策略統一上傳。這樣頭信息僅需上傳一次，減小了流量也節省了資源。

4.6 網絡緩存

對服務端返回數據進行緩存，設定有效時間，有效時間以內不走網絡請求，減小流量消耗。對網絡的緩存能夠參見HttpResponseCache。

備註：咱們也能夠自定義緩存的實現，一些網絡庫例如：Volley、Okhttp等都有好的實踐供參考。

4.7 網絡狀態

根據網絡狀態對網絡請求進行區別對待，2G與Wifi狀態下網絡質量確定是不同的，那對應的網絡策略也應該是不同的。例如：在Wifi場景下能夠進行數據的預取、一些統計的集中上傳等；而在2G場景下此類操做以及網絡請求的次數策略都應該調低。網絡狀態能夠由TelephonyManager.getNetworkType()方法獲取到。

備註：還可使用Facebook的開源庫network-connection-class來作網絡狀態的判斷。

4.8 其它

• 斷點續傳，文件、圖片等的下載，採用斷點續傳，不浪費用戶以前消耗過的流量；

• 重試策略，一次網絡請求的失敗，須要屢次的重試來判定最終的失敗，能夠參考Volley的重試機制實現。

• Protocol Buffer
  Protocol Buffer是Google的一種數據交換的格式，它獨立於語言，獨立於平臺。相較於目前經常使用的Json，數據量更小，意味着傳輸速度也更快。

  具體的對比能夠參見：《Protobuffer和json深度對比》。

• 儘可能避免客戶端的輪詢，而使用服務器推送的方式；

• 數據更新採用增量，而不是全量，僅將變化的數據返回，客戶端進行合併，減小流量消耗；

五、 其它

• 對於網絡優化，實際上和內存優化同樣，是一項投入巨大的事情。提高網絡的成功率尤其困難。所以建議優先進行流量優化，減小干擾項；
• 弱網不只僅指代網絡很差，移動互聯網的網絡帶寬很容易出現「跳變」，下一秒的傳送速度可能降到前一秒的幾十分之一；並且即使是信號滿格也傳不出一個字節；
• 對於真正的弱網，可使用抓包工具進行模擬，也有聰明的小夥伴使用wifi精靈進行限速；
• Facebook的開源項目augmented-traffic-control能夠模擬不一樣的網絡環境，針對帶寬、時延抖動、丟包率、錯包率、包重排序率等方面，堪稱弱網調試神器；
• 針對網絡請求對電量的損耗，本文暫時不提，在下一篇文章中細說。

參考：

• Android性能優化典範《Network Performance》
• 《移動App性能評測與優化》
• 《Protobuffer和json深度對比》

歡迎關注微信公衆號：按期分享Java、Android乾貨！

歡迎關注