作者 | 阿里文娱无线开发专家 韦兴华

责编 | 屠敏

背景

作为优酷APP中用户使用频度最高、停留时间最长的窗口，播放器一直以来都承载着用户最直接的内容消费体验、产品创新、业务突破能力。随着长时间的功能迭代和业务累加，播放器架构在面对现有的体验优化和业务支撑上，越来越显得力不从心，亟需一次全面的架构升级。

经过多方权衡，最终确定基于Pipeline模式进行播放器的架构设计，达到易用、开放、可定制，同时具备清晰的结构、低功耗和良好稳定性的架构改造目标。

设计目标

结合问题的现状，改造的目标如下：

1. 减少部分播放链条中的冗余逻辑，减少函数调用数，减少链路层次，提升起播速度；

2. 统一内存、文件的多份存储，提升解码、渲染的复用度，可以降低播放器内存、线程等资源消耗，提升稳定性；

3. 将播放源、数据下载、后处理等模块的实现开放化和可定制化，让业务可以根据需求自行在播放链路中插入和实现功能逻辑，实现业务的定制化能力；

4. 从整体播放中心的角度思考，优化架构，以便支撑可预见的多源、多流的业务需求，快速扩展，及时响应业务；

5. 实现下载器、解码器、渲染引擎、PCDN、Netcache、智能档等功能模块的原子化，降低模块间的耦合，方便对外输出，并逐步实现单测覆盖。

面临的问题

如下图，通过分析现有的结构，比较容易看出目前存在的问题：

1. 层次过多，一些功能和状态代码散落在不同的层次中，导致可维护性不够。

2. 核心播放逻辑和业务定制逻辑耦合较重，导致对外支撑和向二、三方开放时接口易用性不够，可配置化能力不足。

3. 开放性和扩展性不足，对于需要深度定制的接入方，没有快速的方式对下载、后处理等流程进行干预，对于合流、切流、混帧等特异化处理也没有统一的开放能力透出。

方案设计

1、整体设计

通过梳理，一个播放流程可以抽象为“播放源请求”、“流数据下载”、“流解码”、“后处理和渲染”几个主要的过程，以及“数据埋点中心”“配置中心”等配套设施。在整体架构上，将原来多个层次的实现合并到一个统一的播放框架中，将播放能力和基础业务原子化插件化，由播放框架统一管理并提供可配置化能力。

在开放和扩展性的支持上，将以上的几个主要流程抽象成“播放源管理器”、“数据下载器”、“渲染器”并提供统一的定制化开发能力，并提供自适应的解码能力，以满足未来业务创新上对合流、切流、混帧和后处理的特异化开发需求。

2、统一播放框架

播放框架层负责统一管理和串联各个模块，同时对外部提供统一的API接口。如图所示，1）接口层提供基础的播放上下行消息、管线注册、模块配置等接口；2）状态管理、上下文管理、时间轴管理和多实例管理模块，可以支持多Period和多Source的播放序列，以方便业务方能够快速实现可变格式播放源合并、切流等业务；3）实例池模块可以结合设备和可用资源自适应的管理解码器实例，保证稳定性和体验的平衡；4）管线管理模块负责管线注册和管线绑定逻辑；5）插件管理模块支持一些定制能力的内部实现，内置一些优酷业务能力并支持可配置能力。

3、播放源管理

播放源管理模块抽象了一个PlayList结构，用于支持业务方能够方便的实现不同格式和编码方式的播放源合并、播放序列管理、切流等业务。主要结构如下图，其中PlayList是一个总播放序列；其下的每个Period节点表示一个统一的时间轴播放序列，其下的所有source会合并成一个时间轴，比如由4个15秒的视频合并成的一组60s贴片广告；每个Period下可以挂载多个source，这些source可以支持相同或者不同格式、不同编码参数的视频组合。在播放过程中，允许动态的切换当前Peroid，或者修改后续Peroid的顺序。

4、缓存管线

缓存处理采用多级管线的处理，业务方可以根据自己的场景通过缓存中间件和缓存过滤器的定制实现，来满足针对性的数据下载优化。在优酷播放场景中，针对网络请求和本地存储实现了NetCache和PCDN两个缓存过滤器，具体如下图所示：

1）将资源存储分为三级缓存管理，由缓存管线进行调度管理；

2）业务可以通过参数自定义选择使用混合层级的缓存；

3）缓存管线针对不同资源，读取或写入存储时分别通过访问 NetCache 或 PCDN 模块进行处理；

4）未来本地磁盘存储除预览需求外，希望统一采用 PCDN 存储方式存储，以提升 PCDN 的分享率，有效的降低成本。

5、渲染管线

后处理和渲染同样采用多级管线的处理。渲染管线模块提供多个渲染Context支持，每个Context绑定一个解码器和一个渲染窗口，并自动对同一个渲染窗口的多个Context的渲染结果进行合并和上屏。业务方可以通过实现渲染中间件和渲染过滤器来进行定制化的开发，以进行诸如混流、混帧、视频特效等特异化开发来满足业务和创新需求。

思考和总结

播放器以及端侧播放链路是一个庞大而复杂、且综合性很强的系统，尤其在优酷这样的重视频场景消费的产品中，播放器承载的业务会随着时间不断增长。如果没有一个相对合理稳定的架构设计，在长时间迭代之后整个系统的复杂度是不可想象的。在本次架构改造中，我们首先抽取播放的核心过程作为整个架构的基础，把播放中心已经积累的能力模块化原子化，通过统一的播放框架组织起来，同时结合未来业务的创新和发展方向，对外开放了统一的定制化开发能力，基本实现了预期的改造目标。

当然播放框架的改造并不是一蹴而就的，未来在核心框架稳定的前提下，还需要继续推进诸如端侧数据中心、端侧AI、全链路监控等配套基础设施的建设。同时随着5G技术的发展，如何将端侧和边缘结点打通，如何在端、边、云上做到计算资源的最大化利用，也是播放框架需要思考和尝试的方向。

【End】

推荐阅读 

☞75.58 亿美元成交！美国最大规模 5G 毫米波频谱拍卖

☞不用掉一根头发！用 Flutter + Dart 快速构建一款绝美移动 App

☞超轻量级中文OCR，支持竖排文字识别、ncnn推理，总模型仅17M

☞和黑客斗争的 6 天！

☞一文了解 Spring Boot 服务监控，健康检查，线程信息，JVM堆信息，指标收集，运行情况监控！

☞用 3 个“鸽子”，告诉你闪电网络是怎样改变加密消息传递方式的！

你点的每一个在看，我认真当成了喜欢