如果需要下载 5 秒数据才可以播的话，肯定是非常慢的。我们这里的策略会采用 FFmpeg Based Player 自己来做解码，要关注兼容性和耗电的问题。解决了 Mdata 之后，如果 MOOV 数据在头部，拿关键信息进行播放的话，其实需要的开始播放数据量是非常小的。

　　对于下载优化，会有一个防盗链的请求，通过 HTTP 拿到真实的播放 URL 才可以下载数据。

　　但是在手机上执行 HTTP 请求非常耗时，这里走私有长连接通道做这个事情。

　　关于优化下载链路，这里也是谈的比较多的，一般也是直接输出 IP 地址，利用 IP 地址做跑马的策略，兼顾性能的效率，这个是用的比较多的方式。

　　进一步思考，按照普遍 600K 码率的话，我们统计到现在 APP 上面下载的平均速度是 400K 左右，这样计算的话，可能在安卓上面播放一个视频的话，需要将近 0.9 秒左右才可以下载到你需要的数据。

　　如果码率再进一步提升的话，可能会更大，这其实我们也做了一些场景分析，会发现我们是社交网站，它有好友动态，视频在好友动态里播放，或者是在视频浮层里播放，我们的选择是预加载的策略，这也是常见的策略。

　　我们会在当前看这条动态时，预加载后面视频的关键信息，比如会加载头部信息和需要播放的数据。在播放当前视频时，加载一定数据之后会加载下一个视频的数据，这些都可以做到的。预加载有一个问题，我们之前踩了一个坑，可能预加载视频时还是要优先图片的。视频当然重要，但是社交网络的图片更重要，可能在预加载视频时会考虑到更高优先级的一些任务。

　　优化效果也是比较明显，经过刚才几个策略，一个是我们对头和播放器的处理，我们对防盗链的处理，还有对下载链路的处理和预加载，这样我们的耗时大幅度减少了，之前是 1.8 秒降到 0.6 秒左右。

　　客户端的性能也是让人容易忽视的问题，发现有些用户虽然有视频的缓存，但是播起来还是很慢，这其实是客户端性能的影响。

　　因为视频涉及到的流程比较多，在这个过程中还要更关注客户端的影响，要分析下客户端哪些在抢占视频播放资源，我们之前犯过一些错误，md5 会卡住一些流程，或者是 HttpParser 会阻止你的任务，会导致视频播放更慢。

　　在优化视频播放过程中，我们在 4 月份也做直播。直播这里面插入个事情，我们要播放直播的视频流，是 HLS 的视频，在好友动态里面可以观看直播的内容。HLS 在安卓上面体验非常差，因为安卓 3.0 之后对 HLS 基本没有做的优化工作，这里每次安卓上播放 HLS 需要等待 6-9 秒。

　　分析发现它的处理也不是很得当，因为安卓系统请求链路较长，串行下载，需要下载 3-4 片 TS 才能启动播放，下载 3 个分片的话，耗时就会很久。之前提到我们这里有代理，有了代理之后做事情方便很多了，通过里获取 M3U8，解析 M3U8 里面有哪些文件，可以做并行下载，只让他下载一次 M3U8，这样下载速度大幅度提升。回到刚才架构上，有了下载代理层的话，你可以做 HLS 的加速和管理，可以加入 HLS 的视频源。

　　回到刚才架构上，有了下载代理层的话，可以做 HLS 的加速和下载管理，可以加入 HLS 的视频源。