HLS 优化效果也是很明显的，之前需要 6 秒左右，现在 1 秒左右就可以播起来。整体从之前的 2 秒左右，现在优化到 700m 秒，0-1 秒的占比目前在 80% 左右，80% 用户都可以在 1 秒内播视频。

　　体验优化

　　还有一个是用户比较关注的问题，观看视频时卡，观看一会卡了一下，loading 数据，loading 完以后又卡，这个体验非常差，我们希望所有的视频都不卡。

　　其实这有两个播放场景，一个是正常场景，边下边看，数据在下载。对于正常场景下载时会做一些带宽调整，在低速时会做切换 IP 的处理，比如说当前连通 IP 的耗时比较久的话，会做一些处理，也会对网络进行速度限制。

　　针对 Seek 场景，用户拖动，如果文件缓存系统是顺序存储系统的话，必然会造成拖到这里时，后面的缓存数据没有办法下载到系统里面来。只要用户每次拖动，拖动后的下载数据没法存到硬盘上来。

　　我们就对存储做了一次重构，支持文件空洞。会按照一兆的方式进行文件碎片划分，这就是视频的数据，每一兆就是个文件分片，通过它的 Key 和文件进行存储，这样好处是可以分段存储，可以允许逻辑空洞，拖动的话也可以在后面存储，也不依赖数据库，通过文件名可以知道是从哪个位置到哪个位置的存储。这样淘汰缓存高效一点，可以制定更灵活的缓存策略。可以淘汰更低粒度的文件，比如 seek 之后的文件可以保留，还可以对文件加密。

　　产生卡顿的用户里面，开奖，90% 是因为进行拖动，拖动之后又没有缓存数据，所以这里有可能导致缓存。统计效果也是比较明显的，上了分片缓存之后，之前的缓存概率是 4.6% 左右，最后下降到 0.48%，基本上看不到发生缓冲的场景。

　　成功率优化，也是比较关键的指标。成功率优化没有捷径，可能是 Case by Case 各个击破。针对错误进行编码，有几百个错误码，每一个错误码捞 log 去看，错误码原因进行上报，每次进行循环一个个错误码进行解决。

　　DNS 劫持是比较多的，会劫持你的请求。这个是在国内比较常见的劫持，有的小运营商按 URL 劫持视频内容，可能直接污染 DNS 让你查找不到 CDN，这是比较多的，还有一些网络不稳定的影响导致。更高级的直接污染视频内容，让视频内容是错误的。

　　播放比较多的可能是一些编码的原因，手机采集出来的视频在低端手机上播不出来，我们会对这些视频进行修复。

　　逻辑上的问题，因为播放器是有状态机的，开发人员比较多，每个人过来加一个逻辑的话，会导致播放状态出现问题。

　　我们解决播放器错误的方法：HOOK 播放器接口与回调，实现播放器状态机，监控插放器 API 的调用是否合法，不合法直接告警或 Crash。帮助开发快速定位问题，同时减轻测试同事的负担，封装成 UI 组件，使其它开发不必理解播放器。