作者| 阿里文娛無線開發專家 韋興華
一、背景
作為優酷 APP 中用戶使用頻度最高、停留時間最長的窗口，播放器一直以來都承載著用戶 最直接的內容消費體驗、產品創新、業務突破能力。隨著長時間的功能迭代和業務累加，播放 器架構在面對現有的體驗優化和業務支撐上，越來越顯得力不從心，亟需一次全面的架構升級。
經過多方權衡，最終確定基於 Pipeline 模式進行播放器的架構設計，達到易用、開放、可定製，同時具備清晰的結構、低功耗和良好穩定性的架構改造目標。
二、設計目標
結合問題的現狀，改造的目標如下：
1）減少部分播放鏈條中的冗餘邏輯，減少函數調用數，減少鏈路層次，提升起播速度；
2）統一內存、文件的多份存儲，提升解碼、渲染的複用度，可以降低播放器內存、線程等資源消耗，提升穩定性；
3）將播放源、數據下載、後處理等模塊的實現開放化和可定製化，讓業務可以根據需求自 行在播放鏈路中插入和實現功能邏輯，實現業務的定製化能力；
4）從整體播放中心的角度思考，優化架構，以便支撐可預見的多源、多流的業務需求，快 速擴展，及時響應業務；
5）實現下載器、解碼器、渲染引擎、PCDN、Netcache、智能檔等功能模塊的原子化，降低模塊間的耦合，方便對外輸出，並逐步實現單測覆蓋。
三、面臨的問題
如下圖，通過分析現有的結構，比較容易看出目前存在的問題：
1）層次過多，一些功能和狀態代碼散落在不同的層次中，導致可維護性不夠。
2）核心播放邏輯和業務定製邏輯耦合較重，導致對外支撐和向二、三方開放時接口易用性 不夠，可配置化能力不足。
3）開放性和擴展性不足，對於需要深度定製的接入方，沒有快速的方式對下載、後處理等 流程進行干預，對於合流、切流、混幀等特異化處理也沒有統一的開放能力透出。
四、方案設計
1.整體設計
通過梳理，一個播放流程可以抽象為“播放源請求”、“流數據下載”、“流解碼”、“後處理和 渲染”幾個主要的過程，以及“數據埋點中心”“配置中心”等配套設施。在整體架構上，將原來多 個層次的實現合併到一個統一的播放框架中，將播放能力和基礎業務原子化插件化，由播放框 架統一管理並提供可配置化能力。
在開放和擴展性的支持上，將以上的幾個主要流程抽象成“播放源管理器”、“數據下載器”、 “渲染器”並提供統一的定製化開發能力，並提供自適應的解碼能力，以滿足未來業務創新上對 合流、切流、混幀和後處理的特異化開發需求。
2.統一播放框架
播放框架層負責統一管理和串聯各個模塊，同時對外部提供統一的 API 接口。如圖所示，
1）接口層提供基礎的播放上下行消息、管線註冊、模塊配置等接口；
2）狀態管理、上下文管 理、時間軸管理和多實例管理模塊，可以支持多 Period 和多 Source 的播放序列，以方便業務方 能夠快速實現可變格式播放源合併、切流等業務；
3）實例池模塊可以結合設備和可用資源自適應的管理解碼器實例，保證穩定性和體驗的平衡；
4）管線管理模塊負責管線註冊和管線綁定邏輯；
5）插件管理模塊支持一些定製能力的內部實現，內置一些優酷業務能力並支持可配置能力。
3.播放源管理
播放源管理模塊抽象了一個 PlayList 結構，用於支持業務方能夠方便的實現不同格式和編 碼方式的播放源合併、播放序列管理、切流等業務。 主要結構如下圖，其中 PlayList 是一個總 播放序列；其下的每個 Period 節點表示一個統一的時間軸播放序列，其下的所有 source 會合並 成一個時間軸，比如由 4 個 15 秒的視頻合併成的一組 60s 貼片廣告；每個 Period 下可以掛載多 個 source，這些 source 可以支持相同或者不同格式、不同編碼參數的視頻組合。在播放過程中， 允許動態的切換當前 Peroid，或者修改後續 Peroid 的順序。
4.緩存管線
緩存處理採用多級管線的處理，業務方可以根據自己的場景通過緩存中間件和緩存過濾器 的定製實現，來滿足針對性的數據下載優化。在優酷播放場景中，針對網絡請求和本地存儲實 現了 NetCache 和 PCDN 兩個緩存過濾器，具體如下圖所示：
1）將資源存儲分為三級緩存管理，由緩存管線進行調度管理；
2）業務可以通過參數自定義選擇使用混合層級的緩存；
3）緩存管線針對不同資源，讀取或寫入存儲時分別通過訪問 NetCache 或 PCDN 模塊進 行處理；
4）未來本地磁盤存儲除預覽需求外，希望統一採用PCDN 存儲方式存儲，以提升 PCDN的分享率，有效的降低成本。
5.渲染管線
後處理和渲染同樣採用多級管線的處理。渲染管線模塊提供多個渲染 Context 支持，每個 Context 綁定一個解碼器和一個渲染窗口，並自動對同一個渲染窗口的多個 Context 的渲染結果 進行合併和上屏。業務方可以通過實現渲染中間件和渲染過濾器來進行定製化的開發，以進行 諸如混流、混幀、視頻特效等特異化開發來滿足業務和創新需求。
五、思考和總結
播放器以及端側播放鏈路是一個龐大而複雜、且綜合性很強的系統，尤其在優酷這樣的重 視頻場景消費的產品中，播放器承載的業務會隨著時間不斷增長。如果沒有一個相對合理穩定 的架構設計，在長時間迭代之後整個系統的複雜度是不可想象的。在本次架構改造中，我們首 先抽取播放的核心過程作為整個架構的基礎，把播放中心已經積累的能力模塊化原子化，通過 統一的播放框架組織起來，同時結合未來業務的創新和發展方向，對外開放了統一的定製化開 發能力，基本實現了預期的改造目標。
當然播放框架的改造並不是一蹴而就的，未來在核心框架穩定的前提下，還需要繼續推進 諸如端側數據中心、端側 AI、全鏈路監控等配套基礎設施的建設。同時隨著 5G 技術的發展， 如何將端側和邊緣結點打通，如何在端、邊、雲上做到計算資源的最大化利用，也是播放框架 需要思考和嘗試的方向。