來源：得物技術

目錄

一、背景

二、影片體驗技術最佳化

    1. 影片質量提升

    2. 影片卡頓率最佳化

    3. 影片秒開最佳化

    4. 其他

三、影片從釋出到消費

    1. 釋出

    2. 編碼

    3. 解碼

四、過程中典型案例分析

    1. 沉浸流冷啟最佳化記憶體洩漏

    2. 高幀率倍速播放音畫不同步

    3. 關注流進入影片詳情頁，再返回關注流沒有續播

五、影片體驗我們做了什麼

    1. 效能

    2. 效能分析

    3. 發熱分析

    4. 總結

六、未來展望

一

背景

當談論如何提升影片的體驗時，我們需要明確網際網路影片市場的背景和現狀，並分析使用者對於影片體驗的期望和挑戰。

• 首先，隨著行動網路的普及和網際網路頻寬的不斷提升，影片觀看已成為網際網路的主要應用之一，影片內容也涉及更多的領域，例如教育、電商、社交等。同時，影片流量的份額也逐漸擴大，佔據著網際網路流量的重要部分。可是，面對海量的影片內容，使用者們提出了越來越高的要求，如需要更快的載入速度、更流暢的播放體驗、更高的畫質和解析度等，這些要求又產生了一系列挑戰。

• 其次，不良的網路環境和裝置所帶來的影響也是影片體驗不理想的重要原因之一，例如網路延遲、頻寬瓶頸、裝置效能等，這些因素都可能導致影片的卡頓、畫面模糊、下載速度慢等質量問題。此外，由於網路環境的差異和影片內容的多樣性，保障使用者體驗變得更加複雜，需要針對不同的使用者需求和裝置特性，採用不同的最佳化方案和技術手段。

針對這些問題，我們需要梳理出最佳化影片體驗的技術手段和測試角度，以提高影片的質量和使用者的滿意度。並透過不斷的最佳化落地，最終來提升影片體驗並提高市場競爭力。

上半年我們針對得物影片場景做了資料摸底，主要涉及的場景包含影片流和沉浸影片流，收集的指標包括卡頓率，秒開資料，CPU，記憶體及主客觀質量。從結果來看，我們在內容質量、秒開、卡頓上都有一定的提升空間。

二

影片體驗技術最佳化

為了最佳化以上存在的痛點問題，我們針對影片規劃了一系列的最佳化專案，主要從影片質量提升、影片卡頓率最佳化、影片秒開最佳化這 3 方面進行整改。

影片質量提升

影片卡頓率最佳化

影片秒開最佳化

其他

三

影片從釋出到消費

釋出

發布入口

• App釋出

• 創作者後臺釋出

• 達人後臺釋出

釋出流程

• 影片素材選擇

• 影片封面設定

釋出上傳

• 獲取 Oss 上傳地址和 Token

• 將 URL 上傳給社群服務端

編碼

我們前面講到影片體驗最佳化的 3 個方向，第一點就是影片質量提升，那麼如何能夠讓我們的影片有所提升，其實重點就是在編碼這一塊下功夫。這裡我們主要介紹得物社群編碼處理。

雲廠商

• 原影片 720P-H264 窄帶高畫質轉碼工作流（基礎轉碼）。

• 轉碼完成後呼叫【演算法服務】去水印&加水印。

• 觸發時機：影片釋出完成自動觸發。

社群服務

• 動態釋出介面：

• 儲存原影片連結到內容媒體庫。

• 轉碼檢查，增加雲廠商轉碼影片檢查記錄，待檢查轉碼狀態。

• 轉碼檢查處理指令碼：

• 檢查雲廠商轉碼是否完成，完成後儲存到內容媒體庫，同時請求演算法去水印。

• 檢查內容媒體中心轉碼是否完成，完成後儲存到內容媒體庫。

• 媒體中心回撥：

• 接收媒體中心轉碼回撥，更新內容媒體庫原影片寬高、時長等資訊。

• 往轉碼檢查表增加媒體中心轉碼的多種轉碼影片記錄待檢查轉碼狀態。

• 寬和高同時大於 720 會觸發 2 路轉碼（720P-H265和1080P-H265），否則一路轉碼（720P-H265）。

• 演算法處理回撥：

• 接收演算法去水印、生成封面圖等處理回撥，儲存處理後內容檔案到內容媒體庫。

• 去水印型別，MQ 通知中後臺影片轉碼已完成，中後臺開始稽核流程。

媒體中心

轉碼服務：

私有化微幀轉碼服務：

• 接收服務端原影片轉碼請求，雲廠商轉碼。

• 監聽二審二審透過、熱門影片、高幀率處理微幀轉碼。

• 監聽打標結果、籃球美妝類影片，影片增強轉碼。

• 影片首幀擷取處理。

• 回撥社群服務媒體中心，回傳轉碼完成後影片相關資訊。

演算法服務：

• 去原影片水印。

