移动APP网络问题以及优化方案

发布时间:2025-05-01 点击:10
当我们开始关注 app 的用户体验后,网络通畅性和界面的流畅性是保证 app 好用的重要指标。近期对项目中的网络数据进行了简单的分析,又对业界的一些方案做了调研,故写此文做一下知识梳理。
在使用 app 时,如经常遇到加载失败或者小圈转个不停的情况,那么很可能 app 的网络性能出现了问题,急需研发同学来进行优化。而对于开发人员来说,定位网络问题又是十分艰难,因为出现网络问题的用户往往遥在天边,你没办法进行调试定位。那么建立完善的网络监控体系就显得十分重要,通过海量数据的分析来对网络问题精确定位。
通过对数据的分析以及调研、用户反馈,发现移动端网络常常存在如下的问题:
网络成功率低,经常请求失败; 用户反馈 dns 劫持,数据被篡改,出现广告和请求超时等情况; 网络延迟较长,且存在较多的长尾数据; 经过数据分析,发现长连的时间明显比短连的时间少 100ms 左右(短连指的是,经过dns解析、tcp 握手、 ssl 握手等一系列的过程建立连接,长连指的是直接复用前者的连接通道); 网络经常出现抖动,本来大部分请求都是 100ms 左右,突然冒出来一两千毫秒的,甚至有10、20秒的延迟情况 http 1.1 的 head of blocking 情况存在,一个网络抖动,很容易影响后续的请求,导致一连串的延迟较高请求(head of blocking:指的是在 http 1.1 中,如果你发出1、2、3 三个网络请求,那么 response 的顺序 2、3 要在第一个网络请求之后); 传输的 payload 太大,延迟高,易超时; 苹果要求https ,此时加入的 ssl 握手较耗时。针对上面一系列的问题,业界已经有很多解决方案,我在这里简单列举一些。
面对这样的网络,如何解决?对于 dns 劫持的情况,业界的主要做法是 httpdns 或者内置 server ip 列表。客户端直接访问 httpdns 接口,获取业务在域名配置管理系统上配置的访问延迟最优的ip,获取到ip后就直接往此ip发送业务协议请求,不需要使用本地运营商解析域名,所以从根本避免了劫持问题,同时可以降低网络延迟,提高连接成功率。而建立 server ip 列表,是在本地缓存一个 ip 的映射表,此表可在app启动时动态下发更新,访问服务器时直接拿出 ip 发出请求。
传输的 payload 也直接影响了延迟,并且对成功率有影响,对于数据的压缩,业界很多公司已经开始使用 protobuf 协议,对于优化的百分比我还没有准确的说数据结论,但是从大家的反馈来说,优化效果明显。对于数据的压缩,还可以考虑接入 http 2.0,毕竟这是一个趋势,也有较多公司已经加入 http 2.0,http 2.0 通过头部压缩等方式也帮你减小了传输的 payload。
上面的问题其实很多是涉及到长连与短连的问题,对这个问题有较多的问题可以考虑。
域名合并:淘宝、美团等公司公布的方案中都有提到,就是将公司原来很多域名的情况,合并为较少的几个域名,为什么这么做呢?http 的通道复用是基于域名划分的,如果域名只有几个,那么多数请求都可以在长连接通道进行,这样就可以降低延迟、增加成功率; 尽早建立长连接,这样其他的业务请求就可以复用长连接通道,加快访问速度。对于建立连接的时机,可以考虑多个方面,比如冷启动,前后台切换、网络切换等; 考虑接入 http2.0,他们两个都解决了 http 1.1 的head of blocking,降低了网络延迟,提供了更强大的多路复用技术,还加入了流量控制、新的二进制格式、server push、请求优先级和依赖等特性。或者接入 spdy ,但是目前觉得好像直接上 http 2.0 比较合适; 建立多通道,比如携程、美团等公司都有自己tcp、udp通道,具有多域名共用通道,成功率三个九等诱人的功效。同时各大厂也对新的网络协议,比如 quic,进行尝试。facebook还出一分享,对 quic 改进,实现 tls 的 0-rtt。再者还有一些其他可以考虑的点:
加入 cdn 加速,动静资源分离; 对于埋点的数据,也可以合并请求,减少流量; app 网络诊断; 根据网络情况,动态设置超时时间等。

网络公司培训客户维护网站操作人员
网站托管的网站页脚怎么设计
行业动态视频网站自制剧艺术创作的泛娱乐化表现
网站客户端的演进
百度智能小程序转化率提升成交转化
行业变革趋势下,网站推广的生存之道
微信营销如何获取有效流量
中国SEO揭开百度快照神秘面纱 分析影响其的因素所在