客户端HTTP请求优化实战

转自 https://zhuanlan.zhihu.com/p/31927387

一、引言

对每个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%以下,可喜可贺,可喜可贺~

发布了206 篇原创文章 · 获赞 68 · 访问量 6万+

猜你喜欢

转载自blog.csdn.net/u013728021/article/details/102819646