1、 前言

移動網際網路發展到現在，雖然使用者的聯網方式已經完成了3G/4G網路依賴到Wifi依賴的轉變，但是過多以及沒有經過處理的網路請求，會消耗使用者的網路流量,造成使用者流量費用（金錢）的損失，高流量的消耗必然導致非WIFI場景使用者的流失，流量測試在效能評測中勢必會佔較大的權重。下面會根據實際app效能測試案例，展開進行app效能評測之網路流量的分析和總結。

2、 流量測試方法

2.1 流量理解

運營商替我們的手機轉發資料包文，資料包文的總大小（位元組數）即流量，這裡的資料包文包含手機上下行的報文。由於資料包文采用IP協議傳輸，運營商計算的流量一般是包含IP頭的資料包文大小

2.2 流量資料獲取

流量獲取方式對比總結如下：

下面將會簡單介紹這三種統計方法，會重點介紹TCP收發長度統計，因為該方法會在我們移動端APP流量測試中最常用到

2.2.1 抓包測試法

原理：
流量測試最直接的方法就是抓包。在App執行期間，通過抓包工具如Tcpdump+wireshark把手機收發的所有報文度抓取下來，再計算收發報文總大小，即App消耗的流量。
操作方法：操作方法網上一搜教程一大堆，篇幅也較長，在這裡不做具體介紹。
優勢：資料準確
劣勢：tcpdump有個問題，就是它捕捉到的流量是系統層面的，我們很難區分捕捉得到的流量資料是否都是當前apk產生的，所以如果我們需要測試某一個App消耗的流量需要禁用其他APP的連網許可權，需要ROOT，操作起來步驟也比較長，如果追求高效率不推薦使用該方法。

2.2.2 安卓自身提供的TCP收發長度統計功能

原理：一般APP和後臺伺服器之間的通訊都是基於TCP的，所以我們可以利用此統計來測試我們APP的流量，而且安卓提供的該統計功能是按照APP緯度來統計的。
優勢：不需要禁止其他app的連網許可權而且手機不需要ROOT，操作步驟簡單，獲取資料相對準確。
劣勢：這種方式只能獲取TCP協議的流量，UDP的沒有計算。
操作步驟
1）使用ps命令檢視所測app的uid

關於UID，簡單地進行下說明。在Linux系統中，UID表示的是User Identifier，主要用於表示是哪位使用者執行了該程式。但在Android系統中，由於Android系統本身就為單使用者系統，這時UID就被賦予了新的使命，主要用於實現資料共享。具體地，Android系統為每個應用都分配了一個UID，不同apk的UID幾乎都是互不相同的，而對於不同UID的apk，不能共享資料資源。之所以用“幾乎”，是因為有時候同一廠家會存在多個產品，並且希望能在多個apk之間實現資料共享，這個時候，便可通過在menifest配置檔案中指定相同的sharedUserId，然後在Android系統中安裝應用時便會分配相同的UID。

2）進入/proc/uid_stat/10850目錄，cat獲取當前tcp_snd和tcp_tcv的初始值

shell@OnePlus:/ $ cat /proc/uid_stat/10853/tcp_rcv

shell@OnePlus:/ $ cat /proc/uid_stat/10853/tcp_rcv

3）此時可以開始測試了，測試完成後再次獲取tcp_snd和tcp_tcv的值
4）所測時間內的流量計算
傳送流量：tcp_snd_new-tcp_snd_old=2032150-893233=1128917bytes
接收流量：tcp_rcv_new-tcp_rcv_old=18648825-1350829=17297996bytes

注意：測試前記錄下數字，測試完後減去記錄的數字就是流量大小。單位bytes，這個資料是累加的，除非解除安裝應用才會被刪除。否則會一直增加。另外這種方式只能獲取TCP協議的流量，UDP的沒有計算。

所以也可以用下面的命令獲取到
其中第6和8列為 rx_bytes（接收資料）和tx_bytes（傳輸資料）包含tcp，udp等所有網路流量傳輸的統計，一個uid可能對應多個 程式，所以這有兩行流量是累加的就求和就行，這種方法只能再Android6.0以下手機上操作。

