如何打造支撑多种视频播放诉求的大前端播放器？

VideoX 是内容前端团队基于电商业务（以下简称大淘宝）背景打造的面向大终端场景的前端播放器。这篇文章谈谈我对播放器领域问题的认识，以及当下解决这些问题的思路。

大淘宝视频播放的场景有哪些？

大淘宝视频播放的第一业务场景，是在消费侧。回想起来我最早在淘宝上看到视频内容，应该是在商品的详情页。几十秒的视频内容更形象地传递了商品的信息。商品有了视频内容，自然地在一些前置入口上也就可以透出它们了。比方说首页上的「猜你喜欢」，搜索的结果页等这些淘宝的基础交易链路；16年淘宝开始提出内容化与社区的方向，引入了创作者的角色以及图文类型的内容，并推出了爱逛街、有好货、淘宝头条等内容电商产品，短视频在其中扮演着至关重要的角色。淘宝直播也在这期间横空出世，实时类视频登上淘宝历史的舞台。21 年淘宝持续推进内容化，提出“生活在淘宝”的愿景，逐渐形成了以逛逛、点淘和淘宝直播的社交内容产品矩阵；商家上传的商品视频和创作者发布的图文视频，又可以在前台的导购场景中透出，不断丰富淘内的商品导购形式和信息消费形态。

应该说，在内容和交易日渐融合的趋势下，在淘宝从交易走向消费的进程中，视频已经无处不在了。

视频内容的流转涉及从生产到消费的完整链路，在生产侧和平台端的业务场景同样存在视频播放的诉求。在生产侧，创作时在亲拍中需要播放模板视频，发布时在逛逛需要预览视频上传后的效果；在平台端，在纵横的体验中心演示能力时需要对多种分辨率和编码格式的视频进行播放，在黄雀每天众多的审核人员完成巨量的审核任务时需要播放视频。

大淘宝视频播放的场景有哪些？

由上可见，大淘宝视频播放的业务场景是非常复杂的。尽管场景是复杂的，但业务对于视频播放的诉求是可抽象的。我把它们抽象为以下几点。

▐  多端的播放能力

业务上对于视频播放的首要诉求，还是视频能不能播的问题。在大淘宝上，主要播放短视频、视频动画、直播和回放、全景视频等。依据实时性和交互方式的不同，通常将这几类视频分为点播(Vod)和直播(Live)。

为使得这些类型的视频能够在网络上更好地进行传输和播放，则需要用到不同的视频格式：

不同的视频类型使用哪种视频格式是由跨平台兼容性、延时、可拓展性、使用成本等因素综合决定的。

由于不同业务场景面向的客户群体的差异，以及业务根据其性质对用户体验和研发效率的权衡，业务上的终端场景也是千差万别：

比方说行业小二给商家进行直播开课，商家是在千牛 PC 客户端上进行观看；店铺为了做三方的开放技术，很长的一段时间用的是小程序的方案；基础链路要优先保障稳定性，用的是 Native 的方案，外投又需要适配 WebView……

播放器需要对这些的视频类型、视频格式和终端场景提供完备的视频播放支持。

▐  视频交互能力

除了播放画面和声音，在观看视频时，业务还需要为用户提供视频交互能力。这些实现交互功能的控件是盖在视频之上的：

交互的目的通常是为了控制视频的播放进度和效果，以及设置视频的可见性。这些交互能力我归类总结了一下，有以下几种：

1. 播放状态和进度控制：播放状态控制，例如通过点击按钮播放、暂停或重播该视频；播放进度控制，例如通过点击前进/后退按钮跳过一段内容，或通过点击或拖拽进度条切换播放时刻；

2. 播放效果控制：例如切换静音/有声，调节音量，设置播放倍数，切换视频清晰度等；在一些长视频网站上，还有当存在多语言时可切换音轨和字幕的能力。不过目前在淘内没有这类诉求；

3. 可见性控制：即控制视频在屏幕上的可见范围。通常的业务诉求是全屏和小窗的能力；移动上在宽高比合适的情况下自动横屏的诉求；PC 上部分业务有宽屏和满屏的诉求；

