<轉>Android App性能評測分析－網絡流量篇

一、 前言

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

二、 流量測試方法

2.1 流量理解

運營商替咱們的手機轉發數據報文，數據報文的總大小（字節數）即流量，這裏的數據報文包含手機上下行的報文。因爲數據報文采用IP協議傳輸，運營商計算的流量通常是包含IP頭的數據報文大小

2.2 流量數據獲取

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

 

流量獲取.png

 

下面將會簡單介紹這三種統計方法，會重點介紹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.png

 

關於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 

 

流量查詢.png

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小時後查看流量變化，看流量的變化走勢，嘗試從後臺運行角度分析具體耗費流量的緣由

三、XX銀行流量性能評測結果分析

3.1 總覽

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

 

各場景流量統計及得分對比.png

從流量對比看，行業競品均值爲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啓動時應該提醒用戶是否開啓推送服務。

 

 

流量查詢.png

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

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

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

可是咱們的APP設置的心跳週期爲5分鐘，5分鐘未操做鎖屏時，當用戶點亮屏幕的時候，會作一次心跳喚醒,這個5分鐘時間是在合理範圍內，並且心跳機制會比輪詢機制更減小流量的耗費，心跳機制主要做用是防止NAT超時, 其次是探測鏈接是否斷開，不可缺乏，不能爲了流量優化而犧牲功能。
另外，若是APP和服務器實時性數據傳輸要求不高的話，能夠不使用心跳發包維持長鏈接，否則就會帶來流量的不合理耗費。

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

1.後臺接口是否返回冗餘數據

例如理財產品理財列表接口通常會返回理財產品至關多的信息，其中這些信息有50%的字段是不須要展示給用戶的，其實這就能夠考慮在接口設計的時候與前端開發約定好將這部分後端返回的數據做爲冗餘數據，後續再也不返回給前端，減小流量的消耗。
另外APP端和服務器端的每一個接口的數據結構都儘可能簡單，每一個字段對應的內容也應該儘可能簡短。

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

HTTP協議上的Gzip編碼是一種用來改進WEB應用程序性能的技術，用來減小傳輸數據量大小，減小傳輸數據量大小有兩個明顯的好處：
能夠減小流量消耗；
能夠減小傳輸的時間。

3.圖片格式處理是否得當：通常來講WebP格式>JPG>PNG

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

4. 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深度對比》

 

做者：蕭竹 出處：https://www.jianshu.com/u/88caeb7696f5 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接。