2020年618大促已經過去，作為淘系每年重要的大促活動，淘系前端在其中扮演着什麼樣的角色，如何保證大促的平穩進行？又在其中應用了哪些新技術？淘系前端團隊特此推出「618 系列|淘系前端技術分享」，為大家介紹 618 中的前端身影。
本篇的作者是淘系技術部進階前端工程師 葉序，為大家介紹億級使用者高穩定性視訊播放器養成計劃
001
《618 大促背後的淘系前端技術體系》002
《生産力再提速，618 互動項目進化之路》003
《淘寶大促頁面性能監控和優化實踐》背景
PHA 架構的優秀性能讓大量業務、會場開始逐漸轉用 H5，但同時帶來了一些挑戰。以多媒體日常短視訊/直播業務為例，H5 原生的播放器的穩定性、性能、播放能力支援均難以達到使用标準，在 H5 環境下沒有一個業務可用的 H5 播放器。這時候就需要一個 H5 上能夠流暢播放的播放器。
先提前體驗一下618期間，H5 下播放器能力：
618 期間戰果：618主會場，猜你喜歡，直播會場，聚劃算百億補貼、行業會場。
同層渲染播放器方案設計
也許你之前不了解什麼是同層渲染？
同層渲染，是允許将 Native 元件和 WebView DOM 元素混合在一起進行渲染的技術，能夠保證 Native 元件和 DOM 元素體感一緻，渲染層級、滾動感受、觸摸事件等方面幾乎沒有差別。
綜合了性能、穩定性、易用性、靈活性上考慮，我們選擇了同層渲染這種技術方案，以此渲染手淘 H5 下播放器。
底層 Native 播放器 擁有一套健全的播放能力，在早期 weex 及 Native 下，均有不俗表現。經過多年沉澱，api健全、性能穩定性良好，Naitive 播放器能力已達到業務可用的标準。
在此基礎上，需要針對 Native 播放器 做一層同層渲染元件的封裝處理以适用于 webview（iOS wkwebview，android UC 核心）上播放器的同層渲染。用戶端封裝元件 層需要監聽同層渲染事件通知，在接收到建立/銷毀消息時，執行個體化/銷毀播放器。
監聽的依賴于中間的 通信層，淘系基礎架構團隊針對同層渲染的元件做了監聽：在同層渲染元件建立
節點時，通知到用戶端播放器執行個體化渲染。
業務層播放器封裝，使用了 @ali/rax-composite-view-factory 同層元件渲染工廠方法，該庫将元件渲染成
節點，當 節點渲染出來時，前端會通知到監聽層需要渲染何種元件，此時監聽層收到後通知到用戶端元件，用戶端完成渲染，并持續接收來自前端的事件監聽。(iOS 通過 element.addEventListener 通信，Android 通過 WindVane 通信)。
▐ Videoplus
從業務角度來說，視訊播放主要分為兩種：直播和點播。
其中，直播中區分：直播流、回放、看點，點播則是視訊播放形式。
從圖中可以看到，對于如此複雜度的播放要求，在此之前，僅在weex和web端下針對複雜業務的播放器支援。手淘内在PHA(即手淘H5)場景下，沒有一個适用的播放器。
618前視訊元件支援情況：
Videoplus 是端内針對多場景播放器的一個元件，該元件在對不同場景下的播放器進行了抹平處理，對使用者來說，無需關注目前場景，隻關注播放器本身即可。
✎ 播放場景抹平：Videoplus 針對環境做了一層抹平處理，不同場景使用不同的播放器，本次 618 新增同層渲染播放器，能力上更加完善。
- weex：使用 weex 底層封裝的播放器
- 手淘 H5：使用同層渲染播放器播放3、外部 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 播放器隊列中選擇最佳位置(居中)的開始播放。
穩定性保障方案
Videoplus 提供了多元度的降級能力，通過手淘 mt 配置降級方案。在大促期間，在預案平台提前報備。
Videoplus 的播放能力整體系分為以下幾個次元：
- 全量降級終極兜底方案，開啟後，所有 Videoplus 播放器強制降級成 poster。
- 播放器場景降級方案（H5/weex/PHA）支援 H5/weex/PHA 場景，對應場景（直播或者點播）播放器出現意想不到的情況時應急采用。H5/weex/PHA場景分别帶有：1、禁用直播2、禁用視訊
- 指定bizFrom降級方案在某一業務使用播放器時發生問題時，兜底使用。當開發業務接入播放器時，需要傳入唯一業務指定 bizFrom，具體需要到播放器管理者處申請，如果未傳入值，則播放器不可使用。可直接指定某項業務(bizFrom)關閉播放功能，一旦關閉，直播和視訊在該業務場景下不可使用。
- 指定用戶端/用戶端版本号使用指定用戶端版本及版本号使用。在手淘及天貓用戶端版本中，如果播放器被發現某些bug，可通過此開關降級。粒度控制到三位版本号，例如手淘 10.0.0 版本。
- 指定作業系統版本号此場景由于某些作業系統及版本下播放器出現問題，粒度控制到三位版本号，例如 iOS 10.0.0 版本。
大促技術和業務表現
淘系技術部 Native 播放器核心的多年沉澱，Native 底層播放器處于穩定狀态。相較 H5 播放器來說，Native 播放器支援格式更廣、解碼能力更優、性能體驗極佳，但靈活能力不足。基于 Native 播放器的同層渲染播放器，在體驗上與 Native 播放器達到達到持平狀态的同時，靈活能力兼具。
▐ H5的播放器 vs 同層渲染播放器
▐ 618 戰果
業務資料：6 個以上618子產品(行業、直播1x2、猜你喜歡、頭圖等)接入，服務超過 200 個以上會場。
技術表現：sls大盤監控底層播放器成功率99%以上；用戶端監控穩定無 crash 新增，無故障，無復原降級，整體灰階順利。
同層渲染播放器遇到的問題
問題：前端移除
之後，PHA Tab切換挂起webview，導緻異步操作失效未将播放器執行個體銷毀，主會場頭圖/猜你喜歡子產品、行業商品子產品、直播會場1x2子產品。
解法：播放器監聽PHA 頁面 disappear，強制停止播放，并forceUpdate同步銷毀播放器解決此問題
問題：Splayer的複雜使用場景，在1x2 子產品播放器視訊切換過快情況下，消失動畫延時，封面圖移除時機出錯導緻出現白窗
解法：調整底層播放器封面圖移除時機，在播放前移除。
未來規劃
對于本次 618 的實驗與應用，同層渲染播放器僅僅是小試牛刀。本次大促同層渲染播放器的能力讓業務嘗到甜頭，結合今年直播帶貨的火爆，後續手淘大量業務将會更積極擁抱 PHA 使用同層渲染播放器能力，對于我們而言，如何把握住風口将播放器大力發展走在業務前頭，驅動業務發展是主要目标。
同層渲染播放器後續将會持續發展，提升播放體驗、直播互動能力：
1，降低接入标準，覆寫全量環境，業務0成本接入；
2，打造端内體驗對标用戶端直播間的 H5 直播間，應對業務的快速疊代；
3，提升會場播放器播放體驗，帶來更多 GMV 轉換；
4，未來直播互動遊戲打造；
以同層渲染播放器為鈎子，技術能力完善驅動業務能力更新，全面發展多媒體業務多點開花。
淘系前端團隊
主要負責淘寶直播、短視訊等多媒體業務，在直播低延時推拉流、視訊非線編、播放器、媒體智能、流媒體互動、多媒體開放等方向上持續研究和實踐，專注于音視訊Web技術的研究，緻力于打造國内頂尖的多媒體前端技術團隊。
如果對我們團隊感興趣，歡迎來信交流📮：[email protected]
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~