1、 前言
移動網際網路發展到現在，使用者的聯網方式已經完成了由流量依賴到Wifi依賴的轉變。雖然網路環境在變好，但也對網路的應用提出了更高的要求，同時開發人員對網路的重視度卻在下降。確實Wifi場景下使用者的網路質量變好了，而且使用者對網路流量消耗的敏感度也在下降。但是對網路問題的忽視，在網路狀態不好的場景下，會表現的很明顯。
2、 網路問題
2.1 流量耗費
過多以及沒有經過處理的網路請求，會消耗使用者的網路流量。Android使用者一般都會安裝手機管理類App，可以方便清楚檢視到每個App耗費的流量，高流量消耗會導致經常處於非Wifi場景下的使用者解除安裝。
2.2 電量消耗
與第一條流量消耗類似，耗電也會導致使用者最終的解除安裝。
2.3 使用者體驗差
網路請求耗時會給使用者帶來卡頓的產品體驗，雖然可以使用Loading提升使用者體驗，但屬於治標不治本。例如最近我在使用某火爆單車App，每次網路請求都能超出我的耐心，於是我就轉投另一款單車App！
2.4 其它
- 應用Apk更新，Apk下載的快慢肯定會影響到應用更新流程的轉換率；
- 類如熱修復Patch包、Hybrid資源包等的下載，肯定是越早下載到本地越好；
3、 網路監控
3.1 Network Monitor
Android Studio自帶的Network Monitor簡單直觀，可以看出時間段之內的網路請求數量及訪問速率；
3.2 Charles、Fiddler等抓包工具
使用Charles、Fiddler等抓包工具同樣可以實現Network Monitor的功能，而且更加強大。
3.3 Stetho
Stetho是Facebook出品的一個Android應用的除錯工具。無需Root即可通過Chrome，在Chrome Developer Tools中視覺化檢視應用佈局，網路請求，sqlite，preference等。同樣整合了Stetho之後也可以很方便的檢視網路請求的各種情況。
4、 網路優化
網路優化主要從三個方面進行：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.9、1.0、1.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深度對比》。
儘量避免客戶端的輪詢，而使用伺服器推送的方式；
資料更新採用增量，而不是全量，僅將變化的資料返回，客戶端進行合併，減少流量消耗；
5、 其它
- 對於網路優化，實際上和記憶體優化一樣，是一項投入巨大的事情。提升網路的成功率尤為困難。因此建議優先進行流量優化，減少干擾項；
- 弱網不僅僅指代網路不好，移動網際網路的網路頻寬很容易出現“跳變”，下一秒的傳送速度可能降到前一秒的幾十分之一；而且即便是訊號滿格也傳不出一個位元組；
- 對於真正的弱網，可以使用抓包工具進行模擬，也有聰明的小夥伴使用wifi精靈進行限速；
- Facebook的開源專案augmented-traffic-control可以模擬不同的網路環境，針對頻寬、時延抖動、丟包率、錯包率、包重排序率等方面，堪稱弱網除錯神器；
- 針對網路請求對電量的損耗，本文暫時不提，在下一篇文章中細說。
參考：
- Android效能優化典範《Network Performance》
- 《移動App效能評測與優化》
- 《Protobuffer和json深度對比》
歡迎關注微信公眾號：定期分享Java、Android乾貨！