背景
线上APP有一个下拉刷新的请求，大部分时间下拉刷新很快，偶发性下拉刷新请求接口特别慢，单独请求接口的时候都很快，怀疑是网络波动问题，因此有了这篇文章
一.复现请求慢的情况
二.charles相关知识
1.显示模式
（1） Structure形式如下图 优点：可以很清晰的看到请求的数据结构，而且是以域名划分请求信息的，可以很清晰的去分析和处理数据。
（2）Sequence形式如下图 优点：可以看到全部请求，这里的结果以数据请求的顺序来显示，最新的请求显示在最下面
综上，两种形式各有千秋，structure 适合对单一系列的访问请求从宏观上进行把握，可以快速定位。sequence 适合精确定位内容，因为每条sequence 都有size，status等属性信息，方便快速定位这条结果的价值.
2.相关名词解释
Filter ： 过滤，可以输入关键字来快速筛选出 URL 中带指定关键字的网络请求
Overview ： 查看这次请求的详细内容，例如耗时详细列车了请求开始时间、结束时间，响应开始时间、结束时间，总耗时、DNS耗时、网络延时等。对于Size也详细列出了请求头大小、响应头大小、压缩比例等内容。
URL：进行网络请求的链接；
Status：当前状态，complete表示请求完成；
Responce Code：返回码。不同的接口，不同的请求结果，返回码都不同；
Protocol：使用的协议；
Method：请求方式，如GET请求，POST请求等；
Kept Alive：判断当前是否正在链接（活跃）；
Content-Type：响应的content-type头；
Client Address：客户端的IP地址；
Remote Address：远程服务器的IP；
Timing:
Request Start Time：接收到的第一个请求的第一个字节的时间点
Request End Time：发送到客户端的最后一个响应的最后一个字节的时间
Response Start Time：响应开始时间
Response End Time：响应结束时间
Duration：整个请求响应持续时间。Duration=DNS+Connect+TLS Handshake+Response+Latency（应该是上面的加和）
DNS：所有选中的session解析DNS所花费的时间的总和
Connect：所有选中session建立TCP/IP连接所花费的时间总和
TLS Handshake--TLS协议握手时间
Request：请求耗费时间
Response：响应耗费时间
Latency：网络延迟时间和服务器处理时间
Charles shows a measure of the latency on each request on the Overview tab. Charles calculates latency by measuring the time taken between finishing sending the request and starting to receive the response. Therefore latency includes network latency and server latency, that is the time spent processing the request. For static requests the server is usually able to respond instantly, unless under load, so the latency figure mostly represents the network latency. For dynamic requests, or any request for which the server has to do some work, you can subtract an approximate network latency to determine how long the server spent processing the request. Charles在“概述”选项卡上显示了每个请求的延迟度量。Charles通过测量完成发送请求和开始接收响应之间的时间来计算延迟。因此，延迟包括网络延迟和服务器延迟，即处理请求所花费的时间。 对于静态请求，服务器通常能够即时响应（除非处于负载状态），因此延迟数主要表示网络延迟。 对于动态请求或服务器必须为之执行的任何请求，您可以减去近似的网络延迟来确定服务器处理该请求所花费的时间。Size:
Request Header ：请求的头部大小；
Response Header：返回的头部大小；
Request : 请求发送的大小；
Response：返回数据的大小；
Total：所有数据大小；
Contents ： 查看请求参数和返回数据
Headers：发送请求的头部信息或者返回的头部信息；
Text：请求的参数信息或者返回信息的文本；
Hex：请求的参数或者返回信息的16进制表示；
JavaScript： 以js的形式格式化请求的参数或者返回的参数；
JSON：请求参数或者返回的数据JSON形式展示；
JSONText：请求的信息或者返回的信息格式化成test形式；
Raw：发送的原生数据，包括了Headers和Text；
Summary: 查看发送数据的一些简要信息（主机，状态码，数据的类型，header和body大下，加载时间，总时间）
Chart: Summary中简要信息以图表形式展示
Timeline：时间线。请求上传、处理请求、响应组合的时间线。
Request - the time spent sending (uploading) the request (dark blue) Latency - the time spent waiting for network latency or processing time on the server (mid blue) Response - the time spent receiving (downloading) the response (light blue) 请求-发送（上传）请求所花费的时间（深蓝色）。 延迟-等待网络延迟或服务器上的处理时间所花费的时间（蓝色）。 响应-接收（下载）响应所花费的时间（浅蓝色）。Sizes：响应数据的大小
Duration：与Overview中的Duration值是一样的。不包含请求发送的时间。
Types：返回的格式。application/json
Flow：应该是上传下载速度与耗时的关系？？？
Notes: 其他信息
三.问题分析
1
由上面两张图可以看出，整个请求过程刨除请求发送，耗时441ms。主要耗时在request上面了，由chart--timeline可以清晰的看出来请求时间组成，request占据了大部分的时间，可以推断接口的响应速度还是可以的，更大的可能是网络波动造成的请求时间过长！
站在巨人肩膀上摘苹果
https://www.cnblogs.com/henanleon/p/9902366.html
https://blog.csdn.net/weixin_42139375/article/details/105258019
https://www.jianshu.com/p/2baf3585a4c2
https://www.charlesproxy.com/documentation/using-charles/chart/