Categories
程式開發

愛奇藝知識的音視頻通用播放架構實踐


導讀

隨著經濟的發展“衣食住行”等基礎消費已不再是消費者首要考量,自我認知的提高便成為現階段消費的必然選擇。尤其是在移動互聯網崛起的當下,移動支付和不限流業務的普及,人們為他們感興趣的內容或知識買單的行為逐漸養成,為知識服務平台商業價值打下基礎。

早期的知識服務類平台大多以音頻形式為主,因播放形式比較單一,對架構技術場景的要求也較為簡單,隨著內容消費的升級,知識服務平台的展現形式更加豐富,視頻類消費逐漸成為行業共識,為了滿足用戶的多種需求,早期音頻起家的知識服務類平台開始陸續切入視頻,這樣的音頻、視頻混雜的多場景的播放體驗及場景間的平滑切換逐漸成為了行業內面臨的技術挑戰。

愛奇藝知識技術團隊較早就開始針對兼顧音視頻播放架構進行思考、通過實踐開發出一套音視頻播放的通用架構,支持更豐富的音視頻場景體驗,有效解決了行業內面臨的技術挑戰,本文將分享愛奇藝知識音視頻通用播放架構的實踐。

愛奇藝知識播放業務產品形態

愛奇藝知識的音視頻通用播放架構實踐 1

愛奇藝知識的音視頻通用播放架構實踐 2

愛奇藝知識的音視頻通用播放架構實踐 3

從上面產品形態效果圖可以看出,愛奇藝知識播放器支持視頻窗口、音頻窗口、視頻浮窗、音頻浮窗、短視頻窗口、短視頻浮窗、音頻控制台等多種場景播放,並且可以根據需要在保持播放的平滑流暢的同時隨時切換。

上述多場景播放的產品形態在技術實現上的最大挑戰是是多個播放場景的平滑切換,也就是說在播放一個內容時很難在不影響播放器的狀態的情況下音視頻場景隨意切換,這就面臨著無法保證用戶的持續流暢的視聽體驗的問題。愛奇藝知識技術團隊開發了一套通用播放架構,其支持以下特性:

1)支持多種音視頻融合場景,以及新的音視頻場景快速接入;

2)場景之間的切換不會引起播放器狀態的變化,即播放器的播放狀態對場景的切換無感知。

音視頻通用播放架構

為了支持多場景融合以及播放器對場景的無感知切換,這套通用播放架構要具備以下特點:

1)播放器與播放業務解耦: 支持更多的播放場景、以及新的播放業務快速接入,並且不影響其他播放業務;

2)播放器與播放SDK解耦: 支持第三方內容和SDK接入: 提供強大內容拓展性,保證接入第三方內容現有的播放業務不需要調整;

3)播放器與分發頁面解耦: 播放器存在於App全局,可以出現在任何展示頁面,不影響用戶瀏覽。

愛奇藝知識的音視頻通用播放架構實踐 4

架構的介紹:

  1. 基礎播放SDK:提供基礎的播放功能,對外輸出音視頻效果;

  2. 統一播放器:屏蔽底層播放SDK差異,根據協議為上層提供統一的播放能力接口;

  3. 播放業務管理器 : 負責播放業務的調度、解除播放業務與播放器的耦合;

  4. 播放場景業務:負責向用戶展示音視頻播放能力和交互的業務;

  5. 播放關聯業務: 為播放器提供增值或支撐的業務。

3.1 播放器與播放業務的解耦

3.1.1 播放器與播放業務耦合的弊端

從愛奇藝知識播放器的產品形態可以看到,播放器可支持多種場景下的播放,一個內容的周期內必須使用同一個播放器,這樣就會帶來一個問題,一個播放業務播放器狀態發生變化,其他播放業務必須同步更新播放狀態,各個播放業務之間互相交叉,隨著播放業務的增多,開發和維護成本會急劇增加, 導致後續開發不可持續。

3.1.2 播放器與播放業務的解耦方案

播放狀態變化是導致不同播放業務場景之間交叉同步的原因,新的解耦方案需要解除播放業務對播放器的直接操控,採用觀察者模式對播放業務和播放器進行解耦,設計思路如下:

1、播放業務管理器

1)作為被觀察者為各個播放業務分發播放器的狀態變化;

2)為各個播放業務提供基礎的播放操控和數據訪問接口。

2、播放業務

1)作為觀察者接收播放器的狀態變化,更新關聯的播放狀態和數據;

2)接收用戶操作,通過播放業務管理器對播放器進行操控。

愛奇藝知識的音視頻通用播放架構實踐 5

目前愛奇藝知識播放業務都是以模塊的形式註入到播放器業務管理器,業務模塊只負責觀察調用播放業務管理器。不直接持有播放器實例。解除了播放業務與播放器的耦合。

3.2 播放器與播放sdk解耦

