文/ Evan Farina
译/ 元宝
审校/ John
原文
我们的视频团队始终致力于提升用户观看视频体验。在2016年底，LinkedIn的视频功能还处于雏形阶段，包括自动播放在内的一系列功能仍未成为现实。两年过去了，虽然自动播放已经成为LinkedIn实现良好视频播放体验的一个不可或缺的部分，但由于复杂的产品需求与遗留的性能问题，这一功能仍待我们去完善。本文将概述我们的自动播放产品标准和工程师为支持这一标准所开发的技术与架构，还有我们在构建这个可承载数亿规模用户的自动播放解决方案时遇到的一系列性能挑战。
技术用词
这篇文章将引用下列前端技术，关键词及定义如下：
- iframe： iframe是一个可以在其自身内部呈现外部网页内容的元素。在LinkedIn，我们借助iframe实现将来自第三方域名（YouTube、Vimeo）的视频直接呈现于LinkedIn网站。
- 播放窗口（或“视觉重点窗口”）：用户直接看到的播放视频的窗口。
- Spaniel： LinkedIn的内部解决方案，用于跟踪元素进出Viewport时的情况。
- postMessage： postMessage是一种本机浏览器技术，它允许不同域上的两个网站相互通信。本质上，我们使用postMessage与第三方域提供的视频API进行交互。
- 发布-订阅（pub-sub）模式：应用程序所使用的通信模式，其中的程序化事件并不会发送给特定订阅者，而是在不知道应用程序中有哪些组件可能订阅事件的情况下盲目地发出。
- 去抖动：在给定时间范围内，限制对特定方法的调用次数。多用于处理可能导致网页出现问题的特殊用户交互行为（例如，快速滚动页面）。
- DOM：将web页面表示为由许多内容节点组成的树。
产品标准
从工程和产品角度来看，自动播放是我们视频团队所构建的最复杂的功能之一，自动播放的关键在于细节上确保万无一失。为实现这一点我们着重关注了以下几个关键标准：
- 一次只能播放一个视频;
- 一般情况下，自动播放的视频应该在退出播放窗口时暂停（如果用户人为调整窗口则应遵循此规则;与此有关的更多内容在后面会介绍到）;
- 当用户与视频或其窗口中的任何控件进行交互时，视频应当继续保持有声播放的状态，即便退出播放窗口时也不应暂停播放视频。
架构概述
LinkedIn的自动播放架构有以下四个关键部分组成：
- HTML5视频：这是浏览器播放视频源文件的主要执行方式。
- 视频管理器：一个负责跟踪正在播放的视频并判断其声音是否正常播放的独立组件。视频管理器通过事件加载组件(使用pub-sub模式)控制哪些视频应该被播放。
- 视频包装器：一个JavaScript项目，用于包装HTML5视频并与视频管理器的公共API交换数据，同时控制视频管理器加载正确的视频文件。
- 播放窗口管理：我们使用Spaniel跟踪移入或移出播放窗口的视频元素。播放窗口管理在我们的每个媒体加载策略里都扮演着至关重要角色，也是我们接下来着重介绍的一部分。
用户体验方面的考虑因素
自动播放是一项复杂的功能，开发者需对其有十分透彻的了解。从用户角度出发，实现出色的自动播放交互体验需要考虑很多因素，以下是我们在构建此功能时考虑到的几个可直接影响用户体验的关键因素。
关注情景
LinkedIn.com上的大量视频都基于其特定情景而存在——播放视频的情景可能是Feed流、私人消息甚至学习播放列表......我们需要分析每种情景分别有哪些关键因素影响用户播放体验，而每个人对于网页上元素的认知与交互策略都是不同的。当视频处于Feed流情景时，如何同时管理一系列视频成为亟待我们解决的关键挑战；而当视频被用于学习情景时，一些用户既希望视频自动播放时保持静音，也希望在与视频发生互动时取消静音。对此我们制定了以下策略从而妥善解决该问题：在LinkedIn的学习应用程序中，播放列表加载视频，下一个连续播放的视频需要参考上一个播放视频的音量参数。深入研究用户与视频进行交互时所处的各种情景，并为每种情景量身定制自动播放解决方案是实现良好播放体验至关重要的条件。
播放窗口
在桌面端的LinkedIn 视频Feed流情景下，视频会在用户浏览至播放窗口时迅速播放并在滑出播放窗口时暂停。如果视频处于有声播放的状态则不适用于此项策略：当视频处于有声播放时，只有当用户对视频内容表现出足够的兴趣并希望在滚动视频Feed流时继续播放此视频，我们才会允许其在后台继续播放。
人性化设置调整
鉴于自动播放可能对某些用户的使用体验带来负面影响，允许用户关闭自动播放功能是至关重要的，在LinkedIn上我们为会员开放了禁用自动播放功能的权限。
网站性能
视频的背后是海量的数据，数据下载的性能直接关系到视频播放的效果。考虑到网络的带宽限制与桌面端浏览器的各种限制，调用过多资源优化视频下载性能可能会导致网页上其他资源的加载性能迅速下降。因此，我们必须将优化网站整体性能摆在优化自动播放策略之前，接下来我们将深入探讨此话题。
性能方面的考虑因素
我们的视频团队不断调整视频加载活动优化算法的介入积极性。一方面，我们希望优先下载视频内容以减少会员在等待视频缓冲上浪费的时间；另一方面，鉴于视频资源背后庞大的数据量，我们需要确保从服务器请求视频资源的过程不会为用户的网络带来过多负担；同时，随着单一网页上的视频数量的增加，大量视频资源与其背后的海量数据会明显加重网络带宽的压力；我们不仅需要考虑客户一端向服务器请求的总数据量，更应考虑数据下载的时间范围，同时掌握浏览器对高并发网络数据请求的限制。
接下来我们将进一步探究上述内容。
网络带宽
网络带宽资源优劣取决于以下几个因素：
- 位置：不同地区的互联网基础设施水平存在差异。2017年第一季度的Akamai互联网报告便指出，印度的平均连接速度为6.5 Mbps，而当时美国的平均连接速度为18.7 Mbps。在设计自动播放解决方案时，我们一定要考虑处于带宽资源不佳区域的会员并对其提供特别优化，避免由于用户浏览至视频播放窗口时使用大量带宽资源下载视频对有限网络资源的过度消耗。
- 连接类型：考虑不同的连接类型。其中的连接类型是指会员连接至互联网的方式（以太网、Wi-Fi或移动数据）。我们不仅需要将连接类型作为造成不同用户在连接速度上出现差异的因素，还应避免视频的自动下载活动造成用户移动数据流量的过度消耗从而为用户带来不必要的资费困扰。
- 设备类型：人们可以通过自己的任何设备连接互联网，无论是手表、手机、平板电脑还是台式电脑。用户使用不同类型的设备观看视频，自动播放体验也会存在一定差异，这里我们需要着重关注由性能、兼容性等因素导致的不同设备所能处理的并发网络请求规模的差异。在使用自动播放功能的情景下，我们不使用后台加载视频的策略以避免网络拥塞；相反，我们会优先下载当前处于播放窗口的视频数据以确保用户浏览至播放窗口时视频自动播放的成功与及时。
总结优化策略：
- 为会员提供视频自动播放的个性化定制设置（例如，移动设备上的会员可选择仅在设备连接Wi-Fi网络时允许视频自动播放）。
- 排队加载。这是一种借助排队系统加载视频的策略。该系统避免页面同时下载多个视频，并将加载视频的优先级置于加载页面其他元素之下。
移动数据流量计划
尽管许多用户会选择使用他们的移动数据流量来浏览LinkedIn，我们也要清晰意识到加载视频会快速消耗大量移动数据流量的事实。因此，默认情况下，只有在移动设备连接至无线网络时客户端才会开启自动播放；除此之外，处于移动网络环境下客户端只有在用户主动滑动页面至下一个视频时才开始加载数据。
滚动性能
如果网站包含诸如RSS订阅源这样需要用户滚动浏览的长页面，网页的滚动性能便是影响用户浏览视频内容的关键因素。鉴于滚动事件的触发与响应速度非常快，了解在滚动事件处理程序中，执行DOM操作对整个页面加载性能的影响至关重要。浏览器会在两个周期内完成大部分网页渲染工作：回流和重绘。正如Google在本文中所提到的那样，回流计算页面的布局会在更改CSS样式与移动DOM节点并发生滚动事件的情况下发生改变。另一方面，当网页样式的改变影响到DOM节点的视觉外观，同时节点的布局与屏幕上元素的位置不发生改变时，浏览器会进行重绘操作。浏览器的目标是限制回流与重绘的次数，使用原生RequestAnimationFrame方法可确保多个回流和重绘的批量循环处理。
考虑到上述情况，让我们来看看滚动页面会对页面的渲染性能产生怎样的负面影响。当用户滚动浏览器页面时，浏览器*重新计算随着页面滚动带来的DOM节点的移动与布局改变；如果在滚动事件的处理程序中改变DOM节点，那么浏览器将再次*重新绘制页面，这会导致滚动事件处理程序执行DOM操作的成本显著提高，同时导致视觉衰减（也被称为布局抖动）情况的发生。
为避免浏览器承受过大运算压力，请务必去除滚动事件并确保只有当页面停止滚动时才会进行回流而非每次滚动页面时进行回流。
视频加载策略
当我们制定视频加载策略时，如果您希望确保所有用户在您的网站上都拥有最佳的用户体验，那么重点关注前文所介绍的诸多影响性能的因素至关重要。接下来我们将就LinkedIn对一些功能的测试深入探讨每项实验功能的优劣。每一个精心设计的实验都将视频加载时间与网站整体性能作为关注重点。
快速加载DOM中的所有视频
积极地加载LinkedIn Feed中的视频
在LinkedIn中，我们已经尝试了积极与消极的视频加载策略。积极的视频加载策略是指进入DOM后立即开始下载视频；与其不同的是，消极的视频加载策略是指在视频进入播放窗口之前不会加载视频。在积极的视频加载策略中，视频基本上会在后台进行加载。
积极策略的好处是视频将在后台完成大部分或全部缓冲工作。后台加载的内容越多，视频进入播放窗口后需要加载的内容就越少。因此，与没有采取积极策略加载的视频相比，预先加载的视频在播放窗口中的缓冲时间更少。
但在连接速度相对较慢的情况下，积极加载视频的缺点最为明显。当我们在后台下载视频资源时，允许播放窗口下载视频数据的可用带宽较少；除了带宽问题之外，移动设备和桌面设备上的浏览器能够并行处理的HTTP请求数量十分有限。视频加载占用大量后台资源，可能会导致播放窗口中的内容加载出现延迟。
最重要的是，在上图中，一旦视频元素附加到DOM，无论视频元素是否已经进入播放窗口，网页都会加载所有三个视频。
有限队列加载
使用有限队列在LinkedIn Feed中加载视频
有限队列加载系统通过限制可以快速加载的视频数量，解决了无限制快速加载（高带宽和HTTP请求使用）和无限制队列系统（高HTTP请求使用）的缺陷。
虽然有限队列系统继承了无限队列加载系统的部分优势，但由于系统限制了后台可加载视频数量，其优势并不如无限队列加载系统般明显。
有限队列系统的缺点在于限制了后台加载视频的数量，如果会员处于高质量网络带宽，同时网页包含比队列所允许的最大加载数量还要多的视频，此项缺点尤其明显。
无限队列加载
使用无限队列在LinkedIn Feed中加载视频
队列系统旨在允许开发者与用户从快速加载的优势中获益，同时我们还需考虑其缺点。队列系统的工作原理是将页面上的所有视频添加到队列中，无论其是否在视频窗口中，浏览器按照添加顺序加载队列中的每个视频。虽然队列可同时存在多个视频，但系统每次只允许加载一个视频从而确保视频加载庞大的数据量不会阻塞浏览器可用的HTTP连接。
队列加载系统的一项优势在于可以快速地加载播放窗口外部的视频（如，在后台），允许视频在进入播放窗口时几乎不发生缓冲。
当然，无限加载队列的一个潜在缺点是在某些情况下，如果会员的订阅源包含大量视频的更新活动，网页可能会要求浏览器在很短的时间内下载大量数据。对于网络连接较弱的会员，这可能会导致观看体验不佳并对页面加载时间产生负面影响。
最重要的是，在上图中，这三个视频都有机会快速加载；然而视频不会被并行加载而首屏内容会被优先加载。我们发现，无限加载队列为我们的会员实现了用户体验和性能的最佳平衡。
结论
尽管LinkedIn构建的自动播放功能看似十分复杂，实际上是基于网络带宽、浏览器渲染周期、网站交互设备等环环相扣实现的结果。这直接关系着我们的会员浏览视频时的用户体验，如果使用得当，自动播放功能可以极大提升网站访问者的参与度。因为二十一世纪的网络用户渴望海量内容高效呈现在眼前，而视频便是实现这种效果的绝佳媒介。通过视频向我们的成员提供大量的高质量内容，需要一个这样的整体性能解决方案提供技术支持，我们期待此功能可为用户带来高质量视频播放交互体验的同时为企业带来收益与积极影响。
————————————————
版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/88729960
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。