使用GT测试流量：
对流量要求没有那么严格的话可以在安卓的设置里面查看
Wireshark：抓包分析工具，也提供了安卓手机的抓包实现，GT中抓包的功能就是
在其提供的实现基础上的易用性封装起来，在本次测试中用wireshark进行抓包分析。PC端安装
如果我们可能需要知道一个业务操作过程内，消耗的流量，及发出请求的流量，收到的响应结果的流量各有多少，并且流量的消耗曲线是一个什么走势，这个时候我们就需要GT了，这里GT提供了两个方法一种进行简单的测试方法，也提供了一个严谨但麻烦的测试方法
1.在安卓查看APP消耗的流量：
设置——》流量管理———》流量排行、
接下来我们使用GT监控APP流量的测试：
首先我先来介绍这种简单的方式
- 先将应用运行起来，然后启动 GT 并在 GT 上选中被测应用及被测项 NET（流量）。
2.业务操作前，启动数据采集，将会记录选中应用的流量的变化，为了方便统计，可以先 把业务操作前发生的流量记录归零。
3.退到应用界面，执行需测试的业务操作。
4.业务操作后，回到 GT 界面，停止流量数据的采集，查看本次业务操作流量的变化。
我们再来看看麻烦而严谨的方式：
如果只是纯粹测测流量，上面的方式也足够了，那我们为什么需要麻烦而严谨的方式 呢？这里有两个原因，一个是仅仅知道流量的大小和趋势，还不足以对后续的流量优化进 行明确的指导，即知道流量可能有点多，但不知道该如何着手优化。另一个是原因是弥补 上面方式的一个不足：有的应用，使用了本地 socket 和手机里其他进程产生交互，有时候 Android 系统会把这种手机内部的 socket 传输的数据量也计算到应用消耗的流量里(比如常 见的视频应用不少都有这个问题)，此时上面的方式就显得不够准确了，要获得真是网卡上 发生的流量，就需要抓包这种终极方法了。注意掌握这种方法的前提是您得先掌握基础的 TCP 和 HTTP 网络知识。
手机抓包是针对手机的网卡，所以这种方式无法单独抓一个应用的包，需要后续将归属 于应用的包分析出来，而为了后续分析减少工作量，测试时候应尽量把其他能消耗流量的应 用都关了。Android 手机的抓包是 Wireshark 提供的实现，GT 上面做了封装，使手机可以不 必连着 PC 即可抓包，方便在室外测试的场景。
注意这里需要在PC端安装一个Wireshark好了 我们第一步 ：点击插件 —>>选择抓包
看来这里 你们需要准备一个Wireshark 这个工具直接百度下载就好
把文件下载到电脑上面，选择Wireshark 打开选择统计下面的第一个
通过对包的过滤分析，我们自然就可以得到流量的大小，产生流量的类型和原因，请 求的频率，这样就能够对后续的流量优化进行指导了。
常见的流量问题 最后简单例举几类可控的比较容易优化的流量问题给大家： 1.冗余内容
同类请求被间隔执行，请求的内容包含一些相对静态的信息，正确的处理是第一次请求 包括静态信息就好，后面的同类请求只包含必要的即时变化信息即可。错误的处理方式是每 次请求服务器都返回一次静态信息。
1.冗余请求
有的时候会发现应用短时间内发出多个同样的请求，收到结果也都几乎一样，这种情况 应该尽量减少请求次数，同时注意排查程序逻辑错误，也许问题不像表面看起来那么简单。
2.无用请求
有的请求，你会发现谁也不知道它是干嘛的，很可能是以前版本遗留下来的无用请求， 或者是引用的其他代码包偷偷发出的，甚至是间谍请求，请收集一切证据后，毫不犹豫的干 掉它。
3.永远无法得到回应的请求
如果见到某类请求永远的连接失败或被返回 404 之类的失败结果，那它不是历史遗留的 多余请求，就是某个不易察觉的功能已经失效了。
4…过多的失败请求
有见过一类或一组请求，n 个成功之中夹着 m 个失败的吗？举个简单的场景，某类请 求，间隔 1 分钟后连续发两次，总是先有一次失败的请求，1s 后马上再次发出一次同样的 请求就成功了（这里 1s 后发出的请求是指业务逻辑层判断前面请求失败后延迟 1s 后重传 的）。很好奇为什么第一次总失败是吧，就有这么种情况，客户端两次请求乐观的想要复用 同一个 TCP 连接(长连接半长连接)，但是服务端不这么想，也许是客户端发起两次请求的间 隔，超出了服务端长设置的长连接无响应时限。。如何判断呢？看看失败的那次请求，是否 和前一次成功的请求复用了同一个 TCP 连接（体现在 Wireshark 的 streamId）。
5.非预期请求
比如一种常见的情况，应用退后台后，有些请求就没必要了，观察下自己的产品，是 否在后台真的没有发出这些请求