4. 更多能力：例如淘宝直播上的弹幕能力、逛逛短视频的商品卡片及互动弹层等。

▐  交互定制能力

上面列举了全量的交互能力。但不同的业务场景需要的交互能力是各不相同的。这就需要播放器提供交互的定制能力。对相关的定制能力进行归纳总结，有以下几种：

1. 控件的定制：最常见的是不同的业务场景下要显示的控件均有细微差别；其次是菜单类型的控件（例如倍数）选项列表需要可以被业务所指定；最后是不同的业务对控件的交互行为也有不同的偏好，例如点击视频是否切换播放/暂停状态，双击视频是否全屏，播放开始后是否隐藏所有控件等等；

2. 样式的定制：控件的排布顺序和位置经常在不同的产品下有所不同；控件的大小、颜色会在一些大的业务线下所有不同；控件使用的图标在一些独立 App 下有所不同；

还有一种是控件语言的定制，允许业务设置控件内使用的文本语言。例如业务可根据用户所在地区设置播放器使用的语言。目前在淘内没有这类诉求。

▐  多视频管理能力

在移动端，当页面上有多个视频时，为了避免一次性加载所有视频资源浪费用户流量或多个视频一起播放出现「双音轨」的情况影响用户体验，业务普遍有多视频管理能力的诉求。

管理能力可以概况为以下几种：

1. 控制每个视频的加载时机：例如在幻灯片(Slider)场景下，只有当前显示的那个幻灯片才需要加载视频资源。切换幻灯片后播放当前幻灯片下的视频，暂停或销毁之前的视频；

1. 选择最佳位置的视频进行播放：例如在滚动(Scroll)场景下，要选择离屏幕视觉中心点最近的视频进行播放，该视频播放时，暂停或销毁上一个正在播放的视频。

淘内的交互场景还有很多。比方说：

1. 选项卡(Tab)场景下，切换 Tab 后选择当前 Tab 下面最佳位置的视频进行播放，暂停或销毁上一个 Tab 下的视频；

2. 或者版头是 Slider 且整个页面可 Scroll 的场景下，需要优先播放版头的视频，版头滚出可视区域后暂停或销毁版头内的视频，选择滚动区域内最佳位置的视频进行播放；再次回到版头后，接着上一次被播放的视频继续播放。

▐  播控服务能力

通常来说，业务播放视频，只需要传递一个视频资源 URL 就足够了。但部分业务为了权衡视频投入的支出和前台用户的体验，就需要使用到播控服务能力。播放器会请求一个播控的服务，来实现：

1. 视频资源下发：服务端下发不同档位分辨率的视频资源 URL，业务决定优先播放哪个档位的视频；服务端下发不同编码格式的视频资源 URL ，业务决定优先播放哪种视频编码；服务端下发不同投影方式的视频资源 URL，业务决定优先播放哪种投影的视频；

2. 播放策略下发：包括首次加载视频时的预加载大小、播放时的缓冲区大小、是否开启资源本地化缓存等策略。这些策略通常使用的是默认值，但业务也会基于自身的视频资源类型和终端用户环境来进行调整；

3. 更多：例如视频版权管理(DRM)、视频广告投放(Ads)等能力，都需要借助播控服务来实现，不过目前在淘内没有这类诉求。

▐  数据化能力

业务需要了解视频的投放效果和用户的观看体验，就需要数据化能力。视频播放评估指标可以分为两类：

1. 一个是视频体验质量(QoE: Quality of Experience) ，该指标用来衡量最终的业务效果，反映在业务中用户使用视频产品的情况（例如对视频是否喜爱）。具体的指标值包括播放次数、播放时长、有效播放率等等；

1. 一个是视频服务质量(QoS: Quality of Service) ，该指标用来衡量技术提供视频服务的效果，反映线上视频播放技术的运作情况（例如性能和稳定性）。具体的指标值包括视频秒开率、视频卡顿率、视频播放成功率等等。

业务需要我们定义这些指标及其计算口径，并提供其业务域内的实时和离线数据。

