<转>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 本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文链接。