作者| 阿里文娛技術專家 翠姝
一、設計背景
音視頻播放器的工作內容可以描述為：根據流媒體協議還原音視頻內容的過程。在還原的 每個階段都存在丟失精度的風險，而最終呈現的結果也是一個主觀的內容，這就給播放器輸出結果的評估引入了一些痛點問題，可以列舉如下：
測試階段：
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.擴展監控內容
目前基於內容的監控只有黑屏，花屏，低音量，屬於被動式檢測，只是針對異常進行檢測， 我們完全可以開放更多主動性的檢測，如人臉檢測，音色檢測等，將視頻進行小片段分割基於 下發機制，讓一部分性能優異的機型在播放的過程中對某個片段進行視頻內容信息的分析，最 終將結果在服務端彙總完成整片的分析，而這些分析的數據對於我們挖掘廣告位或者互動玩法 都有很大的益處。