目前针对公司Android端的SDK进行实际测试，反映出存在网络加载资源缓慢的问题，在知晓目前CDN的可能存在不稳定的情况下，针对sdk本身的网络模块进行了相应的分析，整理出相关的测试记录，帮助后期可以做出的优化。
典型的HTTP请求流程说明：
发起一次完整的视频广告请求包括：
- 根据广告位请求Ad内容
- 下载广告视频截图
- 下载Logo角标请求
- 下载插屏页模板Temp资源
- 下载广告视频的video文件
- 下载插屏页html的source资源
如下图所示，根据广告请求AD返回成功后，才会执行下载资广告资源的任务，这里是同步。而当服务器返回AD数据以后，发起多线程异步下载广告资源的任务。只有当一次视频广告所需的全部资源全部下载成功时，才会进入广告的播放显示流程。
简单的理解就是，多个下载任务是并发的，对内容的获取是异步的。
数据获取和内容解析
一般来说，客户端从服务端请求获取数据，缓存数据内容，最终按不同形式呈现出来。所以对资源的加载简单地分为下面两个环节：
- 数据获取：也就是发送请求给服务器返回相应的数据。
- 内容解析：对服务器返回的不同数据类型，在设备上缓存的文件形式，对应其不同的解析方式。
网络任务分析
通过手机端设置代理方式，借助Fiddler对手机端的网络数据进行抓包分析。下面是针对SDK项目的demo程序来进行数据抓包分析：
可以看出，针对一次完成的视频广告请求，一共是发起6次网络请求的任务，与上面描述的内容一致，下面针对这些任务的实际执行情况和相应的数据指标来进行分析。
网络任务耗时分析：（公司网络环境下根据广告位请求AD）
通过分析请求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%的数据传输量
网络任务优化措施
- 考虑预取包括预连接、预加载数据。
- 使用HttpUrlConnection替换目前的HttpClient，可以具有默认的Gzip压缩和连接复用实现
- DNS优化，确定IP直连和DNS缓存两者结合的方式
- 多连接下载，对于较大文件，如大图片、文件下载可考虑多连接下载
需要控制请求的最大并发量，毕竟移动端网络受限
- 增加网络性能的监控，毕竟优化需要通过数据对比才能看出效果，所以监控系统必不可少，通过前后端的数据监控确定调优效果。