▐  播放管控能力

视频的引入给业务在终端带去了全新的用户体验，但是如果使用不当，轻则造成突然播放声音影响用户体验，重则在移动端浪费流量造成用户经济上的损失。因此，一方面业务既期望我们能够提供便捷的定制能力，另一方面也期望我们能有「兜底」的能力，在发生问题时能够及时止损。这就是播放器的播放管控能力。

例如：

1. 权限类的：是否允许自动播放、是否允许后台播放、是否允许流量播放。这些配置还与用户的手淘配置相关，最终影响到用户的流量使用；

2. 优化类的：是否启用硬解、是否启用缓存、是否启用数据埋点。这些配置设定目的是对用户终端硬件的消耗及播放性能之间进行权衡。

技术如何满足这些诉求？

我们为满足业务视频接入的诉求，提供了一套完整的视频接入方案，覆盖业务从视频发布到视频播放的完整链路。从端视角来看，方案中包含了视频上传SDK，视频服务，视频播放器三大模块。链路中通过业务标识和视频标识来保障业务域内视频流转的可追溯。

业务发布页使用视频上传SDK：

const uploader = await createUploader({ bizCode: 'foo' });
const fileInfo = await uploader.startUpload(file);

业务主页使用视频服务接口获取 videoId：

const videoIds = await request('//service.taobao.com/foo', { bizCode, from });

业务详情页使用视频播放器：

备注：

1. 业务主页也可能直接使用视频播放组件；

2. 业务通常使用短视频全屏页而非建详情页来实现视频播放和互动。

▐  播放器架构

基于业务的诉求和当下的生产关系，播放器的整体架构遵循两个大的原则：一是要薄，让业务有选择权，基于能力组合进行定制；二是要白盒，让业务有发现和定位问题的能力而不是强依赖底层。

因此播放器架构遵循关注点分离的原则，分为以下几层，每一层解决一个领域内的问题（业务诉求点），使用特定的技术栈（技术发力点）：

1. 播放能力层：这一层解决视频能不能播的问题。解决这个问题需要音视频技术能力。架构上把这一层封装为独立的模块，称之为播放器内核；

2. 业务接入层：这一层解决如何能够在业务系统内基于底层能力快速定制专属播放器的问题。解决这个问题需要大前端技术能力。架构上把这一层封装为独立的模块，称之为播放器组件；

3. 体验保障层：这一层解决如何保证开发者体验和用户体验的问题。解决这个问题需要软件工程能力。架构上把这一层作为一个纵向建设，称之为播放器配套设施。

基于这个分层产出播放器整体架构图：

1. 播放器规范：包括了统一术语定义、视频播放评估指标定义、播放器 API 和事件定义等。通过一个类型包来 videox-types 进行承载，使得在播放器体系内名词得到统一；

2. 播放器内核：包括了面向 Web 场景使用前端技术栈的播放内核 videox-core ，以及面向移动端场景使用原生技术栈的播放内核 native-core。前者可以在前端领域被直接使用，后者可以在原生领域直接使用，也可以通过 SDK 集成的方式在 Weex/MiniApp/PHA 等容器下被使用；

3. 播放器组件：包括了面向 React 技术栈的播放器组件 react-videox，适用于 Web 场景。以及面向 Rax 技术栈的播放器组件 rax-videox，使用于多端场景（适配了 PHA/Weex/MiniApp 容器）。两者一些共用的能力则通过插件形式承载，在业务接入时通过组合的方式进行选配；

4. 播放器配套设施：包括了保障视频播放体验的测试方案、日志方案、数据埋点方案等，通过工具库 videox-utils 承载；以及保障业务接入效率的教程文档及代码示例，通过官网 videox-site 承载。

▐  播放器内核

播放内核解决视频能不能播的问题，并提供一组可控的 API。根据大淘宝业务对多端视频播放的诉求，结合多端场景下稳定性和性能最优解的权衡，播放内核有面向 Web 场景使用前端技术栈的播放内核 videox-core ，以及面向移动端场景使用原生技术栈的播放内核 native-core。

• 面向 Web 场景