• 生成封面圖。

• 加品宣水印。

• 策略演算法商品封面圖。

解碼

這裡我們主要介紹解碼，從解碼到播放，這一塊的工作重點就是客戶端的各種最佳化了，如秒開、卡頓等各種體驗都是非常直觀的，也是直接面向使用者，讓使用者去檢驗影片體驗好與不好最簡單粗暴的方法。從業務層到播放器我們都做了很多努力，這裡大致介紹一下。

業務播放流程

前面我們在轉碼時介紹了很多種不同的轉碼型別、同時針對不同的轉碼定義了 Type 的多個列舉值，作用就在於業務這邊的播放優先順序策略。

• 冷啟動讀取影片切換策略。

• 影片動態下發兜底播放 URL、轉碼播放 URL、型別 Type。

總結：

• 每次冷啟動會拉取配置中心配置的影片播放策略。

• 播放影片時，根據配置中心配置優先順序，讀取實際下發的 Type，選對應的 Type 進行播放。

• 解碼器選擇：配置中心中配置了 264 解碼器播放型別和 265 解碼器播放型別，我們會根據對應優先順序選中對應 Type 的 URL 進行播放，然後再選中對應的解碼器進行解碼。

• 預下載大小：配置中心中配置了不同型別預下載大小，那麼我們會根據播放型別進行預下載。

如果 Video 下發為空，那麼我們會使用兜底連結播放。

首幀載入邏輯

• 可以先看一下下面的例子：

• 為了防止有人惡意將我們服務當做影片儲存地址，同時出於規避黑灰產的非法資源的合規風險，我們針對影片做了防盜鏈技術，即影片地址是有有效期的，超過配置的有效時間，地址會失效，播放時，需要進行換鏈請求。這裡帶來的一個問題就是存在一些場景在進入影片詳情頁時無法載入首幀圖，只有黑底圖到影片播放的過渡，影響秒開。

• 同時，影片是可以設定封面的，封面可能是演算法識別、也可能是使用者自己選擇，這就造成了很大的不確定性，即封面很有可能不是影片首幀，甚至和影片毫無關聯。這類影片，我們在進入影片詳情頁先用封面填充，但到播放時會感覺明顯跳幀，畫面不連貫，也非常影響影片觀看的體驗。

因此，雖然我們有預下載首幀邏輯，但如果影片地址過期，首幀下載是會失敗的，就存在瞭如上進入影片先出現黑底圖的現象。基於此，我們做了首幀載入邏輯的最佳化。

• 首幀獲取邏輯

• 播放邏輯策略

• 取得新的影片首幀圖片後需要自行拼接裁剪引數，目前統一轉 Heic 格式圖片，裁剪寬度最大 360（和線上邏輯一致），高度自適配。轉成 Heic 可以有效降低檔案大小，減少網路傳輸成本，提升首幀載入速度。

• 優先順序：影片首幀的圖片快取 > 雙列卡片的封面圖片快取 > 載入首幀網路圖並以黑底圖兜底。

沉浸流冷啟最佳化

最終展示的資料情況：

• 之前某次啟動的快取資料 1 條 + 本次啟動沉浸流請求的後續資料 6 條。
• 本次啟動社群首頁請求的資料 1 條 + 本次啟動沉浸流請求的後續資料 6 條。
• 本次啟動沉浸流請求的資料 6 條。

播放器複用

最佳化前：

最佳化後：

這裡我們可以明顯看到最佳化前，關注流進入到影片詳情頁會黑一下，最佳化後就更加絲滑了，肉眼看不出有黑屏的情況。這裡我們主要就是使用了播放器複用來解決這個問題，節省建立播放器核心等待時間。

• 建立 View 的時機

• 每次點選提前建立 View 開始解碼。

• 跳轉後將 View add 到螢幕上。

複用過程就是 A 頁面解綁 -B 頁面繫結 -B 頁面解綁 -A 頁面重新繫結。

當然這裡，推薦流是比較特殊的，有個共享的播放器例項。

四

過程中典型案例分析

沉浸流冷啟最佳化記憶體洩漏

沉浸流冷啟最佳化功能測試完成後，沒有發現什麼問題，但是在我們效能的每日 DailyRun 報告中發現有一處記憶體洩漏，並且每一個指令碼都報了這個洩漏，檢視堆疊資訊關鍵字 ImmersiveVideoInitManager preRenderVideoView，大致猜測是首頁沉浸流預渲染導致靜態變數沒釋放的問題，聯想到這個技改需求，進一步和開發確認，發現的確是這個需求引入的。透過這個例子，進一步驗證功能測試和自動化是相輔相成、相互兜底的，多方組合手段才能提升線上的穩定性。

Tips：針對端上的一些大需求、模組技改、底層邏輯重構等等，我們可以結合自動化來驗證 App 的穩定性，業務邏輯測試 + 探索性測試 + 自動化測試 + 灰度驗證，在整個版本週期都能透過一些手段去有效發現問題，左移前置的越多，線上暴露的問題就會越少。

