優化 APP 網絡流量

套餐雖然優惠，流量仍是很貴，對用戶而言網絡流量就是錢吶！用戶習慣打開系統自帶 APP 流量統計功能（以下），從 APP 的角度，總不但願用戶一眼看出自家的 APP 是流量大戶，因此有必要花時間知道 APP 的流量怎麼流失的。可是系統的流量統計功能只是很粗略的對每一個 APP 消耗的流量總量（分時）進行統計，可是程序員須要對 APP 的流量進行更精細、多維度的分析，從而有針對性地優化 APP 數據流量。

 

Android 流量測量經常使用方法

	方法	侷限
從 linux 系統文件的流量	Android 基於 Linux，系統提供了 /proc/net/dev、/proc/uid_stat/{uid} 等系統文件可獲取整個系統以及具體 APP（uid） 的流量統計。同類文章不可勝數	只能獲取 APP 的某段時間的總流量，沒法對流量進行更細粒度的分解，具體哪一個請求耗流量
從 Android API	Android 自己也提供了一些 API 來獲取系統流量（設置的流量統計就是從這裏來的）：TrafficStats和 NetworkStatsManager	本質也是經過讀取系統中的流量數據文件，某些方法沒有時間參數，無法獲取具體時間段的流量，而且還可能要用戶開啓系統權限 /root 才能使用
代理抓包	使用網絡代理工具，截獲每個網絡請求響應包，分析請求的數據量，經常使用的工具備：tcpdump、 wireshark，github 上提供了一個開源的數據包分析項目 pcap2har	不少抓包軟件須要在設備上配置代理，作不少額外的系統配置，很是麻煩；代理對 https 支持不行，須要爲每一個域名安裝僞造的證書；此外，抓包工具的流量分析並不現成，須要必定的二次開發

注：鵝廠的 GT 性能測試工具的流量測試方案其實就是以上三種方法的彙總，也就僅僅能獲取某段時間內被測應用的 流量大小和趨勢 ，以及 GT 對 Wireshark 封裝進行抓包，抓的是經過手機網卡的所有數據流量，卻不能分析單獨應用的流量狀況。因此說鵝廠的 GT 工具對於手機應用流量只是停留在得到應用流量，拿下來看看的階段，並不能提供行之有效的流量優化指導策略。

基於插樁的精細化分析

以上列舉的幾種流量分析方法，或是簡單粗暴統計流量，開發者依然找不到耗費流量的程序代碼；或是抓包，配置繁瑣易錯，二次開發成本高，實現自動化的代價高。理想狀況下，開發者自行在源代碼中打點，記錄全部網絡請求的起始結束以及流量消耗，而後分析 log，可是手工打點顯然是要命的。
代碼 插樁 從底層完全解決了這些問題，根據規則對 APK 的字節碼（ Dex 文件）進行修改，模仿人工，在 APP 每次發送的 HTTP 請求的地方插入監控代碼，運行時採集請求數據，並分析流量。詳細原理請看：https://testerhome.com/topics/9264

Appetizer 就是業界爲數很少可以穩定應用插樁技術的工具，經過 插樁監控 http 請求 並進行精細化的正確性、性能、流量等多維度分析，支持基本全部的主流 http 庫，事實上絕大多數的庫都是對一些基本 http 庫的再次封裝（尤爲是那些所謂的快速開發框架，基本都是用了 okhttp 來作 http 請求的）。因此 Appetizer 經過截獲底層的這些庫來支持包括 HttpURLConnection， Apache HTTP client, okhttp 2/3，retrofit, volley 等。同時 https 是徹底能夠截獲的，不一樣於抓包工具，抓包工具的底層原理是網絡代理，而 https 的設計是防止代理軟件看到請求內容，因此抓包工具須要額外配置僞造的證書等等麻煩的事情；而 Appetizer 的底層原理是 打點 ，採集的數據比如在源代碼裏面能看到的數據同樣，沒有這個問題，https 請求的內容能夠完美抓到。

使用 Appetizer 進行插樁分析的方法很簡單，上傳 apk，插樁，下載插樁後的 apk，而後在設備上跑，完成後經過 Appetizer 分析，生成測試報告。具體例子，請戳 https://testerhome.com/topics/8162。

每次分析會產生一個分析報告，請戳眼睛打開報告：

 

這是一個 Appetizer 測試報告的截圖，這裏看到的是統計信息，左邊四個功能項目分別是：統計信息，業務流程建模，詳細時間軸圖，流量分析；因此請戳第四個

 

點擊進入流量分析界面，橫軸是時間，縱向是分類標準，一個點表明一個 http 請求，大的表明流量大，支持左右拖拽以及滑輪縮放，上方有六種分類標準輔助流量分析

 

