LinkedIn Feed流視訊自動播放架構演進

為提升使用者觀看體驗，LinkedIn視訊團隊一直努力完善其視訊自動播放功能。本文概述了LinkedIn自動播放產品標準，以及為實現此標準所開發的技術與架構。

文/ Evan Farina

譯/ 元寶

審校/ John

原文 

https://engineering.linkedin.com/blog/2019/03/feature-highlight--scaling-autoplay-videos-for-hundreds-of-milli

我們的視訊團隊始終致力於提升使用者觀看視訊體驗。在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構建的自動播放功能看似十分複雜，實際上是基於網路頻寬、瀏覽器渲染週期、網站互動裝置等環環相扣實現的結果。這直接關係著我們的會員瀏覽視訊時的使用者體驗，如果使用得當，自動播放功能可以極大提升網站訪問者的參與度。因為二十一世紀的網路使用者渴望海量內容高效呈現在眼前，而視訊便是實現這種效果的絕佳媒介。通過視訊向我們的成員提供大量的高質量內容，需要一個這樣的整體效能解決方案提供技術支援，我們期待此功能可為使用者帶來高質量視訊播放互動體驗的同時為企業帶來收益與積極影響。

點選【閱讀原文】或掃描圖中二維碼瞭解LiveVideoStackCon 2019 上海 音視訊技術大會 最新日程資訊。