shell@OnePlus:/ $ cat /proc/net/xt_qtaguid/stats | grep 10853

2.2.3 第三方工具

原理：通過系統API來獲取基本的流量資料。TrafficStats類提供了多個方法獲取不同角度的流量資料，例如騰訊Gt、網易Emmagee、平安測試助手等
優勢：簡單快捷
劣勢：
（1）這種方法統計不到一些系統的DNS等流量，還有不使用介面封裝的模組產生的流量會被遺漏
（2）目前安卓6.0以上手機不再提供該API，所以安卓6.0以上手機均無法通過第三方工具獲取流量資料

2.3流量測試場景

流量可以從使用者使用的相關性角度分為：一類是使用者的操作直接導致的流量消耗；另一類是後臺，即在使用者沒有直接使用情況下的流量消耗。所以會分以下幾種測試場景

2.31頁面流量測試

這種是基於使用者的操作直接導致的流量消耗而進行的頁面流量測試，也是最基本的測試場景

2.3.2 切換至後臺執行時流量測試

CPU空閒時，停留在主介面不退出，開啟網路然後鎖屏，24小時後檢視流量變化

為什麼需要測試產品的背景流量？在不操作 APP 的情況下，發現一天中每個時間段的流量都是不一樣的，即上午的一小時消耗的流量可能就與下午的一小時消耗的流量不一樣。因為 APP 的後臺執行機制， APP 後臺執行時的流量一般都是按照時間策略觸發的，每天的各個時間段的發包頻率是不一樣的，基於這種機制，我們就需要測試 24 小時 APP 的背景流量。

2.3.3 隨機流量測試

APP在操作執行時，按照設定的時間規律，比如每隔1小時後檢視流量變化，看流量的變化走勢，嘗試從後臺執行角度分析具體耗費流量的原因

3、XX銀行流量效能評測結果分析

3.1 總覽

此次質量開放平臺-評測中心（http://fit-stg1.jryzt.com/Hyperion-server/html/index.html）的效能測試的採集的流量主要是針對場景頁面的流量測試，個人認為實際上APP流量測試的場景遠不止於頁面，應該更傾向於面向整個APP的包大小、報文協議、更新機制、配置機制、心跳機制，後臺服務耗費流量方向進行流量的測試及分析。

從流量對比看，行業競品均值為432.4KB，90分位約114.8KB，75分位約357.5KB，中位數約700.9KB，25分位約2832.2KB。【榕商Bank】各場景頁面平均流量為43KB，看平均值表現優秀，頁面耗費最大的流量為141.563KB，未超過200K。仔細分析可以看出首頁載入是相對耗費流量較大的頁面,這個頁面仍然有可優化的空間。

3.2 首頁流量分析

根據抓包及程式碼段分析顯示APP啟動到首頁載入完成是一個預載入和非同步載入的過程。

(1) 啟動到首頁載入完成網路請求密集，請求內容豐富,部分資源重複請求消耗流量。

請求了相關配置資訊、啟動頁廣告、個推、磁貼配置資訊、商城理財產品列表，運營廣告Banner、F後端介面，廣告BANNER位、外掛資訊、任意門、廚房、百度地圖SDK（talkingdata、灰度升級）等林林總總加起來就有40+個網路請求，載入的資料+廣告頁一共有1.7M左右，這說明了我們的APP首頁設計的內容比較豐富，部分資源重複請求，所以耗費流量較多，這是產品設計問題以及資訊未做快取處理導致，建議優化。

（2）PushService在後臺消耗流量

每隔1分鐘、5分鐘、10分鐘通過ADB命令可以檢視到，首頁載入完成後在在TAB各個頁籤之間切換不產生任何資料互動。但是PushService大約每隔1分鐘就要耗費2000byte的流量，為了保證訊息的及時性，PushService會一直開著，所以如果為了讓使用者少消耗流量，建議在APP啟動時應該提醒使用者是否開啟推送服務。

（3）心跳機制耗費流量？

