当我们开始关注App的用户体验时，网络的流畅度和界面的流畅度是保证App好用的重要指标。最近在项目中对网络数据进行了简单的分析，并对业界的一些解决方案进行了研究，所以写了这篇文章来梳理一下知识点。我们在使用app的时候，如果经常遇到加载失败或者小圆圈不停的转，很可能是app的网络性能有问题，急需研发同学进行优化。对于开发者来说，定位网络问题是非常困难的，因为出现网络问题的用户往往都在很远的地方，你没有办法去调试和定位。那么建立完善的网络监控体系，通过对海量数据的分析，准确定位网络问题就显得尤为重要。通过数据分析、研究和用户反馈，发现移动网络经常存在以下问题：网络成功率低、请求失败频繁、用户反馈DNS劫持、数据篡改、广告和请求超时等。网络延迟很长，并且有很多长尾数据。数据分析后发现，长期连接的时间明显少于短期连接约100ms（短连接是指通过DNS解析、TCP握手等一系列过程建立连接，和SSL握手。长期连接是指直接多路复用之前的连接通道）网络经常抖动。本来大部分请求都是100ms左右，突然出现一两千毫秒，甚至有10、20秒的延迟。HTTP1.1Head阻塞的存在，一个网络抖动，很容易影响后续的请求，导致一连串的高延迟请求（headofblocking：指的是HTTP1.1，如果发送1,2,3三个网络请求，那么Response2和3的顺序应该在第一个网络请求之后）传输的Payload过大，延迟高，容易超时。苹果需要HTTPS。这个时候，这个时候加入的SSL握手是比较耗时的。针对以上一系列的问题，业界已经有了很多的解决方案，这里我简单罗列一下针对这样的网络的一些解决方案。对于DNS劫持，业界主要的手段是HTTPDNS或者内置的ServerIP列表。客户端直接访问HttpDNS接口获取业务在域名配置管理系统上配置的访问延迟最高的IP。获取IP后，直接向该IP发送服务协议请求。不需要使用本地运营商解析域名，因此从根本上避免了劫持问题，并且可以减少网络延迟，提高连接成功率。ServerIPlist的建立就是在本地缓存一个IP映射表。这个表可以在App启动的时候动态更新，访问服务器的时候可以直接用IP发送请求。传输的Payload也直接影响时延，对成功率有影响。对于数据压缩，业内很多公司都开始使用ProtoBuf协议。优化百分比我没有准确说出数据结论，但是从大家的反馈来看，优化效果是很明显的。对于数据压缩，也可以考虑接入HTTP2.0。毕竟这是一个趋势，很多公司都加入了HTTP2.0。HTTP2.0还可以帮助您通过标头压缩和其他方法减少传输的负载。其实，上面的很多问题都与长线和短线的联系有关。这个问题比较多，可以考虑域名合并：淘宝、美团等公司在规划中都提到了，就是公司原来的很多域名为什么要这样做？HTTP通道多路复用是基于域名的。如果只有几个域名，大部分请求都可以在长连接通道中进行，这样可以减少延迟，提高成功率。尽早建立长连接，让其他业务请求可以复用长连接通道，加快访问速度。对于建立连接的时机，可以考虑很多方面，比如冷启动、前台后台切换、网络切换等。考虑接入HTTP2.0，两者都解决HTTP1.1的blockinghead，减少网络延迟，并提供更强大的多路复用技术，还增加了流量控制、新的二进制格式、ServerPush、请求优先级和依赖等特性。或者连接SPDY，不过目前看来直接在HTTP2.0上建立多通道比较合适。比如携程、美团等公司都有自己的TCP和UDP通道，有多个域名共享通道，成功率三比九。.同时，各大厂商也在尝试新的网络协议，比如QUIC。Facebook也放出了分享，改进QUIC，实现TLS的0-RTT，还有一些其他的点可以考虑加入CDN加速，动静资源分离。对于埋藏的数据，也可以合并请求以减少流量。基于网络状况的App网络诊断，超时时间的动态设置等。
