Android網絡分析和優化

目前針對公司Android端的SDK進行實際測試，反映出存在網絡加載資源緩慢的問題，在知曉目前CDN的可能存在不穩定的情況下，針對sdk本身的網絡模塊進行了相應的分析，整理出相關的測試記錄，幫助後期可以做出的優化。

典型的HTTP請求流程說明：

發起一次完整的視頻廣告請求包括：

根據廣告位請求Ad內容 下載廣告視頻截圖 下載Logo角標請求 下載插屏頁模板Temp資源 下載廣告視頻的video文件 下載插屏頁html的source資源

如下圖所示，根據廣告請求AD返回成功後，才會執行下載資廣告資源的任務，這裡是同步。而當服務器返回AD數據以後，發起多線程異步下載廣告資源的任務。只有當一次視頻廣告所需的全部資源全部下載成功時，才會進入廣告的播放顯示流程。

簡單的理解就是，多個下載任務是並發的，對內容的獲取是異步的。

數據獲取和內容解析

一般來說，客戶端從服務端請求獲取數據，緩存數據內容，最終按不同形式呈現出來。所以對資源的加載簡單地分為下面兩個環節：
* 數據獲取：也就是發送請求給服務器返回相應的數據。
* 內容解析：對服務器返回的不同數據類型，在設備上緩存的文件形式，對應其不同的解析方式。

網絡任務分析

通過手機端設置代理方式，借助Fiddler對手機端的網絡數據進行抓包分析。下面是針對SDK項目的demo程序來進行數據抓包分析：

可以看出，針對一次完成的視頻廣告請求，一共是發起6次網絡請求的任務，與上面描述的內容一致，下面針對這些任務的實際執行情況和相應的數據指標來進行分析。<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxoNSBpZD0="網絡任務耗時分析公司網絡環境下根據廣告位請求ad">網絡任務耗時分析：（公司網絡環境下根據廣告位請求AD）

通過分析請求AD任務的整體耗時分布，發現耗時主要是在進行DNS解析和TCP握手連接兩個方面。

針對上面兩點通常的優化有下面幾種方式：
1.采用IP直連的方式，避免需要把域名通過DNS服務器解析得到IP地址這個耗時過程；
2.同時考慮到CDN分布式部署情況，域名解析到的IP地址並不一定，增加DNS緩存的設置；

將域名和從DNS服務器解析得到的IP地址保存在DNS緩存中。當下一次再使用這個域名時，就直接從DNS緩存裡獲得所需的信息，而無需再訪問DNS服務器。

3.建立TCP/IP可靠連接，是需要三次握手協議，每次請求都重復這個建立連接的過程，無疑是非常耗時的，考慮下面的方式：

請求合並，對數據量小而零散請求都一次集中執行完畢，類似的請求做合並；
分優先級、延遲部分請求，將不重要的請求延遲，削峰減少並發；
連接復用，不需要每次都通過“三次握手：建立一個新連接，再通過“四次揮手”來關閉連接；

整個請求的TimeLine

網絡任務數據傳輸分析：

請求頭和響應頭

請求和響應的內容：

所占的比例

通過上面的數據表現，考慮對網絡傳輸的數據進行一下處理：
減小請求數據大小
1.對於 POST 請求，Body 可以做 Gzip 壓縮
2.對請求頭進行壓縮，Http 1.1 不支持，可以進行SPDY改造後支持， Http 2.0 原生支持。

Http 1.1 可以通過服務端對前一個請求的請求頭進行緩存，後面相同請求頭用 md5 之類的 id 來表示即可。

減小返回數據大小
通常一般對網絡數據優化的措施是：
(1) 對返回的內容數據使用 Gzip 壓縮
(2) 精簡數據格式如 JSON 代替 XML，WebP 代替其他圖片格式
(3) 對於不同的設備不同網絡返回不同的內容，如不同分辨率圖片
(4) 增量更新需要數據更新時，可考慮數據增量更新。如常見的服務端進行 bsdiff，客戶端進行 bspatch。
(5) 大文件下載支持斷點續傳和多線程下載，並緩存 Http Resonse 的 ETag 標識，下次請求時帶上，從而確定是否數據改變過，未改變則直接返回 304。

下圖是對比Json數據使用 Gzip 壓縮前後對比圖
返回內容開啟 Gzip壓縮前

開啟Gzip壓縮後

對比發現，開啟Gzip後可以減少57.3%的數據傳輸量

網絡任務優化措施

 

考慮預取包括預連接、預加載數據。 使用HttpUrlConnection替換目前的HttpClient，可以具有默認的Gzip壓縮和連接復用實現 DNS優化，確定IP直連和DNS緩存兩者結合的方式 多連接下載，對於較大文件，如大圖片、文件下載可考慮多連接下載

 

需要控制請求的最大並發量，畢竟移動端網絡受限

增加網絡性能的監控，畢竟優化需要通過數據對比才能看出效果，所以監控系統必不可少，通過前後端的數據監控確定調優效果。