1、 前言
移動(dòng)互聯(lián)網(wǎng)發(fā)展到現(xiàn)在,雖然用戶的聯(lián)網(wǎng)方式已經(jīng)完成了3G/4G網(wǎng)絡(luò)依賴(lài)到Wifi依賴(lài)的轉(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類(lèi)提供了多個(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)性角度分為:一類(lèi)是用戶的操作直接導(dǎo)致的流量消耗腕够;另一類(lèi)是后臺(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ò)類(lèi)型設(shè)計(jì)不同的訪問(wèn)策略
比如使用非WIFI網(wǎng)絡(luò)進(jìn)行大圖定庵、視頻資源查看,是否會(huì)提醒用戶當(dāng)前操作會(huì)耗費(fèi)過(guò)多的流量,是否需要切換到WIFI場(chǎng)景進(jìn)行瀏覽
參考:
Android性能優(yōu)化典范《Network Performance》
《移動(dòng)App性能評(píng)測(cè)與優(yōu)化》
Android端消息推送總結(jié):http://www.52im.net/thread-195-1-1.html
騰訊原創(chuàng)分享(二):如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗(上篇):http://www.52im.net/thread-696-1-1.html
《Protobuffer和json深度對(duì)比》