當然往往這些都伴隨了一些 AB，因此我們在跑自動化時要把 AB 開啟。讓這些功能能提前得到一些驗證。

高幀率倍速播放音畫不同步

• 原因：在迴歸時，發現部分影片倍速播放出現音畫不同步的現象，排查發現，該影片是 60fps，2 倍速的話會變成 120fps，播放器渲染不過來了。因此當倍速 *幀率 >60，雙端都存在這個問題。

• 解決：在業務方面，我們是沒有 60fps 轉碼的，因此播放器僅支援 60fps 播放，60+ 倍速沒有支援，這類影片是百度超分轉碼沒有限制幀率，導致會有部分影片出現60fps，最終雙端播放器支援 60+fps 播放解決該問題，同時我們這邊其他轉碼也支援高幀率影片了。

Tips：倍速播放我們這邊採用的是：沒有跳幀的變速播放，在不跳幀的情況下改變影片的播放速度，從而實現加快或減慢影片播放的效果。音訊採用變速不變調，能夠改變音訊播放速度，同時不改變其音調的技術。

針對影片各種各樣的問題，首要原則是不給自己設限，多瞭解總沒錯，比如不同解析度影片播放（480P、720P、1080P、4k......）、不同比例影片播放（1：1、3：4、4：3、16:9......），不同幀率影片播放（24fps、30fps、60fps、120fps）、HDR 和 SDR（目前端上播放器不支援 HDR，導致播放 HDR 影片有色差，轉碼時需要相容支援HDR轉SDR）、Livephoto、直播切片有水印類影片播放、外接裝置如藍芽耳機播放等等。

瞭解的越多，覆蓋的場景就會越全面，同時也是一個很好的知識積累機會。

關注流進入影片詳情頁，再返回關注流沒有續播

原因：這個問題是當時一個技改 Https 轉 Http 播放時出現的一個問題，從關注流到影片詳情頁我們會切換成 Http 的地址進行播放，當返回時又變成了 Https，播放器接受到的播放地址發生發生變化，導致播放器進行重播了，而不是續播。

解決：外部有播放器，涉及場景切換時相容這種邏輯。

Tips：這個問題我將其放到經典案例分析，原因很簡單，因為在影片測試過程中，碰到過影片播放的很多問題，視覺呈現的問題效果都不一樣，比如這裡的沒有續播，還有穿搭精選九宮格點選影片到影片詳情頁影片跳幀、播放不流暢、黑屏，防盜鏈過期換鏈播放等等，深究原因都是播放地址發生變化而導致的問題。只不過造成地址不一樣的原因不一樣，有的是快取資料過期，有的是外部資料和裡面資料下發不一致、有的是內部域名轉換等等。

因此碰到類似問題，可以先嚐試自己排查，逐一排除，同時對於一些技改保持對問題的敏感度，提前評估一些影響點。

五

影片體驗我們做了什麼

效能

• 安卓效能基線

• iOS效能基線

• 左移發現問題

  雙端累計發現了一些問題，其中有個別問題是版本技改引入，成功左移攔截。

效能分析

呵呵

發熱分析

• 發熱壓測分析報告

昨當前報告共包含影片詳情頁面共 1 個場景。
影片詳情頁面：該場景包含多個效能指標，其中，得物在 Android 端的部分指標上取得 Top。

總結

效能

• 建立效能基線，覆蓋當前業務核心頁面，雙端效能 Case 穩定執行。

• 針對 Debug 包進行 APM 平臺打通，效能異常指標通知提醒，累計發現多個效能問題。

• 針對 Debug 包進行 Crash 攔截，並打通 Crash 平臺和 Crash 異常通知提醒 ，累計發現多個 Crash。

• 效能問題歸類。

分析

• 針對雙端圖文、影片、沉浸式、推薦流 4 個場景摸底排查並建立效能基線。

• 針對影片做發熱壓測分析。

• 推動並支援開發完成影片內容質量、秒開、卡頓上的一系列技改需求。

• 最佳化後完成效能分析並輸出報告，各場景指標排名獲得一定的提升，iOS 卡頓率下降 25%、影片失敗率：下降 66.6%、首幀載入時長：降低 47%；Android 影片失敗率：降低 42.8%；Android 首幀載入時長：降低 46.6%。

六

未來展望

在如今這個體驗為王的時代，我們在影片的體驗上還需投入更多精力，只有不斷探索新的技術方案，不斷探索新的測試手段，我們才能成為行業的 Top。這也是我們未來努力的方向，比如主客觀測評後臺、影片轉碼技術最佳化、更多的左移、更多的輔助開發做一些分析等等。這需要多方合作，實現共同雙贏。

最後感謝大家的耐心閱讀！感謝在影片建設過程中合作的各位同學提供的諸多幫助~