1傻挂、 前言
移動(dòng)互聯(lián)網(wǎng)發(fā)展到現(xiàn)在，雖然用戶的聯(lián)網(wǎng)方式已經(jīng)完成了3G/4G網(wǎng)絡(luò)依賴到Wifi依賴的轉(zhuǎn)變，但是過(guò)多以及沒(méi)有經(jīng)過(guò)處理的網(wǎng)絡(luò)請(qǐng)求平窘，會(huì)消耗用戶的網(wǎng)絡(luò)流量,造成用戶流量費(fèi)用（金錢(qián)）的損失，高流量的消耗必然導(dǎo)致非WIFI場(chǎng)景用戶的流失凳怨，流量測(cè)試在性能評(píng)測(cè)中勢(shì)必會(huì)占較大的權(quán)重瑰艘。下面會(huì)根據(jù)實(shí)際app性能測(cè)試案例，展開(kāi)進(jìn)行app性能評(píng)測(cè)之網(wǎng)絡(luò)流量的分析和總結(jié)肤舞。
2紫新、 流量測(cè)試方法
2.1 流量理解
運(yùn)營(yíng)商替我們的手機(jī)轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)文，數(shù)據(jù)報(bào)文的總大欣钇省（字節(jié)數(shù)）即流量芒率，這里的數(shù)據(jù)報(bào)文包含手機(jī)上下行的報(bào)文。由于數(shù)據(jù)報(bào)文采用IP協(xié)議傳輸杖爽，運(yùn)營(yíng)商計(jì)算的流量一般是包含IP頭的數(shù)據(jù)報(bào)文大小
2.2 流量數(shù)據(jù)獲取
流量獲取方式對(duì)比總結(jié)如下：
下面將會(huì)簡(jiǎn)單介紹這三種統(tǒng)計(jì)方法敲董，會(huì)重點(diǎn)介紹TCP收發(fā)長(zhǎng)度統(tǒng)計(jì)紫皇，因?yàn)樵摲椒〞?huì)在我們移動(dòng)端APP流量測(cè)試中最常用到
2.2.1 抓包測(cè)試法
原理：
流量測(cè)試最直接的方法就是抓包。在App運(yùn)行期間腋寨，通過(guò)抓包工具如Tcpdump+wireshark把手機(jī)收發(fā)的所有報(bào)文度抓取下來(lái)聪铺，再計(jì)算收發(fā)報(bào)文總大小，即App消耗的流量萄窜。
操作方法：操作方法網(wǎng)上一搜教程一大堆铃剔，篇幅也較長(zhǎng)，在這里不做具體介紹查刻。
優(yōu)勢(shì)：數(shù)據(jù)準(zhǔn)確
劣勢(shì)：tcpdump有個(gè)問(wèn)題键兜，就是它捕捉到的流量是系統(tǒng)層面的，我們很難區(qū)分捕捉得到的流量數(shù)據(jù)是否都是當(dāng)前apk產(chǎn)生的穗泵，所以如果我們需要測(cè)試某一個(gè)App消耗的流量需要禁用其他APP的連網(wǎng)權(quán)限普气，需要ROOT，操作起來(lái)步驟也比較長(zhǎng)佃延，如果追求高效率不推薦使用該方法现诀。
2.2.2 安卓自身提供的TCP收發(fā)長(zhǎng)度統(tǒng)計(jì)功能
原理：一般APP和后臺(tái)服務(wù)器之間的通信都是基于TCP的，所以我們可以利用此統(tǒng)計(jì)來(lái)測(cè)試我們APP的流量履肃，而且安卓提供的該統(tǒng)計(jì)功能是按照APP緯度來(lái)統(tǒng)計(jì)的仔沿。
優(yōu)勢(shì)：不需要禁止其他app的連網(wǎng)權(quán)限而且手機(jī)不需要ROOT，操作步驟簡(jiǎn)單尺棋，獲取數(shù)據(jù)相對(duì)準(zhǔn)確封锉。
劣勢(shì)：這種方式只能獲取TCP協(xié)議的流量，UDP的沒(méi)有計(jì)算膘螟。
操作步驟
1）使用ps命令查看所測(cè)app的uid
關(guān)于UID成福，簡(jiǎn)單地進(jìn)行下說(shuō)明。在Linux系統(tǒng)中萍鲸，UID表示的是User Identifier闷叉，主要用于表示是哪位用戶運(yùn)行了該程序擦俐。但在Android系統(tǒng)中脊阴，由于Android系統(tǒng)本身就為單用戶系統(tǒng)，這時(shí)UID就被賦予了新的使命蚯瞧，主要用于實(shí)現(xiàn)數(shù)據(jù)共享嘿期。具體地，Android系統(tǒng)為每個(gè)應(yīng)用都分配了一個(gè)UID埋合，不同apk的UID幾乎都是互不相同的备徐，而對(duì)于不同UID的apk，不能共享數(shù)據(jù)資源甚颂。之所以用“幾乎”蜜猾，是因?yàn)橛袝r(shí)候同一廠家會(huì)存在多個(gè)產(chǎn)品秀菱，并且希望能在多個(gè)apk之間實(shí)現(xiàn)數(shù)據(jù)共享，這個(gè)時(shí)候蹭睡，便可通過(guò)在menifest配置文件中指定相同的sharedUserId衍菱，然后在Android系統(tǒng)中安裝應(yīng)用時(shí)便會(huì)分配相同的UID。
2）進(jìn)入/proc/uid_stat/10850目錄肩豁，cat獲取當(dāng)前tcp_snd和tcp_tcv的初始值
shell@OnePlus:/ $ cat /proc/uid_stat/10853/tcp_rcv
shell@OnePlus:/ $ cat /proc/uid_stat/10853/tcp_rcv
3）此時(shí)可以開(kāi)始測(cè)試了脊串，測(cè)試完成后再次獲取tcp_snd和tcp_tcv的值
4）所測(cè)時(shí)間內(nèi)的流量計(jì)算
發(fā)送流量：tcp_snd_new-tcp_snd_old=2032150-893233=1128917bytes
接收流量：tcp_rcv_new-tcp_rcv_old=18648825-1350829=17297996bytes
注意：測(cè)試前記錄下數(shù)字，測(cè)試完后減去記錄的數(shù)字就是流量大小清钥。單位bytes琼锋，這個(gè)數(shù)據(jù)是累加的，除非卸載應(yīng)用才會(huì)被刪除祟昭。否則會(huì)一直增加缕坎。另外這種方式只能獲取TCP協(xié)議的流量，UDP的沒(méi)有計(jì)算篡悟。
所以也可以用下面的命令獲取到
其中第6和8列為 rx_bytes（接收數(shù)據(jù)）和tx_bytes（傳輸數(shù)據(jù)）包含tcp念赶，udp等所有網(wǎng)絡(luò)流量傳輸?shù)慕y(tǒng)計(jì)，一個(gè)uid可能對(duì)應(yīng)多個(gè) 進(jìn)程恰力，所以這有兩行流量是累加的就求和就行叉谜，這種方法只能再Android6.0以下手機(jī)上操作。
shell@OnePlus:/ $ cat /proc/net/xt_qtaguid/stats | grep 10853
2.2.3 第三方工具
原理：通過(guò)系統(tǒng)API來(lái)獲取基本的流量數(shù)據(jù)踩萎。TrafficStats類提供了多個(gè)方法獲取不同角度的流量數(shù)據(jù)停局，例如騰訊Gt、網(wǎng)易Emmagee香府、平安測(cè)試助手等
優(yōu)勢(shì)：簡(jiǎn)單快捷
劣勢(shì)：
（1）這種方法統(tǒng)計(jì)不到一些系統(tǒng)的DNS等流量董栽，還有不使用接口封裝的模塊產(chǎn)生的流量會(huì)被遺漏
（2）目前安卓6.0以上手機(jī)不再提供該API，所以安卓6.0以上手機(jī)均無(wú)法通過(guò)第三方工具獲取流量數(shù)據(jù)
2.3流量測(cè)試場(chǎng)景
流量可以從用戶使用的相關(guān)性角度分為：一類是用戶的操作直接導(dǎo)致的流量消耗企孩；另一類是后臺(tái)锭碳，即在用戶沒(méi)有直接使用情況下的流量消耗。所以會(huì)分以下幾種測(cè)試場(chǎng)景
2.31頁(yè)面流量測(cè)試
這種是基于用戶的操作直接導(dǎo)致的流量消耗而進(jìn)行的頁(yè)面流量測(cè)試勿璃，也是最基本的測(cè)試場(chǎng)景
2.3.2 切換至后臺(tái)運(yùn)行時(shí)流量測(cè)試
CPU空閑時(shí)擒抛，停留在主界面不退出，打開(kāi)網(wǎng)絡(luò)然后鎖屏补疑，24小時(shí)后查看流量變化
為什么需要測(cè)試產(chǎn)品的背景流量歧沪？在不操作 APP 的情況下，發(fā)現(xiàn)一天中每個(gè)時(shí)間段的流量都是不一樣的莲组，即上午的一小時(shí)消耗的流量可能就與下午的一小時(shí)消耗的流量不一樣诊胞。因?yàn)?APP 的后臺(tái)運(yùn)行機(jī)制， APP 后臺(tái)運(yùn)行時(shí)的流量一般都是按照時(shí)間策略觸發(fā)的锹杈，每天的各個(gè)時(shí)間段的發(fā)包頻率是不一樣的撵孤，基于這種機(jī)制迈着，我們就需要測(cè)試 24 小時(shí) APP 的背景流量。
2.3.3 隨機(jī)流量測(cè)試
APP在操作運(yùn)行時(shí)邪码，按照設(shè)置的時(shí)間規(guī)律寥假，比如每隔1小時(shí)后查看流量變化，看流量的變化走勢(shì)霞扬，嘗試從后臺(tái)運(yùn)行角度分析具體耗費(fèi)流量的原因
3糕韧、XX銀行流量性能評(píng)測(cè)結(jié)果分析
3.1 總覽
此次質(zhì)量開(kāi)放平臺(tái)-評(píng)測(cè)中心（http://fit-stg1.jryzt.com/Hyperion-server/html/index.html）的性能測(cè)試的采集的流量主要是針對(duì)場(chǎng)景頁(yè)面的流量測(cè)試，個(gè)人認(rèn)為實(shí)際上APP流量測(cè)試的場(chǎng)景遠(yuǎn)不止于頁(yè)面喻圃，應(yīng)該更傾向于面向整個(gè)APP的包大小萤彩、報(bào)文協(xié)議、更新機(jī)制斧拍、配置機(jī)制雀扶、心跳機(jī)制，后臺(tái)服務(wù)耗費(fèi)流量方向進(jìn)行流量的測(cè)試及分析肆汹。
從流量對(duì)比看愚墓，行業(yè)競(jìng)品均值為432.4KB，90分位約114.8KB昂勉，75分位約357.5KB浪册，中位數(shù)約700.9KB，25分位約2832.2KB岗照〈逑螅【榕商Bank】各場(chǎng)景頁(yè)面平均流量為43KB，看平均值表現(xiàn)優(yōu)秀攒至，頁(yè)面耗費(fèi)最大的流量為141.563KB厚者，未超過(guò)200K。仔細(xì)分析可以看出首頁(yè)加載是相對(duì)耗費(fèi)流量較大的頁(yè)面,這個(gè)頁(yè)面仍然有可優(yōu)化的空間迫吐。
3.2 首頁(yè)流量分析
根據(jù)抓包及代碼段分析顯示APP啟動(dòng)到首頁(yè)加載完成是一個(gè)預(yù)加載和異步加載的過(guò)程库菲。
(1) 啟動(dòng)到首頁(yè)加載完成網(wǎng)絡(luò)請(qǐng)求密集，請(qǐng)求內(nèi)容豐富,部分資源重復(fù)請(qǐng)求消耗流量志膀。
請(qǐng)求了相關(guān)配置信息熙宇、啟動(dòng)頁(yè)廣告、個(gè)推梧却、磁貼配置信息奇颠、商城理財(cái)產(chǎn)品列表败去，運(yùn)營(yíng)廣告Banner放航、F后端接口，廣告BANNER位圆裕、插件信息广鳍、任意門(mén)荆几、廚房、百度地圖SDK（talkingdata赊时、灰度升級(jí)）等林林總總加起來(lái)就有40+個(gè)網(wǎng)絡(luò)請(qǐng)求吨铸，加載的數(shù)據(jù)+廣告頁(yè)一共有1.7M左右，這說(shuō)明了我們的APP首頁(yè)設(shè)計(jì)的內(nèi)容比較豐富祖秒，部分資源重復(fù)請(qǐng)求诞吱，所以耗費(fèi)流量較多，這是產(chǎn)品設(shè)計(jì)問(wèn)題以及信息未做緩存處理導(dǎo)致竭缝，建議優(yōu)化房维。
（2）PushService在后臺(tái)消耗流量
每隔1分鐘、5分鐘抬纸、10分鐘通過(guò)ADB命令可以查看到咙俩，首頁(yè)加載完成后在在TAB各個(gè)頁(yè)簽之間切換不產(chǎn)生任何數(shù)據(jù)交互。但是PushService大約每隔1分鐘就要耗費(fèi)2000byte的流量湿故，為了保證消息的及時(shí)性阿趁，PushService會(huì)一直開(kāi)著，所以如果為了讓用戶少消耗流量坛猪，建議在APP啟動(dòng)時(shí)應(yīng)該提醒用戶是否開(kāi)啟推送服務(wù)脖阵。
（3）心跳機(jī)制耗費(fèi)流量？
理論上講墅茉，頻繁的心跳發(fā)送會(huì)耗費(fèi)流量独撇。
根據(jù)網(wǎng)上的一些說(shuō)法, 中移動(dòng)2/3G下, NAT超時(shí)時(shí)間為5分鐘, 中國(guó)電信3G則大于28分鐘, 理想的情況下, 客戶端應(yīng)當(dāng)以略小于NAT超時(shí)時(shí)間的間隔來(lái)發(fā)送心跳包。
心跳周期(即網(wǎng)絡(luò)空閑定時(shí)器的超時(shí)時(shí)間)過(guò)長(zhǎng),則服務(wù)器端要等比較長(zhǎng)的時(shí)間才能檢測(cè)到連接斷線;心跳周期過(guò)短時(shí)雖然能夠很快檢測(cè)到連接斷線,但是消耗在心跳包上的網(wǎng)絡(luò)資源會(huì)過(guò)大躁锁。
但是我們的APP設(shè)置的心跳周期為5分鐘纷铣，5分鐘未操作鎖屏?xí)r，當(dāng)用戶點(diǎn)亮屏幕的時(shí)候战转，會(huì)做一次心跳喚醒,這個(gè)5分鐘時(shí)間是在合理范圍內(nèi)搜立，而且心跳機(jī)制會(huì)比輪詢機(jī)制更減少流量的耗費(fèi)，心跳機(jī)制主要作用是防止NAT超時(shí), 其次是探測(cè)連接是否斷開(kāi)槐秧，不可缺少啄踊，不能為了流量?jī)?yōu)化而犧牲功能。
另外刁标，如果APP和服務(wù)器實(shí)時(shí)性數(shù)據(jù)傳輸要求不高的話镊靴，可以不使用心跳發(fā)包維持長(zhǎng)連接，不然就會(huì)帶來(lái)流量的不合理耗費(fèi)憎瘸。
4器赞、App端耗流量場(chǎng)景問(wèn)題及排查思路
1.后臺(tái)接口是否返回冗余數(shù)據(jù)
例如理財(cái)產(chǎn)品理財(cái)列表接口一般會(huì)返回理財(cái)產(chǎn)品相當(dāng)多的信息，其中這些信息有50%的字段是不需要展現(xiàn)給用戶的，其實(shí)這就可以考慮在接口設(shè)計(jì)的時(shí)候與前端開(kāi)發(fā)約定好將這部分后端返回的數(shù)據(jù)作為冗余數(shù)據(jù)硼控，后續(xù)不再返回給前端刘陶，減少流量的消耗。
另外APP端和服務(wù)器端的每個(gè)接口的數(shù)據(jù)結(jié)構(gòu)都盡量簡(jiǎn)單牢撼，每個(gè)字段對(duì)應(yīng)的內(nèi)容也應(yīng)該盡量簡(jiǎn)短匙隔。
2.相關(guān)圖片和視頻資源是否進(jìn)行Gzip壓縮后上傳
HTTP協(xié)議上的Gzip編碼是一種用來(lái)改進(jìn)WEB應(yīng)用程序性能的技術(shù)，用來(lái)減少傳輸數(shù)據(jù)量大小熏版，減少傳輸數(shù)據(jù)量大小有兩個(gè)明顯的好處：
可以減少流量消耗纷责；
可以減少傳輸?shù)臅r(shí)間。
3.圖片格式處理是否得當(dāng)：一般來(lái)說(shuō)WebP格式>JPG>PNG
同樣的照片撼短，采用WebP格式可大幅節(jié)省流量碰逸，相對(duì)于JPG格式的圖片，流量能節(jié)省將近 25% 到 35 %阔加；相對(duì)于 PNG 格式的圖片饵史，流量可以節(jié)省將近80%。最重要的是使用WebP之后圖片質(zhì)量也沒(méi)有改變胜榔。
- App中需要加載的圖片是否按需加載
App中需要加載的圖片按需加載胳喷，列表中的圖片根據(jù)需要的尺寸加載合適的縮略圖即可，只有用戶查看大圖的時(shí)候才去加載原圖夭织。不僅節(jié)省流量吭露，同時(shí)也能節(jié)省內(nèi)存
5.網(wǎng)絡(luò)請(qǐng)求方面：是否合并網(wǎng)絡(luò)請(qǐng)求，減少請(qǐng)求次數(shù)
APP端應(yīng)該盡量減少向服務(wù)器端發(fā)送請(qǐng)求的次數(shù)尊惰，能合并的接口盡量合并讲竿；每發(fā)一次請(qǐng)求，雙方就都需要至少向?qū)Ψ桨l(fā)送一次HTTP的頭字段數(shù)據(jù)弄屡；如果連接斷開(kāi)了题禀，還要多個(gè)和服務(wù)器的握手過(guò)程；這些都會(huì)多消耗網(wǎng)絡(luò)流量膀捷。
6.是否進(jìn)行網(wǎng)絡(luò)緩存
對(duì)服務(wù)端返回?cái)?shù)據(jù)迈嘹、圖片，JS進(jìn)行緩存全庸，設(shè)定有效時(shí)間秀仲，有效時(shí)間之內(nèi)不走網(wǎng)絡(luò)請(qǐng)求，減少流量消耗壶笼。但由于手機(jī)存儲(chǔ)空間有限神僵，也需要控制整個(gè)緩存大小，并給用戶提供清理緩存的選項(xiàng)覆劈。
7.是否采用客戶端的輪詢來(lái)獲取一些信息的查詢
采用客戶端的輪詢來(lái)獲取一些信息的查詢會(huì)消耗流量保礼，應(yīng)該使用服務(wù)器推送的方式沛励；
8.數(shù)據(jù)更新是否采用增量方式
數(shù)據(jù)更新采用增量，而不是全量氓英，僅將變化的數(shù)據(jù)返回侯勉，客戶端進(jìn)行合并鹦筹，減少流量消耗铝阐；
非 WiFi 情況下，對(duì)于 APP 界面展示的數(shù)據(jù)铐拐，在 APP 后臺(tái)運(yùn)行時(shí)盡量不去拉取徘键。
9.是否針對(duì)不同網(wǎng)絡(luò)類型設(shè)計(jì)不同的訪問(wèn)策略
比如使用非WIFI網(wǎng)絡(luò)進(jìn)行大圖、視頻資源查看遍蟋，是否會(huì)提醒用戶當(dāng)前操作會(huì)耗費(fèi)過(guò)多的流量吹害，是否需要切換到WIFI場(chǎng)景進(jìn)行瀏覽
