安卓入门五十八 网络优化

网络：频繁的网络访问会导致耗电和影响应用的性能；网络交互数据大小会影响网络传输的效率；
对于网络的优化，可以从以下几个方面动手进行：

图片网络优化
比方，针对网络情况，返回差别的图片数据，一种是高清大图，一种是正常图片，一种是缩略小图。当用户处于wifi下给控件设置高清大图，当4g大概3g模式下加载正常图片，当弱网条件下加载缩略图。

网络数据优化
移动端获取网络数据优化可以从以下几点动手：

连接复用：节省连接建立时间，如开启 keep-alive。
对于Android来说默认情况下HttpURLConnection和HttpClient都开启了keep-alive。只是2.2之前HttpURLConnection存在影响连接池的Bug，具体可见：Android HttpURLConnection及HttpClient选择
请求归并：即将多个请求归并为一个进行请求，比力常见的就是网页中的CSS Image Sprites。如果某个页面内请求过多，也可以考虑做肯定的请求归并。
减少请求数据的大小：对于post请求，body可以做gzip压缩的，header也可以做数据压缩。返回数据的body也可以做gzip压缩，body数据体积可以缩小到原来的30%左右。
异常拦截优化
在获取数据的流程中，访问接口和解析数据时都有可能会堕落，我们可以通过拦截器在这两层拦截错误。

在访问接口时，我们不用设置拦截器，因为一旦出现错误，Retrofit会自动抛出异常。比如，常见请求异常404，500，503等等。
在解析数据时，我们设置一个拦截器，判断Result里面的code是否为乐成，如果不乐成，则要根据与服务器约定好的错误码来抛出对应的异常。比如，token失效，禁用同账号登岸多台设备，缺少参数，参数传递异常等等。
网络优化的方向紧张是流量优化、质量优化、线下测试以及线上监控方案，本文对网络优化方面的知识做了一个全面总结，紧张内容如下：

1、网络优化的三个要点
多维
网络优化应该是多维的，流量消耗、网络质量，而不单单只是此中一个方面
精准
在做网络流量统计时，我们要做精准度量，如果只是获取了具体消耗了多少的值，对于我们定位和办理问题是没有太大的资助，因为这个值只能表明用户用了多少流量。
如果线上用户反馈 App 消耗流量较多，但是我们不知道这个用户统共使用了 App 多长时间的话，那就不好定位问题所在，如果用户使用 App 的时间比力长，那消耗流量多一些很可能是正常的。
又比如用户反馈 App 在背景消耗流量比力多，但是我们只统计了整体的值，那就无法断定 App 在背景运行时到底消耗了多少流量。
监控
针对网络优化，我们应该建设全面且完满的网络监控体系，不能只监控一个指标，假如只监控网络请求乐成率，那我们就只能知道用户大概的网络使用情况，这种粗粒度的监控没办法资助我们找出并办理问题的根源。
比如线上用户使用了某个功能使用了 1000 次，然后出现了 1 次异常，而且用户点击重试后就恢复正常了。
如许单从数据上来看的话，网络请求的乐成率还是比力高的，但是只通过乐成率一个值是无法知道这一次异常出现的原因，也就无法避免后续出现这类异常。
2、网络优化的两个维度
流量维度
流量维度是 App 在一段时间内流量消耗的精准度量。
流量消耗大不但对用户有影响，对公司的运营成本也有影响，比如带宽、服务器数量、CDN 等方面的开支，而且网络请求密集对手机耗电量也有肯定的影响。
在流量维度上，我们要做到区分范例、监控异常、上报日记。
区分范例
我们不但要知道用户在某个时间段内的具体流量消耗，还要知道用户在差别网络范例（流量、WiFi）下的流量消耗、区分 App 在前台和在背景时的流量消耗。
只有积聚了差别维度的数据，才能快速断定和办理问题。
监控异常
对于流量统计，我们不但要知道用户的流量消耗均值，还要知道线上用户消耗流量的异常率。
这里的异常分为三种：

• 流量消耗过多
  
• 请求次数过多
  
• 下载文件过大
  

这三个都是我们要注意的异常。
上报日记
最理想的情况，就是我们对所有的网络请求，在当地都有一个完整的监控，每一个请求的 Request 和 Response 相干的所有信息都全部记录下来。
服务端可以下发指令控制客户端上传这些数据，客户端也可以在相干数据凌驾阈值后主动上报。
质量维度
网络请求的质量直接影响了用户的真实体验，如果网络请求速度慢或请求乐成率比力低，都会导致不好的用户体验。
对于网络请求质量的监控，可以从下面几个维度进行区分，以便后续能快速定位和办理问题。