點擊圖中某個點，能夠查看對應網絡請求的詳細信息

 

尋找流量殺手並優化

既然是對流量進行分析，很天然的，咱們須要知道 APP 進行網絡請求的域名、以哪一種方式發送與接收數據、數據類型等。Appetizer 提供的精細化流量分析從不一樣的維度解析 APP 網絡流量，從不一樣角度建議優化策略。

按類型分類: 圖片處理？ HTTP 壓縮？

 

Appetizer 將網絡請求，按照獲取數據類型劃分爲圖片、文本、協議和其餘請求，實際 APP 使用最普遍的三類。以上圖爲例，整體來講，APP 網絡請求以協議流量和圖片流量爲主，協議流量多而密集，圖片流量少而大，天然優先優化協議請求和圖片。

協議 一般是請求某個業務數據，返回數據類型常見爲 JSON, XML 等文本格式，最有效的方法就是 gzip 壓縮 http 請求了，壓縮率通常高達70%以上。安利一個檢測是否啓用 gzip 的工具，以 testerhome 首頁爲例，壓縮率達到了80%。

 

圖片資源 也是現代 APP 主要的"流量大戶"，由於 APP 廣泛都要適應高清化的體驗，產品的圖片愈來愈大。其實圖片格式上也很是有講究，選擇更高效的圖片處理框架，能夠自動對網絡的圖片進行自動轉碼、適應屏幕、自動緩存等，節省流量的同時節省內存提升圖片加載效率。經常使用的有：Picasso、Glide、Fresco。此外，不少 APP 有一個設置是在WIFI和流量下使用不一樣清晰度（大小）的圖片，這也是能夠考慮的一個設計。

最後 文本（網頁） 順應 h5 化的浪潮也慢慢成爲流量大軍中值得關注的部分，相似協議，文本類的數據用 gzip 壓縮，又快壓縮率又高。

按MIME類型分類: 使用現代的格式和庫

 

MIME類型是 HTTP 響應的 Content-Type 域，對請求數據類型進行更細粒度的劃分，常見有以 text、image、application 開頭的格式類型。對於圖片流量，不一樣類型圖片在 
Android 中的顯示代價是不一樣的，使用不一樣顯示方式代價也是不一樣的。好比，png 圖片佔的內存較大，若 png 圖片過多，會容易垃圾回收，甚至內存溢出；而 jpg 圖片的內存小，可是圖片解碼複雜，耗時多。開發者根據上圖中圖片的類型選擇最優的圖片優化方式。此外，能夠建議運營使用更現代格式（解碼快，文件小，質量高），好比使用 webp，使用 mozjpeg 庫提升 jpeg 圖片20%的壓縮率，使用原生 mpeg4 格式替代 gif 等。

按根域名/子域名分類: 明明白白第三方 SDK 流量

 

 

在 APP 開發中須要用到不少第三方提供的 SDK 服務，例如地圖服務，廣告等等。Appetizer 從請求url中提取出服務器域名，獲取 APP 網絡請求數據的來源。從根域名分析結果圖中，首先可以獲取 APP 發出網絡請求的全部服務器（自家域名，三方域名）狀況，有針對性的關注請求最多的服務器，能監控到不一樣時間段服務器的響應狀況。

按請求方法分類：關注到流量的協議設計

APP 客戶端發送 HTTP 請求，最經常使用的請求方法有 GET（下行流量）、POST（上行流量）。請求方法結果圖，反饋給開發者 APP 每一個網絡請求的數據請求方式是什麼。從圖中的分佈，能夠排查出因請求方式差別形成的流量問題。例如常見的 POST 重複加載問題：當咱們屢次發出一樣的 POST 請求後，其結果是建立出了若干的資源，形成了流量的無效消耗，諸如此類問題都能經過請求方法分類的圖中查到；而 GET 請求，從定義上應該要指定返回內容的緩存可能行，現代的 HTTP 例如 okhttp 均可以識別緩存要求，並自動進行本地文件緩存，減小沒必要要的重複請求。

按網絡庫分類: 統一使用高效的 HTTP 庫

APP 中經常使用的 HTTP 請求庫有 HttpURLConnection, Apache HTTP Client, OkHttp，不一樣的請求庫產生的數據流量也是不一樣的。HttpURLConnection 具備的壓縮和緩存機制能夠有效地減小網絡訪問的流量，OkHttp 自動添加Accept-Encoding: gzip，支持自動解壓，並對 HTTP 響應的內容在磁盤上進行緩存。根據結果圖中不一樣網絡請求使用的網絡庫狀況，在優化 APP 時選擇最優的 HTTP 請求庫。