作者| 阿里文娱技术专家 翠姝
一、设计背景
音视频播放器的工作内容可以描述为：根据流媒体协议还原音视频内容的过程。在还原的 每个阶段都存在丢失精度的风险，而最终呈现的结果也是一个主观的内容，这就给播放器输出结果的评估引入了一些痛点问题，可以列举如下：
测试阶段：
1）人工黑盒测试无法覆盖线上海量机型以及实际复杂的使用环境，定位问题的精准度高却 无法大规模应用；
2）自动化测试虽然可以覆盖较多机型，枚举各种测试用例却无法发现（或代价很高）类似 音画不同步，画面异常等问题，而通常这些问题才是影响用户使用的点。当前测试现状可以概括为更多的给出了功能维度的播放器质量，缺乏技术维度描述。
线上监控阶段：
1）目前描述播放质量的 QOS 指标维度包括卡顿率，成功率，crash 率等，这些指标非常重要,但是对于描述用户可能会遇到的播放器异常来说是不够的；
2）除去上述的技术指标，线上异常多由客诉或舆情驱动，而客诉多是暴露显性问题，那些 暗藏的隐形问题，用户根本不会告诉我们，因为他们直接转向其他平台了。
所以播放链条需要一个可以全面监控播放异常，清晰描述各模块工作状态的系统。
线上异常发生时：
1）目前大部分的模块都有备份方案可以通过线上开关来切换，但是不能通过开关覆盖的问题就需要发版来解决，这样解决问题的周期变长，效率较低；
2）还有一种线上热修复的方案，但是 ios 平台实施起来也有一定难度，这里不多做讨论。 播放链条在检测到异常的基础上需要一定的自修复能力，在用户无感知的情况下解决问题。
综上播放链条开发者需要设计一个技术指标用于描述播放器质量，它包含了更多的异常情 况，同时在指标异常时，播放器可以施行针对性的自修复。
二、设计思路及技术方案
播放异常监控需要了解播放器的各个模块可能会出现的问题，同时这些问题也需要有一定 的实际意义能真实反映用户体验。 所以在选择可用来量化监控的异常时我们可以选取播放链条 理论异常和客诉实际上报异常的交集。如图：
1.播放器架构简介
当前播放器的主要工作流程如下图：
2.设计思路
1）如何定义播放异常 播放异常的标准通常都是针对播放器一系列动作结果的衡量，即最终呈现给用户的效果受到影响。播放链条各模块理论会出现问题总结如下图：
综合上述播放器各模块可能会出现的问题以及客诉集中反馈，我们可以抽象出以下问题：
2）播放器异常量化 如何量化考量这些异常?音视频内容具有单位时间的展示规律，如视频帧率：单位时间需展
示视频帧数；音频采样率：单位时间可展示音频 sample 数。上述总结的流程异常最终都将影响到这两个指标，从而影响音视频最终的展示效果，根据观察我们本地构造不同参数的视频文件，最终我们将异常指标量化如下表：
其中优先级用于在多个异常同时发生时优先上报优先级高的异常，同一时间我们只上报一 个异常。
注：上表中数据并非算法中实际值，只是用于说明问题。
3）监控及自修复 在发现播放异常后我们希望能在播放内核进行自修复，因为这样动作最小，可以做到用户
无感知，而要发现异常我们需要对单位时间内播放链条的输出结果做衡量，而要定位异常发生
的模块则需要了解异常发生时各模块的工作状态。所以我们梳理播放链条各模块监控所需信息 如下图：
根据上述各模块采集到的信息我们可以制定出一个异常映射表：
3. 技术方案
现在我们可以归结出一个视频播放，信息查询，异常检测，自动修复，恢复播放的处理流 程，可以表示为下图：
三、实际应用及效果
1.监控服务
1）监控上线后为规模化处理客诉提供了基础，协同客服将播放相关异常按照我们的分类进 行了整理，最终大部分的客诉都在我们的监控表中有数据可查，之前解决问题只能依赖 tlog， 到现在可以通过数据大概分析问题所在，甚至部分异常可自行修复。最终相关客诉降低了 50%。
2）在播放链条监控上线前，安卓端硬解码能力上线只能通过测试手动测试将设备加入白名 单进行开启，监控上线后可以先行开启相似设备，在得到监控数据后再调整策略，通过这样的 方法发现了一批硬解能力相对较差的机型，通过降档策略提升播放体验。
3）在播放链条监控上线前上线类似多播放器同时播放，画面增强等计算复杂度较高的业务 能力需要测试进行大量的适配测试最终选定白名单进行上线，上线策略相对保守，并且上线真 实效果无法衡量，在增加了监控后高计算复杂度业务对播放体验是否有影响有了很直观的衡量。
4）针对重大直播或者点播剧，可以开启监控报警服务，最大程度保障播放质量。
2. 本地自动化测试
同时我们也协调测试同学，在每个版本的技术灰度发布前进行本地的自动化测试，对版本 质量进行摸底，因为本地测试发现问题可以获取到更多的信息用于解决问题，争取把异常解决 于用户发现前，自动化呈现结果如下图：
3.为技术优化提供了方向和衡量标准
目前的播放器优化存在的两大痛点，一是缺少针对性的优化方向，二是优化后没有明确的 衡量指标。播放链条监控可以部分解决这些问题，监控有助于发现线上存在的严重问题，类似音画不同步，在进行针对性的优化后效果可以反馈在监控数据中，而部分同学做的性能优化也 可以反馈在类似平均解码帧率，平均渲染耗时等指标上。
四、未来规划
1.提升精准度
监控系统本身是一个程序，是程序就可能存在 bug，若监控系统对于是否异常判断发生问 题，对于定位发生在哪个模块发生问题，对于该做怎样的自修复产生问题，则可能导致将本来 是正常的播放进程打乱。所以加强各个环节的定位精准度是监控下一个阶段发展的基础工作， 监控系统需要做秩序守护者，而不是麻烦制造者。
2.提升自动化程度
目前我们处理异常的流程仍然是出现问题->数据分析->定位问题->发版修复。虽然我们提 供了自修复能力，但是支持自修复的模块较少，更多的问题还是需要发版解决。后续需要梳理 更多的模块，配置其可自修复的问题，同时对于日志系统需要更加标准化，基于上报数据+本地 日志可以自动化分析问题，打造出现问题->自动化分析->自动化解决的流程。
3.扩展监控内容
目前基于内容的监控只有黑屏，花屏，低音量，属于被动式检测，只是针对异常进行检测， 我们完全可以开放更多主动性的检测，如人脸检测，音色检测等，将视频进行小片段分割基于 下发机制，让一部分性能优异的机型在播放的过程中对某个片段进行视频内容信息的分析，最 终将结果在服务端汇总完成整片的分析，而这些分析的数据对于我们挖掘广告位或者互动玩法 都有很大的益处。
