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的包大小、报文协议、更新机制、配置机制、心跳机制，后台服务耗费流量方向进行流量的测试及分析。

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深度对比》