性能優化5--網絡優化
阿新 • • 發佈：2018-07-07
大文件 應用程序 img 實現 處理 1.0 對待 帶來 上傳
Stetho是Facebook出品的一個Android應用的調試工具。無需Root即可通過Chrome，在Chrome Developer Tools中可視化查看應用布局，網絡請求，sqlite，preference等。同樣集成了Stetho之後也可以很方便的查看網絡請求的各種情況。
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深度對比》。
盡量避免客戶端的輪詢，而使用服務器推送的方式；
數據更新采用增量，而不是全量，僅將變化的數據返回，客戶端進行合並，減少流量消耗；
一. 網絡監控
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深度對比》。
盡量避免客戶端的輪詢，而使用服務器推送的方式；
數據更新采用增量，而不是全量，僅將變化的數據返回，客戶端進行合並，減少流量消耗；
性能優化5--網絡優化