亿级用户高稳定性视频播放器养成计划|618淘系前端技术分享
文末福利：开发者藏经阁
NO.1
背景
PHA 框架的优秀性能让大量业务、会场开始逐步转用 H5，但同时带来了一些挑战。以多媒体日常短视频/直播业务为例，H5 原生的播放器的稳定性、性能、播放能力支持均难以达到使用标准，在 H5 环境下没有一个业务可用的 H5 播放器。这时候就需要一个 H5 上能够流畅播放的播放器。
首先，提前体验一下 618 期间，H5 下播放器能力：
618 期间战果：618主会场，猜你喜欢，直播会场，聚划算百亿补贴、行业会场等。
NO.2
同层渲染播放器方案设计
也许你之前不了解什么是同层渲染？
同层渲染，是允许将 Native 组件和 WebView DOM 元素混合在一起进行渲染的技术，能够保证 Native 组件和 DOM 元素体感一致，渲染层级、滚动感受、触摸事件等方面几乎没有区别。
综合了性能、稳定性、易用性、灵活性上考虑，我们选择了同层渲染这种技术方案，以此渲染手淘 H5 下播放器。
底层 Native 播放器拥有一套健全的播放能力，在早期 weex 及 Native 下，均有不俗表现。经过多年沉淀，api健全、性能稳定性良好，Naitive 播放器能力已达到业务可用的标准。
在此基础上，需要针对 Native 播放器 做一层同层渲染组件的封装处理以适用于 webview（iOS wkwebview，android UC 内核）上播放器的同层渲染。客户端封装组件层需要监听同层渲染事件通知，在接收到创建/销毁消息时，实例化/销毁播放器。
监听的依赖于中间的通信层，淘系基础架构团队针对同层渲染的组件做了监听：在同层渲染组件创建 <object /> 节点时，通知到客户端播放器实例化渲染。
业务层播放器封装，使用了 @ali/rax-composite-view-factory 同层组件渲染工厂方法，该库将组件渲染成 <object /> 节点，当 <object /> 节点渲染出来时，前端会通知到监听层需要渲染何种组件，此时监听层收到后通知到客户端组件，客户端完成渲染，并持续接收来自前端的事件监听。(iOS 通过 element.addEventListener 通信，Android 通过 WindVane 通信)。
Videoplus
从业务角度来说，视频播放主要分为两种：直播和点播。
其中，直播中区分：直播流、回放、看点，点播则是视频播放形式。
从图中可以看到，对于如此复杂度的播放要求，在此之前，仅在weex和web端下针对复杂业务的播放器支持。手淘内在PHA(即手淘H5)场景下，没有一个适用的播放器。
618前视频组件支持情况：
Videoplus 是端内针对多场景播放器的一个组件，该组件在对不同场景下的播放器进行了抹平处理，对用户来说，无需关注当前场景，只关注播放器本身即可。
播放场景抹平：Videoplus 针对环境做了一层抹平处理，不同场景使用不同的播放器，本次 618 新增同层渲染播放器，能力上更加完善。
weex：使用 weex 底层封装的播放器
手淘 H5：使用同层渲染播放器播放
外部 web：使用多媒体前端团队 videox.js
事件/属性/监听：Videoplus 针对播放器的时间、属性、监听进行一层抹平，符合 w3c 标准播放器的 api 标准，用户使用时，如果上手过 video 开发，接入成本大大降低
Splayer
Splayer 严格意义上来说不是一个真正的播放器，是一个业务基于在 Videoplus 上的封装层组件。Splayer 不针对播放器本身功能做特殊处理，把重点放在了业务日常开发播放器中更关注的一些实用功能上。
在 Splayer 管控之前，业务背景十分复杂：
列表形式
单列流
双列流
轮播形式
Tab 形式
版头模式
支持如此复杂且多样的交互上场景，Splayer 必须兼具各项能力，对于事件监听及分发处理逻辑十分复杂。
同事，需要整体考虑客户端性能稳定性，保持播放器单例管控。于是：
实例管控：
Splayer 总能保证当前播放器只有一个播放器实例，避免因为实例无限增长导致 OOM
对于类似会场模块组成形式的页面，Splayer 要求各个模块引用的版本一致，实例化出来的 SplayerEmitter 保证唯一性并能监听到其他模块发送的指令。
事件监听：Splayer 提供了一系列事件监听方案控制视频播放器，可以通过 Splayer 提供出来的 SplayerEmitter 完成播放器的销毁或者创建工作，并且无需担心其余播放器的处理(在每次操作播放器时，Splayer 会同时管理其他播放器实例)。
滚动监听：当滚动停止时，Splayer 会寻找播放器最佳位置播放。
指定 id 播放监听：存在播放器列表场景下，指定单个播放器监听播放，此时 VideoManager 会销毁其余播放器，并将指定 id 的播放器实例化。
Appear/DisAppear 监听：依赖于 rax 的 appear/disappear 方法，在每个 Splayer Appear 时，VideoManager 会缓存当前的播放器，并从当前缓存的 Appear 播放器队列中选择最佳位置(居中)的开始播放。
NO.3
稳定性保障方案
Videoplus 提供了多维度的降级能力，通过手淘 mt 配置降级方案。在大促期间，在预案平台提前报备。
全量降级
终极兜底方案，开启后，所有 Videoplus 播放器强制降级成 poster。
播放器场景降级方案（H5/weex/PHA）
支持 H5/weex/PHA 场景，对应场景（直播或者点播）播放器出现意想不到的情况时应急采用。
H5/weex/PHA场景分别带有：
禁用直播
禁用视频
指定业务降级方案
在某一业务使用播放器时发生问题时，兜底使用。当开发业务接入播放器时，需要传入唯一业务指定 bizFrom，具体需要到播放器管理者处申请，如果未传入值，则播放器不可使用。
可直接指定某项业务(bizFrom)关闭播放功能，一旦关闭，直播和视频在该业务场景下不可使用。
指定客户端/客户端版本号使用
指定客户端版本及版本号使用。在手淘及天猫客户端版本中，如果播放器被发现某些bug，可通过此开关降级。
粒度控制到三位版本号，例如手淘 9.5.0 版本。
指定操作系统版本号
此场景由于某些操作系统及版本下播放器出现问题，粒度控制到三位版本号，例如 iOS 10.1.3 版本。
NO.4
大促技术和业务表现
淘系技术部 Native 播放器内核的多年沉淀，Native 底层播放器处于稳定状态。相较 H5 播放器来说，Native 播放器支持格式更广、解码能力更优、性能体验极佳，但灵活能力不足。基于 Native 播放器的同层渲染播放器，在体验上与 Native 播放器达到达到持平状态的同时，灵活能力兼具。
H5的播放器 vs 同层渲染播放器
618 战果
业务数据：6 个以上618模块(行业、直播1x2、猜你喜欢、头图等)接入，服务超过 200 个以上会场。
技术表现：sls大盘监控底层播放器成功率99%以上；客户端监控稳定无 crash 新增，无故障，无回滚降级，整体灰度顺利。
NO.5
同层渲染播放器遇到的问题
问题：前端移除 <object />之后，PHA Tab切换挂起webview，导致异步操作失效未将播放器实例销毁，主会场头图/猜你喜欢模块、行业商品模块、直播会场1x2模块。
解法：播放器监听PHA 页面 disappear，强制停止播放，并forceUpdate同步销毁播放器解决此问题
问题：Splayer的复杂使用场景，在1x2 模块播放器视频切换过快情况下，消失动画延时，封面图移除时机出错导致出现白窗。
解法：调整底层播放器封面图移除时机，在播放前移除。
NO.6
未来规划
对于本次 618 的实验与应用，同层渲染播放器仅仅是小试牛刀。本次大促同层渲染播放器的能力让业务尝到甜头，结合今年直播带货的火爆，后续手淘大量业务将会更积极拥抱 PHA 使用同层渲染播放器能力，对于我们而言，如何把握住风口将播放器大力发展走在业务前头，驱动业务发展是主要目标。
同层渲染播放器后续将会持续发展，提升播放体验、直播互动能力：
降低接入标准，覆盖全量环境，业务0成本接入；
打造端内体验对标客户端直播间的 H5 直播间，应对业务的快速迭代；
提升会场播放器播放体验，带来更多 GMV 转换；
未来直播互动游戏打造；
以同层渲染播放器为钩子，技术能力完善驱动业务能力升级，全面发展多媒体业务多点开花。
NO.7
关于我们
我们是淘系多媒体前端团队，主要负责淘宝直播、短视频等多媒体业务，在直播低延时推拉流、视频非线编、播放器、媒体智能、流媒体互动、多媒体开放等方向上持续研究和实践，专注于音视频Web技术的研究，致力于打造国内顶尖的多媒体前端技术团队。
如果对我们团队感兴趣，欢迎来信交流 joven.panj@alibaba-inc.com
推荐阅读
1. 618大促背后的淘系前端技术体系 | 618 淘系前端技术分享
文末福利
关注后回复“藏经阁”
喜欢就点在看哦〜