手机APP端网络常见问题及优化对策

当我们开始关注的时候App在用户体验后，保证了网络通畅性和界面流畅性App易于使用的重要指标。最近对项目中的网络数据进行了简单的分析，并对行业中的一些方案进行了研究，所以这篇文章来梳理知识。

当我们使用App如果经常遇到加载失败或小圈不停的情况，那么很有可能App网络性能存在问题，迫切需要研发学生进行优化。对于开发人员来说，定位网络问题非常困难，因为网络问题的用户往往很遥远，你无法调试定位。因此，建立一个完善的网络监控系统是非常重要的，通过大量的数据分析来准确定位网络问题。

通过对数据的分析、研究和用户反馈，找到手机APP移动终端网络存在以下问题：

• 网络成功率低，经常要求失败

• 用户反馈DNS劫持、篡改数据、超时广告和要求

• 网络延迟较长，长尾数据较多

• 经数据分析，发现长连时间明显少于短连时间ms左右(短连指路过DNS解析、TCP握手、SSL握手等一系列过程建立连接，长连是指直接重用前者的连接通道)

• 网络经常抖动，大部分要求都是100ms突然出现一两千毫秒，甚至有10、20秒的延迟

• HTTP1.1的headofblocking存在网络抖动，容易影响后续请求，导致一系列延迟较高请求(headofblocking：指的是在HTTP1.如果如果您发出1、2、3个网络请求，那么Response第一个网络请求后，顺序2和3)

• 传输的Payload太大，延迟高，容易超时

• 苹果要求HTTPS，此时加入的SSL握手较耗时

针对上述一系列问题，业内有很多解决方案，我在这里简单列举一些

如何解决这样的网络？

对于DNS劫持的情况，业界的主要做法是HTTPDNS或者内置ServerIP列表。直接访问客户端HttpDNS在域名配置管理系统理系统中业务配置的最佳访问延迟IP，获取到IP然后直接去这里IP发送业务协议请求，不需要使用当地运营商分析域名，从根本上避免劫持问题，减少网络延迟，提高连接成功率。并建立它ServerIP本地缓存列表IP此表可在的映射表App启动时动态发布更新，访问服务器时直接取出IP发出请求。

传输的Payload也直接影响延迟，影响成功率。业内很多公司已经开始使用数据压缩ProtoBuf协议，对于优化的百分比，我还没有准确地说出数据结论，但从每个人的反馈来看，优化效果是明显的。也可以考虑访问数据的压缩HTTP2.毕竟这是一种趋势，已经有很多公司加入HTTP2.0，HTTP2.头部压缩也可以帮助你减少传输Payload。

事实上，上述许多问题涉及长连和短连，可以考虑更多的问题

• 域名合并:淘宝、美团等公司公布的计划中都提到，公司原有的域名很多，合并的域名很少。为什么这么做？HTTP渠道重用是基于域名划分的。如果域名只有几个，则可以在长连接通道中执行大部分请求，以减少延迟，提高成功率。

• 尽快建立长连接，使其他业务要求能够重复使用长连接通道，加快访问速度。对于建立连接的时间，可以考虑冷启动、前后台切换、网络切换等多个方面

• 考虑接入HTTP2.他们俩都解决了HTTP1.1的headofblocking，减少网络延迟，提供更强大的多路复用技术，增加流量控制，新的二进制格式，ServerPush、请求优先级和依赖性。或访问SPDY，但目前感觉好像是直接的HTTP2.0比较合适

• 携程、美团等公司都有自己的多渠道TCP、UDP该通道具有多域名共用通道、三个九级成功率等诱人功效。与此同时，各大厂商也对新的网络协议，如QUIC，进行尝试。Facebook分享，对QUIC改进，实现TLS的0-RTT

再者还有一些其他可以考虑的点

• 加入CDN加速，动静资源分离

• 还可以合并要求埋点数据，减少流量

• App网络诊断

• 动态设置超时间等。根据网络情况