• 请求时长
  
• 请求乐成率
  
• 长尾率(时长>3s的请求乐成的接口占比）
  
• 失败率
  
• Top 失败接口
  
• 长连接传化率（辅助指标）
  
• httpdns转化率（辅助指标）
  

网络优化的两个误区

只关注一个维度

只关注一个维度比如流量消耗大概质量，忽视了其他维度。


忽略个体数据

另有就是做网络监控时只关注均值和整体的数据，忽略了个体的数据。
比如前面提到的请求乐成率的例子，从整体上来看乐成率非常高，但是这种数据无法资助我们改善单次请求。

3、三个线下测试工具
对于线下测试情况，我们要有一个精确的熟悉，线下测试是为了把问题尽可能在上线前暴露出来，在线下测试环节，我们要注意下面 4 点。

• 网络切换
  
• 弱网/无网测试
  
• 请求是否有误
  
• 接口请求是否有误，比如传了过多的参数或传参不精确
  
• 周期长
  

C 端的 App 到了稳定期后，用户可能高达几千万乃至更多，这时 App 功能一般黑白常复杂的，而且包含了其他功能，比如性能监控等。
这些功能的网络请求每每不是实时上报的，所以我们在做流量消耗测试的时间，周期一般会很长，不能只是简朴测 10 分钟。
我们要确保我们的 App 在切换网络、弱网或无网时做到下面这两点。

• 不能中断流程
  有的 App 对安全性要求比力高，如果突然切换网络状态，会导致用户的登录态失效，也就是要用户重新登录。
  这时我们要注意重新登录后 App 会不会重新回到之前的流程中，不能中断用户正在进行的流程。
  
• 关闭加载弹窗
  而且在弱网或无网状态下，肯定要测试 Loading 弹窗是否会停止，如果不注意的话，在无网的情况下，应用的请求失败了，但是却没有关闭 Loading 弹窗，影响了用户的其他操作。
  如果对无网状态器重不敷，就测不出如许的 Bug 。
  

下面我们来看 3 个常用的线下测试工具：

• Network Profiler（在最新版本的Android Studio Flamingo中是Network Inspector，位于App Inspection下面）
  
• Charles
  
• Stetho
  

3.1 Network Profiler(Network Inspector)
Network Profiler(Network Inspector) 是 AS 自带的网络分析工具，它能显示实时网络活动，比如发送网络请求、继承的数据以及连接数等。
这里笔者使用的是Android Studio Flamingo，所以这里先容的是Network Inspector。
Network Inspector 会在时间轴上显示实时网络活动，包罗发送和吸取的数据。Network Inspector 便于您检查应用传输数据的方式和时间，并适当优化底层代码。
1、在 Android Studio 导航栏中，依次选择 View > Tool Windows > App Inspection。在应用检查窗口自动连接到应用进程后，从标签页中选择 Network Inspector
可以看到连接视图（Connection View），右侧则是某个连接的信息，包罗请求时间、响应、请求以及调用栈

线程视图，显示应用的每个 CPU 线程的网络活动，你可以在此视图中检查各网络请求由哪些线程负责。

规则视图，Rules 有助于测试应用在遇到差别状态代码、标头和正文等响应时的行为方式

在 Response 部分，可以在将响应发送到应用之前对其进行修改，比方可以将规则设置为对具有特定状态代码的响应执行并修改该状态代码。

修改 header
在 Header rules 部分中，可以创建多个子规则来添加或修改响应中的标头。
当创建多个标题规则时，使用规则表顶部的向上和向下箭头来更改标题规则的次序，该次序会影响修改后的响应标头，因为标头规则是按照它们列出的次序应用的。
可以通过点击 Header rules 部分中的 + 添加规则，然后在 Add new header 部分中输入标题的名称和值 。

要修改 header ，可以在 Edit existing header 选项卡里指定要查找的 header 名称或值，输入要替换的header 名称或值。

请求信息

响应信息

调用栈

Charles和Stetho这里就不先容了，有爱好的可以自己去了解
4、 线上监控的三个要点
在看获取网络流量前，我们先来看下线上监控的三个要点：服务端监控、客户端监控以及异常监控。
2.1 服务端监控
耗时统计维度
对于服务端的监控，我们要注意请求的耗时，而且耗时要分多个维度区分。

失败率
服务端要统计失败率：
请求失败
业务失败
业务相干的失败也是失败，比如网络请求确实乐成了，但是用户没有拿到自己需要的数据，对于失败率的统计要全面，如许衡量的指标才能更敏锐地感知线上的异常颠簸；
Top 失败接口
同时在 APM 背景，我们最好统计一下一段时间内，比如 1 天或 1 周内，排行 Top 的失败接口或异常接口，每隔一段时间就进行一次统计，如许就能知道哪些接口不稳定，以便进行针对性的优化。

• 长尾率
  请求时长凌驾3s的接口占比
  
• 长连接转化率
  走长连接的接口占比
  
• httpdns的转化率
  走 httpdns的接口占比
  

2.2 客户端监控
客户端监控比服务端监控更关键，在客户端的监控则更全面，能拿到更多的数据。
我们要在线上监控的数据包罗请求具体耗时、乐成率、错误码以及图片加载每一步的耗时。
虽然图片加载耗时和乐成率在服务端也是可以统计的，但是服务端拿到的数据不完整等，因为很多请求压根没有到服务端就失败了。
而且服务端传过来的数据加上网络通道的耽误时间，肯定比服务端统计到的时间要长，所以我们要在客户端也加上统计。
API 监控
客户端能拿到请求的每一个步调的信息，包罗 DNS 解析时间、建立连接的时间、请求时间以及网络包大小等信息。
同时我们可以记录用户每一次网络请求的操作，比如具体请求了哪些接口，请求是否乐成以及失败的原因，这些信息我们都能作为监控的基础信息传给 APM 服务端，在反面会先容怎样监控网络请求的每一步。
2. 图片监控
同时还要注意做图片监控，一张图片消耗的流量可能比 5 个乃至更多接口的数据还要多。
3. 网络容灾机制
假如某一天我们的用户量突然暴涨，按服务器可能是扛不住这个压力的，对于服务端来说，可以用备用服务器分流，避免把主服务器搞垮。
而我们客户端也可以做一个战略，就是在肯定时间内，网络请求失败了多次时，就不再进行网络请求。
3.2 异常监控
异常监控的目的，是提升我们对异常的感知敏捷度，而不是被动等候用户反馈。
服务器防刷
在服务端，我们要判断是不是有人在刷我们的服务器，也就是恶意攻击，如果检测到有人在刷服务器，我们可以锁定 IP 拒绝这些 IP 访问。
2. 异常兜底
在客户端，我们可以加上主动预警能力，比如我们下载了一个凌驾设定值的文件，客户端在下载后就可以把这个效果上报给服务器，表明现在遇到了异常，需要研发同砚进一步确认。
在一些场景下，服务端可能出现流量过多扛不住的情况，这时客户端可以做一个兜底战略，如果在肯定时间内，比如 30 秒内，接口请求连续失败 5 次，那就不允许持续访问，同时把重试时间设长一些。
3. 单点问题追查
假如线上用户反馈 App 消耗流量过多，大概是在背景时消耗流量较多，我们都可以具体分析用户下的网络请求日记，以及下发下令查看具体时间段的流量消耗。
5. 三个线上监控方案
有的问题只在线上出现，在线下发现不了，比如在线下测试某个版本的时间，H5 包不肯定是新版本，但是到了线上后，部分用户可能会被命中，然后下发了新版本的包。
而这些包如果没有颠末压缩，如许的异常就无法在线下的测试情况中全部发现，只能通过线上监控发现。
下面我们来看下三个线上监控方案：

这三个方案中 OkHttp 变乱监听器能获取到的数据最过细，也最实用，而 NetworkStatsManager 和 TrafficStats 紧张是用于获取流量消耗。
5.1 OkHttp 变乱监听器
5.1.1 自定义变乱监听器
结合 OkHttp 获取网络请求质量数据，OkHttp 给我们留了一个变乱监听器 EventListener 回调，我们可以自己实现这个监听器，监听每一次的请求。
5.1.2 自定义 GlideModule
自定义 GlideModue 是为了监控图片加载的过程，下面我们来看下怎么监控 Glide 加载图片过程的耗时和相干数据。
5.1.3 OkHttp 最大并发请求数
关于请求的频率，我们可以看下 OkHttp 默认的请求池，在 OkHttp 的 Dispatcher 分发器中，有一个 executeService 线程池，它的核心池大小为 0 ，最大值是整型的最大值。
但这并不是意味着通过 OkHttp 发送的网络请求可以并发无数个，对于 IO 密集型使命我们可以多发送一些，因为这类使命对 CPU 消耗不大，但是我们还是要注意，单个 App 能创建的线程数也是有上限的。
5.1.4 区分前背景流量
之所以要在日记中区分前背景流量，是因为很多用户会担心 App 一直在背景消耗流量，如果粗粒度地只获取流量数据，是不知道这些流量有多少是 App 在背景运行时消耗的，如许的话不要说办理用户反馈的问题，就连定位问题都定位不了。
5.1.5 四步上传数据
下面是上报性能日记的大概的四个步调。

• 背景使命
  
• 在 App 启动时，执行一个背景使命；
  
• 间隔统计
  
• 这个使命每隔一段时间（如 30 秒内）就获取网络数据；
  
• 自定数据
  
• 自己维护一份数据统计，给数据加上标记，记住用户在前背景的流量消耗总量；
  
• 上报数据
  
• 在符合的机会（如用户反馈、达到阈值、处于 WiFi 网络下）把数据上报到 APM 背景，如许对用户的流量就不会造成影响，而且数据也能作为流量治理依据；
  

5.2 NetworkStatsManager
NetworkStatsManager 是 API 23 后的流量统计管理器，它可以获取某个时段的流量信息，也可以获取差别网络范例下的流量消耗，它最大的不敷就是用户体验比力差，需要用户开启“查看使用情况”权限。
下面是一些使用网络或对流量的消耗比力多的场景。

5.2.1 流量优化的三个要点
在讲怎么用 NetworkStatsManager 获取流量消耗前，我们要先了解下流量优化的三个要点。
不能只看绝对值
绝对值不能作为流量消耗偏高的唯一统计标准，不能说 App 消耗了 10M 的流量，那就要立即去优化。
绝对值的对比是没有意义的，比如用了 App 30 分钟，欣赏了很多的商品或视频，那用了 10M 可能已经算少了。
对比竞品
那要以什么为标准呢？我们最好是对比竞品，对比两个 App 在相同的场景下的流量消耗。
比如和竞品一起跑一个发布评论的主流程，这里要注意，要保证两个 App 发布的评论是相同的，而且图片也是相同的，以保证变量是唯一的。
如许对比一下，如果我们和竞品的流量消耗差距比力大，那我们对流量优化的步伐，就应该加快一些，这个绝对值跟竞品的对比，应该结合使用。
设定预期
我们要判断一下新上功能的流量消耗，比如我们要预期是用户使用新功能后，单次消耗流量应该为 300K 左右，但是上线后凌驾了 300K 时，我们就要确认下流量消耗是否偏高。
6. 三个流量优化方案
6.1 数据缓存
6.1.1 OkHttp 缓存
如果我们细致跟一下自己项目中的接口，就会发现很多对实时性没有那么高要求的接口，使用缓存不但可以节约流量，而且能大幅提升数据访问速度。
我们常用的网络库，比如 OkHttp 和 Volley，都有比力好的缓存实践。
而且没做缓存对用户体验也不好，一般的 App 会在打开后显示一个无数据的界面，和展示上一次的数据相比，这个用户体验实在是比力差的。
6.1.2 逾期时间与增量更新
逾期时间
在服务端返回的数据中加上一个逾期时间，如许我们每次请求的时间判断一下有没有逾期，如果没有逾期就不需要去重新请求。
增量更新
数据增量更新的具体思路，就是在数据中加上一个版本的概念，每次吸取数据都进行版本对比，只吸取有变化的数据。
如许传输的数据量就会减少很多，比如省市区和配置等数据比力少更新，如果每次都要请求省市区的数据，这就是在浪费流量。
6.2 数据压缩
Gzip
对于 Post 请求，Body 是用 Gzip 压缩的，也就是请求的时间带上 Gzip 请求头，服务端返回的时间也加上 Gzip 压缩，如许数据流就是被压缩过的。
2. 压缩请求头
请求头也占用肯定的体积，在请求头不变的情况下，我们可以只传递一次，以后都只需要传递上一次请求头的 MD5 值，服务端做一个缓存，在需要请求头中的某些信息时，就可以直接从之前的缓存中取。
3. 归并网络请求
每一个网络请求都会有冗余信息，比如请求头，而归并网络请求就可以减少冗余信息的传递；
6.3 图片压缩
缩略图
图片压缩的第一个本领，就是在列表中优先使用缩略图，因为展示原图会加大内存消耗和流量消耗，而且在列表中直接展示原图没有意义。
下面是原图和缩略图的对比大小，缩略图尺寸为原图的 50%，大小为原图的 10%。

2. WebP
图片压缩的第二个本领，就是使用 Webp 格式，下面是同一张图片在 PNG 格式和 WebP 格式下的对比，WebP 格式的大小为 PNG 格式的 51%。

3. Luban
比如我们在上传图片的时间，做一个压缩比如在当地是一个 2M 的图片，完整地上传上去意义不大，只会增长我们的流量消耗，最好是压缩后再上传。
下面这张图片的原始大小为 1.6M，压缩后变成了 213KB，体积为原始大小的 13%。

7. 网络请求质量优化
在前面我们学习了网络请求流量优化，但是实际上，对用户体验粉碎最大的是网络请求质量差，很多同砚忽略了这点。
因为我们一般在开发或测试阶段，都是在公司用 WiFi 测试，网络质量比力好，假设我们的 App 在流量消耗上问题不大，但是用户经常反馈界面打不开、打开慢、图片加载不出来等问题。
这时用户很有可能会卸载我们的 App ，转向竞品，只有在网络请求质量高，用户体验好，继续使用我们的 App 时，用户才有可能遇到流量消耗的问题，所以网络质量优化比流量优化更关键。
网络质量优化的两个指标：

这两个指标都会影响用户体验，在先容网络请求质量优化前，我们先来看下一个 Http 请求的过程。

一个网络请求可以简朴分为连接服务器 -> 获取数据两个部分。
此中连接服务器前还包罗 DNS 解析的过程；获取数据后可能会对数据进行缓存。
7.1质量优化方向
连接服务器优化战略
7.1.1 HttpDNS
首先来看怎么在发出请求这一步上优化，网络请求乐成率与速度一上来就受 DNS 服务器的影响，如果我们的 DNS 解析到 IP 所在的过程被挟制或 DNS 解析慢，都会严重影响用户体验。
DNS 被挟制的效果就是用户得到的数据并不是我们真实想要提供给用户的数据，如果 DNS 解析慢，那用户等候的请求时间就会变长。
所以 DNS 优化是网络质量优化的第一步，我们使用 HttpDNS，绕过运营商域名解析过程，HttpDNS 不是使用传统的 DNS 协议，向 DNS 服务器的 53 端口发送请求，而是使用 Http 协议，向服务器的 80 端口发送请求。
如许做的好处有两个：

腾讯云和阿里云都提供了 HttpDNS 服务，具体的实现可能看他们的官方文档。
不用域名，用 IP 直连
省去 DNS 解析过程，DNS 全名 Domain Name System，解析意指根据域名得到其对应的 IP 所在。
如 www.codekk.com 的域名解析效果就是 104.236.147.76。
初次域名解析一般需要几百毫秒，可通过直接向 IP 而非域名请求，节省掉这部分时间，同时可以防备域名挟制等带来的风险。
固然为了安全和扩展考虑，这个 IP 可能是一个动态更新的 IP 列表，并在 IP 不可用情况下通过域名访问。
服务器合理部署
服务器多运营商多地部署，一般至少含三大运营商、南中北三地部署。
配合上面说到的动态 IP 列表，支持优先级，每次根据地域、网络范例等选择最优的服务器 IP 进行连接。
对于服务器端还可以调优服务器的 TCP 拥塞窗口大小、重传超时时间(RTO)、最大传输单元(MTU)等。
7.1.2 Http 协议版本优化
刚刚说到了网络请求的第二步是创建连接，当中涉及 TCP 三次握手，这个过程是比力长的，如果每次请求都要走三次握手，那这个效率是比力低的。
所以 Http 的差别版本对这点的优化也非常多，下面是 Http 协议差别版本之间的紧张区别。
Http 1.0
较老的版本，现在已经很少见到用这个版本的服务了，它最大的缺点就是 TCP 连接不复用，每个 TCP 连接只能发送 1 个请求，如果要请求别的资源，就必须重新建立一个连接。
TCP 创建连接的成本非常高，需要三次握手，并且在开始阶段发送速度比力慢，也就是 Http 1.0 的性能非常差。
Http 1.1
Http 1.1 的出现只比 1.0 晚了半年，它最大的变化就是引入了恒久连接，从这个版本开始，是默认不关闭的，可以被多个网络请求复用，如许效率就有了很大的提升。
它还是有些缺陷，就是它虽然允许 TCP 复用，但是同一个 TCP 连接里面的所有数据通讯必须按次序来，也就是处理处罚完一个请求后，再响应下一个请求。
如果前面的网络请求比力慢，那反面的请求也只能等着。
Http 2.0
Http 2.0 是一个二进制协议，它最大的改进就是客户端和服务端可以同时发送多个请求和响应，不需要像 Http 1.1 一样按次序请求，是一个双向的实时通讯。
这点是 Http 2.0 相对于 Http 1.1 的最大的改进，各人以后要跟服务端配合时，有得选的前提下，尽可能选择高版本的 Http 协议。
使用qiuc协议
QUIC(Quick UDP Internet Connection)是谷歌推出的一套基于UDP的传输协议，它实现了TCP + HTTPS + HTTP/2的功能，目的是保证可靠性的同时降低网络耽误。因为UDP是一个简朴传输协议，基于UDP可以摆脱TCP传输确认、重传慢启动等因素，建立安全连接只需要一的个往返时间，它还实现了HTTP/2多路复用、头部压缩等功能。
众所周知UDP比TCP传输速度快，TCP是可靠协议，但是代价是双方确认数据而衍生的一系列消耗。其次TCP是系统内核实现的，如果升级TCP协议，就得让用户升级系统，这个的门槛比力高，而QUIC在UDP基础上由客户端自由发挥，只要有服务器能对接就可以。
7.1.3 资本优化
最后一个优化方案就是砸钱，常见的本领有 CDN 加快、提高带宽、动静资源分离。
各人需要注意，使用 CDN 后，如果某个资源需要更新，更新完成后是需要清理缓存的，这些优化不涉及客户端，同时也不要忘了减少传输量，注意请求的机会和频率，这一条和我们前面讲到的流量优化相干。
获取数据优化战略
连接复用
节省连接建立时间，如开启 keep-alive。
对于 Android 来说默认情况下 HttpURLConnection 和 HttpClient 都开启了 keep-alive。只是 2.2 之前 HttpURLConnection 存在影响连接池的 Bug，具体可见：http://www.trinea.cn/android/android-http-api-compare/
请求归并
即将多个请求归并为一个进行请求，比力常见的就是网页中的 CSS Image Sprites。
如果某个页面内请求过多，也可以考虑做肯定的请求归并，使用bff请求方式。
减小请求数据大小
(1) 对于 POST 请求，Body 可以做 Gzip 压缩，如日记。
(2) 对请求头进行压缩
这个 Http 1.1 不支持，SPDY 及 Http 2.0 支持。
Http 1.1 可以通过服务端对前一个请求的请求头进行缓存，反面相同请求头用 md5 之类的 id 来表现即可。
CDN 缓存静态资源
缓存常见的图片、JS、CSS 等静态资源。
减小返回数据大小
(1) 压缩
一般 API 数据使用 Gzip 压缩，下图是之前测试的 Gzip 压缩前后对比图。

(2) 精简数据格式
如 JSON 代替 XML，WebP 代替其他图片格式。
(3) 对于差别的设备差别网络返回差别的内容
如差别分辨率图片大小。
(4) 增量更新
需要数据更新时，可考虑增量更新。如常见的服务端进行 bsdiff，客户端进行 bspatch。
(5) 大文件下载
支持断点续传，并缓存 Http Resonse 的 ETag 标识，下次请求时带上，从而确定是否数据改变过，未改变则直接返回 304。
数据缓存
缓存获取到的数据，在肯定的有效时间内再次请求可以直接从缓存读取数据。
关于 Http 缓存规则 Grumoon 在 Volley 源码解析最后杂谈中有详细先容，可见：
http://codekk.com/blogs/detail/54cfab086c4761e5001b2542
其他优化本领
这类优化方式在性能优化系列总篇中已经有过完整先容
预取
包罗预连接、预取数据。
分优先级、耽误部分请求
将不紧张的请求耽误，如许既可以削峰减少并发、又可以和反面类似的请求做归并。
多连接
对于较大文件，如大图片、文件下载可考虑多连接。
需要控制请求的最大并发量，毕竟移动端网络受限。

• 细分网络请求的各个阶段的耗时，对比力耗时的阶段进行优化
  
• 优化网络拦截器，对耗时的拦截器进行优化
  
• 优化Top失败接口
  
• 走socket长连接，提高接口走长连接的转化率
  
• 提高接口httpdns的转化率
  
• 针对特定业务进行接口优化
  
• 考虑IPV4和IPV6下的接口情况
  
• 考虑前台和背景接口的乐成率和时延
  

App网络优化全方位指南：流量、质量与监控-CSDN博客 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。