一. 網路監控 1 Network MonitorAndroid Studio自帶的Network Monitor簡單直觀，可以看出時間段之內的網路請求數量及訪問速率； 2 Charles、Fiddler等抓包工具使用Charles、Fiddler等抓包工具同樣可以實現Network Monitor ...
一. 網路監控
1 Network Monitor
Android Studio自帶的Network Monitor簡單直觀，可以看出時間段之內的網路請求數量及訪問速率；
2 Charles、Fiddler等抓包工具
使用Charles、Fiddler等抓包工具同樣可以實現Network Monitor的功能，而且更加強大。
Stetho是Facebook出品的一個Android應用的調試工具。無需Root即可通過Chrome，在Chrome Developer Tools中可視化查看應用佈局，網路請求，sqlite，preference等。同樣集成了Stetho之後也可以很方便的查看網路請求的各種情況。
二 網路優化
網路優化主要從三個方面進行：1. 速度；2. 成功率；3. 流量。
1 Gzip壓縮
HTTP協議上的Gzip編碼是一種用來改進WEB應用程式性能的技術，用來減少傳輸數據量大小，減少傳輸數據量大小有兩個明顯的好處：
可以減少流量消耗；
可以減少傳輸的時間。
DNS解析的失敗率占聯網失敗中很大一種，而且首次功能變數名稱解析一般需要幾百毫秒。針對此，我們可以不用功能變數名稱，才用IP直連省去 DNS 解析過程，節省這部分時間。
另外熟悉阿裡雲的小伙伴肯定知道HttpDns：HttpDNS基於Http協議的功能變數名稱解析，替代了基於DNS協議向運營商Local DNS發起解析請求的傳統方式，可以避免Local DNS造成的功能變數名稱劫持和跨網訪問問題，解決功能變數名稱解析異常帶來的困擾。 3 圖片處理
3.1 圖片下載
使用WebP格式；同樣的照片，採用WebP格式可大幅節省流量，相對於JPG格式的圖片，流量能節省將近 25% 到 35 %；相對於 PNG 格式的圖片，流量可以節省將近80%。最重要的是使用WebP之後圖片質量也沒有改變。
使用縮略圖；App中需要載入的圖片按需載入，列表中的圖片根據需要的尺寸載入合適的縮略圖即可，只有用戶查看大圖的時候才去載入原圖。不僅節省流量，同時也能節省記憶體！之前使用某公司的圖片存儲服務在原圖鏈接之後拼接寬高參數，根據參數的不同返回相應的圖片。
3.2 圖片上傳
圖片（文件）的上傳失敗率比較高，不僅僅因為大文件，同時帶寬、時延、穩定性等因素在此場景下的影響也更加明顯；
避免整文件傳輸，採用分片傳輸；
根據網路類型以及傳輸過程中的變化動態的修改分片大小；
每個分片失敗重傳的機會。
備註：圖片上傳是一項看似簡單、共性很多但實際上複雜、需要細分的工作。移動互聯網的場景和有線的場景是有很多區別的，例如移動網路的質量/帶寬經常會發生“跳變”，但有線網路卻是“漸變”。 4 協議層的優化
使用最新的協議，Http協議有多個版本：0.9、1.0、1.1、2等。新版本的協議經過再次的優化，例如：
Http1.1版本引入了“持久連接”，多個請求被覆用，無需重建TCP連接，而TCP連接在移動互聯網的場景下成本很高，節省了時間與資源；
Http2引入了“多工”、頭信息壓縮、伺服器推送等特性。
新的版本不僅可以節省資源，同樣可以減少流量；我對Http2並沒有實際接入經驗，此處僅從原理進行分析。 5 請求打包
合併網路請求，減少請求次數。對於一些介面類如統計，無需實時上報，將統計信息保存在本地，然後根據策略統一上傳。這樣頭信息僅需上傳一次，減少了流量也節省了資源。 6 網路緩存
對服務端返回數據進行緩存，設定有效時間，有效時間之內不走網路請求，減少流量消耗。對網路的緩存可以參見HttpResponseCache。
備註：我們也可以自定義緩存的實現，一些網路庫例如：Volley、Okhttp等都有好的實踐供參考。 7 網路狀態
根據網路狀態對網路請求進行區別對待，2G與Wifi狀態下網路質量肯定是不一樣的，那對應的網路策略也應該是不一樣的。例如：在Wifi場景下可以進行數據的預取、一些統計的集中上傳等；而在2G場景下此類操作以及網路請求的次數策略都應該調低。網路狀態可以由TelephonyManager.getNetworkType()方法獲取到。
備註：還可以使用Facebook的開源庫network-connection-class來做網路狀態的判斷。 8 其它
斷點續傳，文件、圖片等的下載，採用斷點續傳，不浪費用戶之前消耗過的流量；
重試策略，一次網路請求的失敗，需要多次的重試來斷定最終的失敗，可以參考Volley的重試機制實現。
Protocol Buffer
Protocol Buffer是Google的一種數據交換的格式，它獨立於語言，獨立於平臺。相較於目前常用的Json，數據量更小，意味著傳輸速度也更快。
具體的對比可以參見：《Protobuffer和json深度對比》。
儘量避免客戶端的輪詢，而使用伺服器推送的方式；
數據更新採用增量，而不是全量，僅將變化的數據返回，客戶端進行合併，減少流量消耗；