愛奇藝知識除了涵蓋愛奇藝自身生產的內容外,也會接入“喜馬拉雅”、“蜻蜓FM”等第三方合作方的內容。由於每家合作方播放SDK提供的API都不一樣,如果業務層對每個合作方都進行業務開發,就會導致業務量非常龐大,並且不同合作的方的播放SDK會產生交叉,不利於播放業務的維護和拓展。同時開發量指數增長,無法滿足第三方合作快速上線的需求。

為了避免業務層單獨適配第三放播放SDK,需要對業務層和第三方播放SDK進行解耦操作。即上層業務對接入第三方合作方的播放SDK是無感知的。解耦方案設計如下:

1)設計統一播放協議,對於上層播放業務,只調用按照統一協議設計接口,不必關心底層播放器的設計邏輯。保證上層播放業務不隨新的接入播放SDK發生變化。

2)愛奇藝播放SDK和第三方播放SDK按照統一協議進行適配,提供基本的播放接口。保證上層業務對具體播放SDK無感知。

3.2.1解耦設計實現:

愛奇藝知識的音視頻通用播放架構實踐 6

在解耦設計實現中,播放SDK適配器實現的核心:

1)對於上層業務,播放SDK適配器對上層業務輸出標準的播放、暫停、快進等接口;

2)對於底層基礎SDK,播放SDK適配器負責分發具體播放SDK,並適配其播放、暫停、快進等接口。

由於播放器和播放SDK實現解耦,愛奇藝知識App在不改變上層業務的情況下集成了喜馬拉雅和蜻蜓第三方音頻內容。避免了上層業務修改帶來的工作量,大大加快的第三方內容的接入速度。

3.3 播放器與分發頁面解耦

目前市面上很多視頻應用退出詳情頁,視頻播放就會被終止,這樣就不能為用戶提供持續平滑的播放體驗。為了打造極致播放體驗,愛奇藝知識App支持不同頁面間切換時播放器持續平滑播放。

3.3.1 播放器持續平滑播放方案選擇

播放器持續平滑方案主要涉及三種:

1)畫中畫方案:雖然Android8.0及其以上版本已提供了畫中畫方案,但是 Android8.0以下版本仍然保有大量用戶,其缺點就是無法滿足Android8.0以下用戶需;

2)採用系統浮層:採用系統浮層需要係統浮層權限,Android廠商對系統浮層的授權越來越嚴格,導致用戶授權過程的體驗比較差;

3)在每個展示頁面單獨添加播放器浮窗:優點是不受Android系統版本限制,並且用戶無需系統浮層權限授權,適合所有手機用戶,體驗較好。

為了更好支持用戶體驗,我們選用了第三種方案。

3.3.2 展示頁面單獨添加播放器浮窗的弊端

展示頁面單獨添加播放器浮層方案雖然對用戶比較友好,但是開發成本較高,每個頁面都有可能中承載播放器並與播放器生命週期聯動,播放器與每個頁面耦合,開發成本和頁面數量成正比。不利於後期維護。因此我們在此思路的基礎上做了解耦設計和架構改造。

3.3.3 播放器與展示頁面解耦設計:

採用非侵入式方案,設計思想如下:

  1. 通過底層劫持展示頁面的生命週期處理,處理播放器生命週期, 解除播放器與展示頁面的生命週期耦合。

  2. 設計透明容器作為音視頻浮窗的容器,展示頁面可見時將透明容器嵌入到展示頁面的根佈局容器中,實現短視頻浮窗展示頁面的解耦。

非侵入式頁面切換方案調度圖如下所示:

愛奇藝知識的音視頻通用播放架構實踐 7

從調度圖可以看出,播放器頁面間切換和生命週期的控制邏輯由“生命週期劫持模塊”負責,與展示頁面解耦。

目前愛奇藝知識App,新增加的頁面不需要添視頻條容器即可實現視頻條的展示,新頁面的開發者不需要關注視頻條邏輯,降低了開發工作量。

總結與展望

愛奇藝知識為用戶打造極致的音視頻播放體驗出發,自主研發設計了一套通用的音視頻播放架構,能夠有效的支持多種場景播放需求,可實現第三方內容的快速接入,極大提升了用戶體驗。提升播放器性能並支持更多的播放場景是播放器開發者一直面對的問題。愛奇藝知識技術團隊通過不斷的技術創新,賦予用戶更優質的播放能力和體驗。

作者介紹

本文轉載自公眾號愛奇藝技術產品團隊(ID:iQIYI-TP)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI0MjczMjM2NA==&mid=2247486671&idx=1&sn=78bb2087b673a00c600da9b7bd1e6e43&chksm=e97690ecde0119fa9c65dfaf95d713931b78cb26463edb12659f8c80ceeca836d1be6090aa68&scene=27#wechat_redirect