agenda： 快速上线 --> 成本优化 --> 体验优化
我的分享主要是按照我们产品迭代的几个关键步骤展开：
首先是快速上线，2015 年我也是跟随着大家的体验快速上线了新短视频的体验；
其次面临的是成本问题，在做的过程中做了一些成本的优化工作；
然后是体验优化。在解决成本问题之后，短视频的观看体验要做到极致。比如说视频的秒开、不产生缓冲、不卡、成功率的提升。
1 基本的播放需求
基本的技术要点
边下边播，加速播放速度
流量控制，具备元控制能力，让带宽消耗可控
与业务合理解耦
模块化复用，统一播放逻辑，跨平台
监控上报，多维度监控，对业务知根知底
可以看到，完成核心技术要点最核心的一点是如何控制视频的下载，传统的方式是播放器直接塞播放地址给播放器，它就可以直接播放，这其实是一个黑盒。
我们在中间加了一个本地代理，播放器与服务器的数据请求，我们完全可以把控。在这个过程中，比如说播放器要数据时，可以给它更多的数据，这样能解决它缓冲的问题。有了这层代理之后，架构也更清晰一点。
基于 MVC 架构，在 MODEL 一层做一些业务的逻辑，在 VideoController 这一层做控制视频的播放和下载。
有了下载代理之后，就可以通过代理管理下载，在 APP 里面有很多的视频请求，VideoProxy 可以管理这些请求，做流量控制，做预加载，还可以做优先级调度和做监控上报，下载逻辑层则主要关注怎么优化服务器，对接缓存管理层，同时我们抽象出了一个数据层，我的数据源可以是 HTTPDataSource，也可以读本地，也可以是来来自腾讯视频的数据源，也可以是第三方 APP 的数据源，协议层主要是 HTTP、HTTPS、HTTP2 的解决。
在 VideoController 的逻辑里，其实都可以放到 C 层来实现，这样安卓和 iOS 完全可以通用，这一层的逻辑可以在 QQ 和 QQ 空间两个 APP 里面使用，相当于是我们一套逻辑可以完全复用，不用再开发四套逻辑。
监控目的：
问题定位
耗时统计
成功率统计
实时告警
监控上报，肯定是不可缺少的，这是一个成熟的项目必备的要素：
- 问题定位，老板跟用户反馈说我这个视频播不了，要有一套成熟的问题定位的方式；
- 耗时统计，用户播放这个视频花多长时间播出来，这也是要了解到的；
- 成功率统计，外网用户播放视频的成功率是多少？还要通过实时报警，才能及时知道外网发生一些故障。
定位问题
错误归纳
上报流水
错误统计
实时统计
播放成功率
下载成功率
缓存耗时
缓存概率
播放次数
实时告警
传统的捞 Log 方式大家都有，但是这种方式效率太低，需要等用户上线之后才能捞到 Log，Log 捞到之后还得花时间去分析。我们做法的是在关键问题上做一些插装，把每一类错误和每一个具体的子错误都能定义出来，这样一看错误码就知道播放错误是由什么原因导致的。
还可以把每次播放视频的链路所有关键流水上报到统计系统里来，每一次播放都是一组流水，每一条流水里面就包含了例如首次缓冲发生的 Seek，或下载的链接是多少，下载的时间是多少，有了这些流水之后，用户反馈播放失败，我首先可以用流水看发生了什么错误？错误在哪一步？每一步信息是什么？几秒钟就可以定位到问题。
有了这个数据上报之后，还可以做一些报表。比如说可以做错误码的报表，有了报表之后就可以跟进哪个错误是在 TOP 的，负责人是谁，原因是什么，都可以看到。
3 成本优化
如果之前不做限速的话，一点开视频就疯狂地下数据，带宽有多大就下多少的数据，这样浪费很严重。我们采取的第一个策略是进行流量控制。在高峰期播放到第 10 秒时，预下载 N 秒数据，下载到 N 秒就停下来。然后，可以做多级限速。一开始不限速，下载到合适时机做 1 倍码率限速。高峰期时预加载的数据会少一些，防止高峰期时带宽占用明显，这是初级的策略。最终我们也有码率切换的策略。这对用户的观看体验影响比较大，这也是之前必备的一个策略。
流量控制
H265
客户端适配
客户端解码适配
客户端解码覆盖
H256编码后端策略
H256编码后端优化
自严H256编码器
4 体验优化
核心的流程主要是三个步骤：
客户端初始化播放器；
下载数据；
等待播放。
这里主要有两个大的耗时点，第一下载视频数据耗时；第二个是客户端的耗时，下载视频数据耗时的话，主要是下载数据量和下载的速度。
这里有一个很直接的问题，播放器需要下载多少数据才能播放？
优化点：
- mp4的MOOV问题，保证都在文件首部
- 播放器行为优化（Mdata优化）
- 优化下载耗时
防盗链耗时
IP直出与竞速 - 预加载：预加载时机
- 客户端性能优化
线程梳理
异步化
重复运算做缓存
hls优化
串行下载改并行下载
缓存优化
正常情况(10%)
带宽调整（暂停其他占用下载带宽的逻辑）
低速切换IP
网络抖动（单次下载出现两次抖动，就突破下载限制）
Seek场景(90%)
缓存系统重构，支持文件空洞
存储做一次重构，支持文件空洞
成功率优化
成功率优化，也是比较关键的指标。成功率优化没有捷径，可能是 Case by Case 各个击破。
针对错误进行编码，有几百个错误码，每一个错误码捞 log 去看，错误码原因进行上报，每次进行循环一个个错误码进行解决
下载常用错误
DNS劫持 35%
异常返回403 25%
异常返回404 10%
慢速网络 10%
网络不稳定 10%
异常返回500 5%
内容遭劫持 5%
播放常用错误
视频播放器内部错误 35%
播放器调度不合理导致的错误 65%
播放器成功率解决
逻辑上的问题，因为播放器是有状态机的，开发人员比较多，每个人过来加一个逻辑的话，会导致播放状态出现问题。
解决播放器错误的方法：
HOOK 播放器接口与回调，实现播放器状态机，监控插放器 API 的调用是否合法，不合法直接告警或 Crash。
帮助开发快速定位问题，同时减轻测试同事的负担，封装成 UI 组件，使其它开发不必理解播放器。
网友评论