一、背景

优酷播放器早期的架构是普通的单工程分层结构，随着时间推进，播放器容器数量不断增多，陆续支撑了播放页、发现页、自频道、频道页、直播等几大场景，可以说这段时间里原有架构起到了很大的作用。

然而随着代码的继续膨胀，一些问题开始突显出来。工程一直处于不断膨胀的状态。如上图所示，每个业务场景都是一个独立的播放容器和 UI 组件，当有新的业务场景出现时，由于旧有容器无法复用，开发人员只能继承基础容器创建新的容器。同时开发人员要维护所有的播放容器，而这其中大部分工作量都是重复的。

举一个最简单的视觉升级的例子来说，在老架构的前提下，假如需求是要改变进度条的样式，几乎每一个播放容器都需要按照标注图进行一遍样式修改，对团队来说，这既是一种资源的浪费，又是一种疲惫的工作负担。

架构之外，优酷由多个业务团队维护各自的业务场景，这些业务场景最终都对接到播放器团队，在优酷保持高频率发版迭代的情况下，播放器团队本身就疲于应对各种各样的播放容器，使得业务方团队往往排着队等待完成与播放器团队的联调与交付工作。

播放容器不易复用、对多团队并行开发的支持不够友好等原有架构的缺陷愈发明显，为此我们对优酷播放器架构做了全面改造。

二、新的播放器架构应该怎么做

确定新架构的核心需求

为了解决上一章节提到的原有架构缺陷，此次架构改造确定了新架构如下几个核心需求：

1）播放器可以快速复用来支撑多业务场景；

2）播放器支持多团队并行开发。

新架构设计的核心思路

1）插件化：解耦合和独立迭代是分不开的，此次改造决定把优酷播放器现有业务进行划分，将播放器的最小集能力抽象成若干基础能力插件，将其他业务抽象成若干扩展插件，拆分插件的下一步是代码边界划分，播放器团队把不同业务的代码与业务 Owner 一起将其拆分到不同的工程的插件内，插件之间彼此独立。不同插件之间只依赖于新的架构框架进行编译，而框架作为平台来说它的代码变动是低频率较为稳定的，因此可以看为是编译隔离。

2）事件驱动：已经有了插件的概念以后，下一个问题就是，如何让插件之间像魔方一样联动呢？新架构做了基于消息的事件驱动机制，即做出事件总线，插件之间通过事件总线实现互相通信。

3）按需配置：在有了插件化概念的情况下，播放器通过众多业务的拆分生成了插件库，配置化能力其实就是插件的编排能力，这和容器技术的思想类似，根据业务场景需求开发者从插件库中选出对应插件传递给播放器框架进行安装使用，通过不同的配置既可以实现不同业务场景的播放器支撑，又大大提高了插件的复用率。最终把不同的插件配置列表生成配置文件，也就实现了只需要几个配置文件就可以创建出不同场景播放器的能力。

4）分层管理：将播放器视图各 Layer 层进行统一管理，插件内的视图根据自身属性，来决定应该显示在哪个层上。

5）标准明确：制定了插件开发标准，让每个插件拥有统一的属性和生命周期，当做好了开发标准以后，留给业务方团队的就是一道填空题，团队根据自身业务，把原有业务代码稍加重构就能放到插件内。当新的业务场景无法找到满足需求的插件时，也可以根据开发标准创建新的扩展插件。

统一播放器业务框架

有了核心设计思路之后，此次架构改造开始设计架构的其他细节。整体的架构图如下所示，上下往上架构分为能力层、业务层、API、业务场景，团队管这套新的播放器架构称为统一播放器业务框架。

其中插件管理器、布局管理器、事件管理器、配置管理器、数据源管理器作为统一播放器业务框架的核心模块，其功能作用如下：

1）插件管理器

插件管理器主要负责插件的配置、初始化、安装、运行等一系列生命周期管控，将插件内部创建的视图添加到对应 Layer 层，以及管理插件内部 Event 事件的注册、监听、移除。

2）布局管理器

布局管理器将统一标准里制定的 Layer 层抽象成对应的布局组，并创建对应布局组的布局控制器，接收插件发送的布局模型，寻找对应布局组的布局控制器进布局管理，布局控制器根据布局模型，把对应视图插入到对应的 Layer 层。

3）事件管理器

事件管理器创建事件总线供插件间通信使用，维护事件发布者和事件订阅者之间的关系以及根据订阅者优先级对事件 Event 进行派发。

4）配置管理器

配置管理器解析配置文件，转化为插件和 Layer 的配置列表，并传给插件管理器进行插件安装和播放器的初始化。

5）数据源管理器

数据源管理器管理着众多数据源的生命周期，数据源是为了给多插件之间读写共享数据而提出的概念，举例来说，根据播放器和视频应有的属性与方法，分别抽象出播放器数据源、播放视频数据源等，各插件通过对数据源执行属性的 get 和 set 以及方法调用来进行业务处理。

6）生命周期

最终，整个框架的运行生命周期如下图所示，当播放器初始化完成以后即可进入工作状态进行视频服务消费。

核心特性

1）基于消息，事件驱动

引入事件/订阅的消息机制，插件按需订阅播放器的事件，根据优先级响应和消费消息；

2）按需配置，自由组合

支持从配置文件加载层和插件的配置信息，各个业务方在接入业务框架时以搭积木的方式排列组合构造播放器；

3）插件解耦，互不依赖

将所有的播放功能及业务模块解耦为彼此独立的插件，插件之间以消息机制进行通信；

4）标准明确，支持扩展

框架会提供一批功能丰富的标准插件，插件可分组管理，业务方可根据自己的需求定制插件来替换默认实现，也可以新增插件；

辅助工具

相对于老的单工程架构而言，新架构的多工程插件解耦事件驱动在一定程度上使得方法调用链路变长不易调试，为了弥补调试困难需要开发出一些面向开发者使用的调试工具，如视图 Debug 工具、日志工具等。

三、现状及未来

统一播放器业务框架开发完成之后陆续已经在 pad、phone 等多端落地，插件库的数量已经发展到了一百以上，其中大部分插件都在各业务场景中有所复用。

对团队收益而言，它适应了复杂的播放业务场景，支持着众多围绕播放业务的团队并行开发。通过技术架构的解耦带来与之相关的技术团队的组织架构的解耦。

还记得开篇那个视觉升级的例子吗？现在用播放器新架构来代入问题看看，假如需求是要修改进度条样式，现在只需要找到进度条插件，插件的 Owner 团队进行一次样式修改，所有复用此插件的业务场景就可以无成本落地了。

通过插件的配置组合，新播放器支撑了播放页、互动剧、少儿播放、预览播放、首页广告播放、广告页播放、会员页播放、Weex 播放、Feed 流播放、电流小视频、淘宝直播间等诸多业务场景，同时也为业务创新带来了很好的支持，基于统一播放器业务框架，我们在短时间内开发并上线了酷看、互动视频等创新功能，未来播放器团队也将继续朝着平台化、配置化的方向对框架进行优化。

作者 | 阿里文娱高级无线开发工程师贵志

创作场景

优酷统一播放器业务框架演进之路