客户端HTTP请求优化实战

一、引言

对每个APP来说，网络请求必不可少，虽然有大把现成的框架能帮助我们轻松的完成这项工作，但是实际考究效果时，会发现经常有用户反应请求很慢，页面刷不出来，菊花转不停等问题，可见其中还是存在不少优化空间的，这篇文章就烫爷在项目中对HTTP请求做的优化，做一个简单的梳理。

二、数据采集

要解决问题，必先分析问题，要分析问题必先采集数据，所以要解决HTTP请求的问题，首先还是要想办法获得相关的数据，进而分析短板，针对性的进行优化。

获得数据的方式有几种，一者可以使用某些第三方sdk，嵌入后就可以在第三方的网站上看到HTTP请求的信息，错误日志等，用起来虽然方便，但我不是特别推荐，因为这些sdk为了获取请求信息，往往对客户端的侵入十分严重，甚至经常会造成一些兼容性问题，影响app本身的稳定性，有时候颇为让人头疼。

烫爷在项目中采用的是自己采集数据的方式，对请求框架再封装一层，采集一个请求的完整信息——

• 请求ID
  给每个请求生成一个唯一的id，可以方便同时在服务器端跟踪这个请求，另外当请求重发时也可以便于服务器处理请求的幂等性
• 请求URL
• 当前时间戳
• 用户ID
• 设备信息
• 当前网络状态
• 请求用时
• 错误原因（如果请求出错）

另外一点需要注意的是，这些信息采集完必须先存放在本地，因为出错的时候网络状态不稳定，很可能当时是无法上报日志的，存在了本地，就可以寻找合适时机上报，不怕丢失信息。

三、错误数据分析

数据采集完了，经过分析发现了几个显著的问题

• 请求错误中有相当大的比例在DNS解析时就已经错了
  一个http请求的全过程简单来说如下

域名解析 --> 发起TCP的3次握手（客户端发起连接请求、服务器允许请求、客户端确认） --> 建立TCP连接后发起http请求 --> 服务器响应http请求

所以域名解析是第一步，这一步出错，后面就无以为继了。很多人会很奇怪，DNS解析这么基础的服务难道还那么不稳定，还经常出错？很不幸，DNS解析就是这么不稳定。

• 应用开启时调用的那几个接口是错误率最高的
  这其实也可以理解，很多安卓手机性能低下，在应用启动时同时多个接口一起请求，造成了系统资源的紧缺，进而导致了错误率变高。

• 网络状态不好时，错误率高
  这是一句废话，但是也应该针对这种情况做一些相应的处理。

四、问题处理

DNS解析问题

dns解析异常的处理也有几种方案，但总体的思路一致，就是既然域名解析异常，那我就不用域名解析了（好光棍的方法）。简单来说有以下几种方案，当然实战时可以几个方案同时使用。

• 使用HTTPDNS之类的技术方案解决
  HTTPDNS说白了就是用HTTP协议进行域名解析，替代现有的基于UDP的DNS协议，避免域名解析失败，域名劫持等问题。

• 客户端和服务器之间保持长连接，使用socket通信
  这在IM、推送sdk、游戏中应用很广

• 本地维护一个ip列表，直接使用ip进行请求，而非用域名，并定期去服务器更新这个列表。
  同时还可以周期性的ping一下列表上的ip，动态选取延迟最小的ip。

实际在项目中我们采用了腾讯的wns服务，wns基本是结合了1，2两种技术手段，起到的效果非常不错。但是这里提一句，wns并非腾讯的主营业务，所以支持度并不好，如果不是在腾讯内部有人，恐怕也很难用好wns，建议去寻找别的类似的第三方服务替代，或者干脆自己实现。

接口优化

• 在业务层面尽量合并接口
  如前所述，在app启动时同时调用多个接口造成了资源挤压，进而导致错误率上升，那我们就有必要在业务层面去推动合并接口。在自己的项目中，烫爷就把启动时调用的7个接口合成了一个接口，一方面减少了客户端的资源调用，降低了错误率，另一方面也减少了对服务器的压力，一举两得。

• 自动重发机制
  由于网络的抖动，接口请求错误不可避免，所以针对某些错误码，进行接口的自动重发，这样虽然实际上不能降低错误率，但却可以有效降低用户体验到的网络错误，对用户体验来说还是很有帮助的。
  自动重发在客户端层面不难做，更多的工作量其实在服务器侧，服务器必须保证接口的幂等性，比如客户发起了一个买入1000元产品的请求，第一次服务器虽然收到了请求，但因为种种原因没有返回客户端，导致客户端又重发了一次请求，此时服务器虽然收到了2次请求，但绝对不能去买2次1000元的产品。

• 针对不同的网络状态动态调整timeout
  这个其实比较好理解，当发现用户是4g或者wifi状态下时，建议把timeout设为12s左右，当检测到用户是在3g甚至2g状态下时，大可以把timeout设为30-50s。因为用户在较差的网络下，是可以容忍较长时间的等待的，但是如果timeout卡死在了12s，可能每个请求都无法在12s内成功，这样无论用户刷新多少次都无济于事了。

其他优化

• 错误页面
  当检测到http出错时，尽量弹出一个设计过的错误页面，这远比页面一片空白要体验友好的多

• 网络检测
  更进一步的话，可以在错误页面做一个网络检测，出一个网络情况的报告，一来可以让用户自己发现问题，二来用户可以直接把这个报告提供给在线客服，加速问题的定位，当然更重要的是让用户觉得我们对这个问题很重视，我们很专业；）

好了，针对客户端HTTP请求的优化，烫爷大概就做了以上的这些尝试，都不算特别高深，但因为效果已经比较显著，也就没有进一步深入研究下去。最后说结果，无论是iOS还是Android，错误率从优化前的2%以上，降低到了0.3%以下，可喜可贺，可喜可贺~