作者| 阿裡文娛技術專家 翠姝
一、設計背景
音視訊播放器的工作内容可以描述為：根據流媒體協定還原音視訊内容的過程。在還原的 每個階段都存在丢失精度的風險，而最終呈現的結果也是一個主觀的内容，這就給播放器輸出結果的評估引入了一些痛點問題，可以列舉如下：
測試階段：
1）人工黑盒測試無法覆寫線上海量機型以及實際複雜的使用環境，定位問題的精準度高卻 無法大規模應用；
2）自動化測試雖然可以覆寫較多機型，枚舉各種測試用例卻無法發現（或代價很高）類似 音畫不同步，畫面異常等問題，而通常這些問題才是影響使用者使用的點。目前測試現狀可以概括為更多的給出了功能次元的播放器品質，缺乏技術次元描述。
線上監控階段：
1）目前描述播放品質的 QOS 名額次元包括卡頓率，成功率，crash 率等，這些名額非常重要,但是對于描述使用者可能會遇到的播放器異常來說是不夠的；
2）除去上述的技術名額，線上異常多由客訴或輿情驅動，而客訴多是暴露顯性問題，那些 暗藏的隐形問題，使用者根本不會告訴我們，因為他們直接轉向其他平台了。
是以播放鍊條需要一個可以全面監控播放異常，清晰描述各子產品工作狀态的系統。
線上異常發生時：
1）目前大部分的子產品都有備份方案可以通過線上開關來切換，但是不能通過開關覆寫的問題就需要發版來解決，這樣解決問題的周期變長，效率較低；
2）還有一種線上熱修複的方案，但是 ios 平台實施起來也有一定難度，這裡不多做讨論。 播放鍊條在檢測到異常的基礎上需要一定的自修複能力，在使用者無感覺的情況下解決問題。
綜上播放鍊條開發者需要設計一個技術名額用于描述播放器品質，它包含了更多的異常情 況，同時在名額異常時，播放器可以施行針對性的自修複。
二、設計思路及技術方案
播放異常監控需要了解播放器的各個子產品可能會出現的問題，同時這些問題也需要有一定 的實際意義能真實反映使用者體驗。 是以在選擇可用來量化監控的異常時我們可以選取播放鍊條 理論異常和客訴實際上報異常的交集。如圖：
1.播放器架構簡介
目前播放器的主要工作流程如下圖：
2.設計思路
1）如何定義播放異常 播放異常的标準通常都是針對播放器一系列動作結果的衡量，即最終呈現給使用者的效果受到影響。播放鍊條各子產品理論會出現問題總結如下圖：
綜合上述播放器各子產品可能會出現的問題以及客訴集中回報，我們可以抽象出以下問題：
2）播放器異常量化 如何量化考量這些異常?音視訊内容具有機關時間的展示規律，如視訊幀率：機關時間需展
示視訊幀數；音頻采樣率：機關時間可展示音頻 sample 數。上述總結的流程異常最終都将影響到這兩個名額，進而影響音視訊最終的展示效果，根據觀察我們本地構造不同參數的視訊檔案，最終我們将異常名額量化如下表：
其中優先級用于在多個異常同時發生時優先上報優先級高的異常，同一時間我們隻上報一 個異常。
注：上表中資料并非算法中實際值，隻是用于說明問題。
3）監控及自修複 在發現播放異常後我們希望能在播放核心進行自修複，因為這樣動作最小，可以做到使用者
無感覺，而要發現異常我們需要對機關時間内播放鍊條的輸出結果做衡量，而要定位異常發生
的子產品則需要了解異常發生時各子產品的工作狀态。是以我們梳理播放鍊條各子產品監控所需資訊 如下圖：
根據上述各子產品采集到的資訊我們可以制定出一個異常映射表：
3. 技術方案
現在我們可以歸結出一個視訊播放，資訊查詢，異常檢測，自動修複，恢複播放的處理流 程，可以表示為下圖：
三、實際應用及效果
1.監控服務
1）監控上線後為規模化處理客訴提供了基礎，協同客服将播放相關異常按照我們的分類進 行了整理，最終大部分的客訴都在我們的監控表中有資料可查，之前解決問題隻能依賴 tlog， 到現在可以通過資料大概分析問題所在，甚至部分異常可自行修複。最終相關客訴降低了 50%。
2）在播放鍊條監控上線前，安卓端硬解碼能力上線隻能通過測試手動測試将裝置加入白名 單進行開啟，監控上線後可以先行開啟相似裝置，在得到監控資料後再調整政策，通過這樣的 方法發現了一批硬解能力相對較差的機型，通過降檔政策提升播放體驗。
3）在播放鍊條監控上線前上線類似多點傳播放器同時播放，畫面增強等計算複雜度較高的業務 能力需要測試進行大量的适配測試最終標明白名單進行上線，上線政策相對保守，并且上線真 實效果無法衡量，在增加了監控後高計算複雜度業務對播放體驗是否有影響有了很直覺的衡量。
4）針對重大直播或者點播劇，可以開啟監控報警服務，最大程度保障播放品質。
2. 本地自動化測試
同時我們也協調測試同學，在每個版本的技術灰階釋出前進行本地的自動化測試，對版本 品質進行摸底，因為本地測試發現問題可以擷取到更多的資訊用于解決問題，争取把異常解決 于使用者發現前，自動化呈現結果如下圖：
3.為技術優化提供了方向和衡量标準
目前的播放器優化存在的兩大痛點，一是缺少針對性的優化方向，二是優化後沒有明确的 衡量名額。播放鍊條監控可以部分解決這些問題，監控有助于發現線上存在的嚴重問題，類似音畫不同步，在進行針對性的優化後效果可以回報在監控資料中，而部分同學做的性能優化也 可以回報在類似平均解碼幀率，平均渲染耗時等名額上。
四、未來規劃
1.提升精準度
監控系統本身是一個程式，是程式就可能存在 bug，若監控系統對于是否異常判斷發生問 題，對于定位發生在哪個子產品發生問題，對于該做怎樣的自修複産生問題，則可能導緻将本來 是正常的播放程序打亂。是以加強各個環節的定位精準度是監控下一個階段發展的基礎工作， 監控系統需要做秩序守護者，而不是麻煩制造者。
2.提升自動化程度
目前我們處理異常的流程仍然是出現問題->資料分析->定位問題->發版修複。雖然我們提 供了自修複能力，但是支援自修複的子產品較少，更多的問題還是需要發版解決。後續需要梳理 更多的子產品，配置其可自修複的問題，同時對于日志系統需要更加标準化，基于上報資料+本地 日志可以自動化分析問題，打造出現問題->自動化分析->自動化解決的流程。
3.擴充監控内容
目前基于内容的監控隻有黑屏，花屏，低音量，屬于被動式檢測，隻是針對異常進行檢測， 我們完全可以開放更多主動性的檢測，如人臉檢測，音色檢測等，将視訊進行小片段分割基于 下發機制，讓一部分性能優異的機型在播放的過程中對某個片段進行視訊内容資訊的分析，最 終将結果在服務端彙總完成整片的分析，而這些分析的資料對于我們挖掘廣告位或者互動玩法 都有很大的益處。