Foreword
We often mobile applications such confusion: Want to know the application fee does not cost flow; want to know the several similar applications, do
The same thing, which is more provincial traffic; deeper, wondering why so an application fee flow, flow consumed in
Which of; want to know the big 4G era, the house woke up and how to become someone else's car. . This article will introduce to you,
Simple method described above confused answers.
tool
GT (Chinese Name: portable tone): Tencent produced open source debugging tool, which was used for this test hand
Traffic statistics and packet capture machine. GT install the application on your Android phone (through the official website or download the application treasure).
Wireshark: packet capture analysis tools, also provides packet capture Android phone to achieve, GT in packet capture function
Ease of use is based on the realization that the package provided with this test Wireshark packet capture analysis. please at
Wireshark installed on the PC.
text
In fact, want to know an application fee does not cost flow, most Android4.x simple version of the system can already see the:
Fairly thick traffic concerns, it is enough to look at the top here, but the test of demand, only here to observe
Macroscopic flow, the flow rate to 1 day consumption would be unable to refine, if you want to know the specific business operation or a period of
Traffic within the time consuming it? If you want to know the time you start the application traffic consuming it? At this time in respect of the use of previously described
Tool.
Some little deeper than the front, we may need to know in the course of a business operation, traffic consumption, and issue
Flow request is received in response to the results of the respective numbers of the flow, and the flow consumption profile is how a trend. Then
In respect of the use of GT, GT and basic use on Why GT, GT website has detailed instructions, and here only
Traffic-related parts. GT provides a simple way of testing, but also provides a rigorous testing methods trouble.
First, we look at a simple way:
1. first application up and running, and then start the GT and select the application under test and test items NET (traffic) on GT.
2. Prior to business operations, for data acquisition, it will record changes in the flow of the selected application, in order to facilitate the statistics, you can
The flow record occurred before business operations to zero.
3. retreated to the application interface, perform the required testing business operations.
4. 业务操作后，回到 GT 界面，停止流量数据的采集，查看本次业务操作流量的变化
到这里，从前面一张图我们已经可以知道一个业务操作过程中消耗的流量，包括发出请
求的流量、收到响应结果的流量、流量消耗曲线是怎样一个走势了。
5. 我们可以保存本次测试结果到文件，以备后面更深入的分析
我们再来看看麻烦而严谨的方式：
如果只是纯粹测测流量，上面的方式也足够了，那我们为什么需要麻烦而严谨的方式
呢？这里有两个原因，一个是仅仅知道流量的大小和趋势，还不足以对后续的流量优化进
行明确的指导，即知道流量可能有点多，但不知道该如何着手优化。另一个是原因是弥补
上面方式的一个不足：有的应用，使用了本地 socket 和手机里其他进程产生交互，有时候
Android 系统会把这种手机内部的 socket 传输的数据量也计算到应用消耗的流量里(比如常
见的视频应用不少都有这个问题)，此时上面的方式就显得不够准确了，要获得真是网卡上
发生的流量，就需要抓包这种终极方法了。注意掌握这种方法的前提是您得先掌握基础的
TCP 和 HTTP 网络知识。
手机抓包是针对手机的网卡，所以这种方式无法单独抓一个应用的包，需要后续将归属
于应用的包分析出来，而为了后续分析减少工作量，测试时候应尽量把其他能消耗流量的应
用都关了。Android 手机的抓包是 Wireshark 提供的实现，GT 上面做了封装，使手机可以不
必连着 PC 即可抓包，方便在室外测试的场景。
1. 先从 GT 启动抓包
将抓到包文件导入到 PC，用 Wireshark 即可分析抓包文件。关于 Wireshark 的使用，和
PC 上的使用没有区别，请大家自行在网上搜索，这里仅对使用 Wireshark 的要点提示下：
1 我们最先需要知道我们的应用发出了哪些请求，对应了上行流量，可以在 Wireshark 左
上角【过滤】框输入"http"或"tcp"（如果确认过被测应用都是 http 请求，就只需要按 http
过滤）,确认测试场景 GET 和 POST 的请求类型和个数（过滤结果可按【Info】分类更
方便统计）。
如何判断一个应用的流量消耗偏高
如果看流量的绝对值看不出高低，那就找几个同类型的产品对比一下。如果完成同样的
事务，被测应用比同类产品高很多，那就是偏高了，可能有优化空间。
如何找到有效的优化点
把分析的不同类数据包，按包占总流量大小的比例，和包的数量排序，占比多的，和消
息数量多的，一个优化空间大，一个精简请求次数的机会大。
常见的流量问题
最后简单例举几类可控的比较容易优化的流量问题给大家：
冗余内容
同类请求被间隔执行，请求的内容包含一些相对静态的信息，正确的处理是第一次请求
包括静态信息就好，后面的同类请求只包含必要的即时变化信息即可。错误的处理方式是每
次请求服务器都返回一次静态信息。
冗余请求
有的时候会发现应用短时间内发出多个同样的请求，收到结果也都几乎一样，这种情况
应该尽量减少请求次数，同时注意排查程序逻辑错误，也许问题不像表面看起来那么简单。
无用请求
有的请求，你会发现谁也不知道它是干嘛的，很可能是以前版本遗留下来的无用请求，
或者是引用的其他代码包偷偷发出的，甚至是间谍请求，请收集一切证据后，毫不犹豫的干
掉它。
永远无法得到回应的请求
如果见到某类请求永远的连接失败或被返回 404 之类的失败结果，那它不是历史遗留的
多余请求，就是某个不易察觉的功能已经失效了。
过多的失败请求
有见过一类或一组请求，n 个成功之中夹着 m 个失败的吗？举个简单的场景，某类请
求，间隔 1 分钟后连续发两次，总是先有一次失败的请求，1s 后马上再次发出一次同样的
请求就成功了（这里 1s 后发出的请求是指业务逻辑层判断前面请求失败后延迟 1s 后重传
的）。很好奇为什么第一次总失败是吧，就有这么种情况，客户端两次请求乐观的想要复用
同一个 TCP 连接(长连接半长连接)，但是服务端不这么想，也许是客户端发起两次请求的间
隔，超出了服务端长设置的长连接无响应时限。。如何判断呢？看看失败的那次请求，是否
A successful request and before reuse the same TCP connection (reflected in streamId Wireshark's).
unexpected request
For example, a common condition, after application retreat backstage, no need to request some of the observed under their own products,
No really did not issue such a request in the background
More Actions, Reference:
https://gt.qq.com/docs.html
Reproduced in: https: //www.jianshu.com/p/64fa59fbebe1