标签:
目前针对公司Android端的SDK进行实际测试,反映出存在网络加载资源缓慢的问题,在知晓目前CDN的可能存在不稳定的情况下,针对sdk本身的网络模块进行了相应的分析,整理出相关的测试记录,帮助后期可以做出的优化。
如下图所示,根据广告请求AD返回成功后,才会执行下载资广告资源的任务,这里是同步。而当服务器返回AD数据以后,发起多线程异步下载广告资源的任务。只有当一次视频广告所需的全部资源全部下载成功时,才会进入广告的播放显示流程。
简单的理解就是,多个下载任务是并发的,对内容的获取是异步的。
一般来说,客户端从服务端请求获取数据,缓存数据内容,最终按不同形式呈现出来。所以对资源的加载简单地分为下面两个环节:
* 数据获取:也就是发送请求给服务器返回相应的数据。
* 内容解析:对服务器返回的不同数据类型,在设备上缓存的文件形式,对应其不同的解析方式。
通过手机端设置代理方式,借助Fiddler对手机端的网络数据进行抓包分析。下面是针对SDK项目的demo程序来进行数据抓包分析:
可以看出,针对一次完成的视频广告请求,一共是发起6次网络请求的任务,与上面描述的内容一致,下面针对这些任务的实际执行情况和相应的数据指标来进行分析。
通过分析请求AD任务的整体耗时分布,发现耗时主要是在进行DNS解析和TCP握手连接两个方面。
针对上面两点通常的优化有下面几种方式:
1.采用IP直连的方式,避免需要把域名通过DNS服务器解析得到IP地址这个耗时过程;
2.同时考虑到CDN分布式部署情况,域名解析到的IP地址并不一定,增加DNS缓存的设置;
将域名和从DNS服务器解析得到的IP地址保存在DNS缓存中。当下一次再使用这个域名时,就直接从DNS缓存里获得所需的信息,而无需再访问DNS服务器。
3.建立TCP/IP可靠连接,是需要三次握手协议,每次请求都重复这个建立连接的过程,无疑是非常耗时的,考虑下面的方式:
请求合并,对数据量小而零散请求都一次集中执行完毕,类似的请求做合并;
分优先级、延迟部分请求,将不重要的请求延迟,削峰减少并发;
连接复用,不需要每次都通过“三次握手:建立一个新连接,再通过“四次挥手”来关闭连接;
整个请求的TimeLine
请求头和响应头
请求和响应的内容:
所占的比例
通过上面的数据表现,考虑对网络传输的数据进行一下处理:
减小请求数据大小
1.对于 POST 请求,Body 可以做 Gzip 压缩
2.对请求头进行压缩,Http 1.1 不支持,可以进行SPDY改造后支持, Http 2.0 原生支持。
Http 1.1 可以通过服务端对前一个请求的请求头进行缓存,后面相同请求头用 md5 之类的 id 来表示即可。
减小返回数据大小
通常一般对网络数据优化的措施是:
(1) 对返回的内容数据使用 Gzip 压缩
(2) 精简数据格式如 JSON 代替 XML,WebP 代替其他图片格式
(3) 对于不同的设备不同网络返回不同的内容,如不同分辨率图片
(4) 增量更新需要数据更新时,可考虑数据增量更新。如常见的服务端进行 bsdiff,客户端进行 bspatch。
(5) 大文件下载支持断点续传和多线程下载,并缓存 Http Resonse 的 ETag 标识,下次请求时带上,从而确定是否数据改变过,未改变则直接返回 304。
下图是对比Json数据使用 Gzip 压缩前后对比图
返回内容开启 Gzip压缩前
开启Gzip压缩后
对比发现,开启Gzip后可以减少57.3%的数据传输量
需要控制请求的最大并发量,毕竟移动端网络受限
增加网络性能的监控,毕竟优化需要通过数据对比才能看出效果,所以监控系统必不可少,通过前后端的数据监控确定调优效果。
标签:
原文地址:http://blog.csdn.net/u012963909/article/details/51204467