理論上講，頻繁的心跳傳送會耗費流量。
根據網上的一些說法, 中移動2/3G下, NAT超時時間為5分鐘, 中國電信3G則大於28分鐘, 理想的情況下, 客戶端應當以略小於NAT超時時間的間隔來傳送心跳包。

心跳週期(即網路空閒定時器的超時時間)過長,則伺服器端要等比較長的時間才能檢測到連線斷線;心跳週期過短時雖然能夠很快檢測到連線斷線,但是消耗在心跳包上的網路資源會過大。

但是我們的APP設定的心跳週期為5分鐘，5分鐘未操作鎖屏時，當使用者點亮螢幕的時候，會做一次心跳喚醒,這個5分鐘時間是在合理範圍內，而且心跳機制會比輪詢機制更減少流量的耗費，心跳機制主要作用是防止NAT超時, 其次是探測連線是否斷開，不可缺少，不能為了流量優化而犧牲功能。
另外，如果APP和伺服器實時性資料傳輸要求不高的話，可以不使用心跳發包維持長連線，不然就會帶來流量的不合理耗費。

4、App端耗流量場景問題及排查思路

1.後臺介面是否返回冗餘資料

例如理財產品理財列表介面一般會返回理財產品相當多的資訊，其中這些資訊有50%的欄位是不需要展現給使用者的，其實這就可以考慮在介面設計的時候與前端開發約定好將這部分後端返回的資料作為冗餘資料，後續不再返回給前端，減少流量的消耗。
另外APP端和伺服器端的每個介面的資料結構都儘量簡單，每個欄位對應的內容也應該儘量簡短。

2.相關圖片和視訊資源是否進行Gzip壓縮後上傳

HTTP協議上的Gzip編碼是一種用來改進WEB應用程式效能的技術，用來減少傳輸資料量大小，減少傳輸資料量大小有兩個明顯的好處：
可以減少流量消耗；
可以減少傳輸的時間。

3.圖片格式處理是否得當：一般來說WebP格式>JPG>PNG

同樣的照片，採用WebP格式可大幅節省流量，相對於JPG格式的圖片，流量能節省將近 25% 到 35 %；相對於 PNG 格式的圖片，流量可以節省將近80%。最重要的是使用WebP之後圖片質量也沒有改變。

1. App中需要載入的圖片是否按需載入

App中需要載入的圖片按需載入，列表中的圖片根據需要的尺寸載入合適的縮圖即可，只有使用者檢視大圖的時候才去載入原圖。不僅節省流量，同時也能節省記憶體

5.網路請求方面：是否合併網路請求，減少請求次數

APP端應該儘量減少向伺服器端傳送請求的次數，能合併的介面儘量合併；每發一次請求，雙方就都需要至少向對方傳送一次HTTP的頭欄位資料；如果連線斷開了，還要多個和伺服器的握手過程；這些都會多消耗網路流量。

6.是否進行網路快取

對服務端返回資料、圖片，JS進行快取，設定有效時間，有效時間之內不走網路請求，減少流量消耗。但由於手機儲存空間有限，也需要控制整個快取大小，並給使用者提供清理快取的選項。

7.是否採用客戶端的輪詢來獲取一些資訊的查詢

採用客戶端的輪詢來獲取一些資訊的查詢會消耗流量，應該使用伺服器推送的方式；

8.資料更新是否採用增量方式

資料更新採用增量，而不是全量，僅將變化的資料返回，客戶端進行合併，減少流量消耗；
非 WiFi 情況下，對於 APP 介面展示的資料，在 APP 後臺執行時儘量不去拉取。

9.是否針對不同網路型別設計不同的訪問策略

比如使用非WIFI網路進行大圖、視訊資源檢視，是否會提醒使用者當前操作會耗費過多的流量，是否需要切換到WIFI場景進行瀏覽

參考：
Android效能優化典範《Network Performance》
《移動App效能評測與優化》
Android端訊息推送總結：http://www.52im.net/thread-195-1-1.html
騰訊原創分享(二)：如何大幅壓縮行動網路下APP的流量消耗（上篇）：http://www.52im.net/thread-696-1-1.html
《Protobuffer和json深度對比》