揭秘盒馬鮮生 Android 短視頻秒播優化方案

短視頻作為內容重要的承載方式，是吸參考戶的重點，短視頻的內容與體驗直接關系到用戶是否愿意長時停留，因此，體驗的優化就顯得尤為重要，上一篇我們分享了 iOS 短視頻秒播優化，這篇我們來聊聊 Android 端的優化，

作者｜少陽
審校｜泰一

優化前的盒馬沉浸式短視頻播放頁面，體感和流暢度上與主流短視頻 App 有明顯差距，主要問題有播放封面閃屏、出流速度慢兩個問題，所以優化的目標是解決盒馬沉浸式短視頻現有短板，與主流 App 的沉浸式短視頻體驗對齊，如抖音、手淘等，具體指標有：

• 滿足硬性指標：播放成功率、首幀時長、秒開率，
• 滿足用戶體感流暢度，（為反應用戶觀看短視頻程序中的真物體驗，盒馬新增秒播體感指標：從用戶劃到視頻，到視頻首幀播放的時間，）

優化效果對比

首先我們來看一下優化前后與其他 App 的效果對比：
https://v.youku.com/v_show/id_XNTgwMzAwNDQ0OA==.html

環境

• 手機：Pixel 4
• OS：Android 10
• 播放器：淘寶播放器

問題分析

首頁閃屏

盒馬最初為了保證進入畫面時不是空白頁面而增加了封面圖顯示，在播放時隱藏，從體感指標可以看出，即便是優化前，體感播放時間很短，只有 200ms 左右（不包含滑動程序），由于滑動程序中，到視頻正式播放有約 600ms 左右時間顯示封面，隨后又迅速顯示播放畫面，此時用戶仍有強烈的螢屏閃爍和頓挫感，體驗極差，
解決思路：在滑動程序中就顯示視頻首幀畫面，不再顯示封面，則播放時不再產生頓挫感，這里的優化需要結合出流慢問題一起優化，

出流速度慢（播放體感慢）

服務端：服務端造成的出流速度慢，一般是檔案大，網路鏈路差造成，可用 H.265 和 CDN 加速優化
客戶端：客戶端播放需要經歷下載 -> 加載 + 解碼 -> 渲染三個步驟，并且三個步驟為線性執行，所以在視窗播放畫面前必然需要經過 1s 左右的準備作業，這里可以考慮提前執行下載 -> 加載 + 解碼，

優化方案選型

在優化前期，我們考慮了三種優化方案，

方案一：雙播放器 + 預下載
優點：占記憶體小，思路簡單，
缺點：優化力度有限，無法同時兼顧上滑和下滑，

方案二：自定義三播放器管理 + 預下載
優點：同時兼顧上下翻頁，體驗接近抖音，
缺點：播放器管理與回收實作復雜，容易錯亂；占用記憶體高，

方案三：三播放器（基于 RecyclerView 的快取機制實作）+ 預下載
優點：同時兼顧上下翻頁，體驗接近抖音，快取機制由 RecyclerView 托管，
缺點：占用記憶體高，頻繁創建和銷毀播放器，

最終因為性價比因素，選擇了第三個方案，

方案三原理：翻頁前

• current 播放器開始播放視頻 1，
• pre,next 播放器分別加載視頻資料 0 和 2，
• 同時視頻資料 3-7 加入預下載佇列，

方案三原理：翻頁后

• 被 RecyclerView 回收的 holder 銷毀播放器，
• RecyclerView onBind 中的 holder 創建新的 next 播放器，
• current 播放器開始播放視頻 2，
• pre 播放器 seek 0 并暫停， next 播放器創建并加載視頻 3 檔案，
• 同時預下載清除未消費的佇列，視頻資料 4-8 加入預下載佇列開始下載（此處已有快取的視頻不會被重復下載），

具體優化方案

多播放器改造

為了解決體感上的頓挫和出流慢的問題，采用多播放器結合 RecyclerView 方案進行改造，步驟如下：

1. 設定快取數量：利用 RecyclerView 特性，配置 setItemViewCacheSize，確保記憶體中存在 3 個 holder（快取的 1 個 holder，預創建 1 個 holder， 當前 holder），
   mRecyclerView.setItemViewCacheSize(1); // 設定快取數量
2. 重寫 Adapter 的 onBindViewHolder， 用于創建播放器，并預加載解碼視頻內容，播放器控制決議到首幀時暫停，此時 onSurfaceCreated 尚未回呼，畫面未渲染至螢屏，
3. 監聽 onPageRelase 控制即將移除螢屏的播放器暫停，并 seekTo (0)，方便滑回螢屏時立即播放，
4. 監聽 onPageSelected 控制即將進入螢屏的播放器開始播放，注意：由于在 onBindViewHolder 期間已解碼完成，這里只需要進入螢屏 1px，就會立即觸發 Surface 的繪制（只會執行一次），即進入視窗的內容會顯示視頻的首幀畫面，
5. 重寫 Adapter 的 onViewRecycled， 由于當前 holder 即將移出螢屏，移出方向上螢屏外的 holder 將被回收，此時回收并銷毀播放器，

多播放器 + RecyclerView 原理圖

三播放器讓沉浸式短視頻的體驗大幅提高，主要解決了以下問題：

• 上下滑動程序中，進入螢屏的畫面為視頻的第一幀畫面，并且不會有視覺上的頓挫，
• 正式播放前預創建播放器，并加載和解碼，節省了播放視頻之前的準備作業，（ps：這里還包括了下載的程序），
• 由于提前加載和解碼，進入螢屏時，觸發 Surface 瞬間渲染，視覺上無感知，因此播放視頻前不再需要封面圖，避免了封面圖和首幀不一致導致的閃屏問題，

預下載優化

前面講到了多播放器實作翻頁秒播能力，在體驗上有了非常大的改善，但由于預創建的播放器在加載時，同時需要下載視頻檔案，導致這里的下一個播放器準備好視頻的時間會增加到 1s 左右，如果用戶在播放器加載解碼完成前滑至該視頻，則會出現明顯的黑屏，帶來非常差的體驗，

由于預加載的時間過長，且無法預知用戶是否會快速滑動，這里需要提前進行下載和快速滑動檢測，

關于預下載，我們首先要知道播放器內部播放程序，這里的本地代理是視頻快取機制實作的，具體參照下一章節，

播放器內部流程

預下載策略

這里，我們為了節約請求網路資料的程序，在播放之前提前下載視頻的首幀片段，采用如下策略：

• 檔案大小：下載 1MB 視頻檔案的方式進行提前首幀下載，（ps：經測驗 1MB 已包含了首幀，且檔案相對較小），
• 提前量：提前 5 個下載量（pageSize 為 10 的情況），
• 并發情況：下載采用同步佇列下載（避免異步下載導致帶寬占用，正常播放的視頻卡頓），
• 快滑優化：快滑清除下載佇列，避免快滑程序中頻繁觸發下載，
• 下載時機：loadMore 時將前 5 個推入佇列；onPageSelected 時，跳過下一個開始起算 5 個視頻推入佇列（下一個視頻由預加載的播放器自動下載，這里重復下載會導致視頻花屏），

快滑定義

當用戶快速翻頁時（onPageSelected 呼叫之前又滑了一下），onPageSelected 不會觸發，onPageRelease 會觸發多次，在 onPageRelease 中判斷 release position 與 current postion 的差值如果 > 1 則表示用戶至少快速翻頁 1 次，此時定義為快滑狀態，應當停止預下載和播放器預加載，
當 onPageSelected 回呼時，說明用戶沒有繼續翻頁，此時取消快滑狀態，開始執行預下載和恢復播放器預加載，

預下載流程圖

快取優化

目前盒馬使用的播放器為淘寶內部播放器， 播放器本身不存在檔案快取和預下載功能，在播放器重新創建后，即便是同一個視頻也不會有檔案快取，需要重新下載，這里引入一個開源快取框架 “com.danikula:videocache”，

方案原理

播放器播放的地址代理給本地的快取服務，快取服務負責轉發資料流的同時進行檔案保存如：
視頻地址為：https://****.mp4，
本地代理地址為：http://127.0.0.1:8888 (假設埠號分配為 8888)，
代理后的地址為： 本地代理地址 + 視頻地址（URL 編碼），
即：http://127.0.0.1:8888/https%3A%2F%2F****.mp4

后續優化展望

關于多媒體的優化作業還有很多可以做，除了沉浸式秒播的場景外，我們還可以：

1. 對播放器的一般性場景進行秒播優化，如首頁串列的卡片視頻，目前首頁平均首幀畫面需要 550ms，較長的有 1000s 以上，有明顯的頓挫感，在沉浸式的方案基礎上，我們可以提供一般性的預下載能力，從而減少播放器的下載渲染時長，
2. 續播和記憶體優化，續播是另一個提升體驗的方面，用戶能夠非常直觀的感受連貫與否，
3. 頁面單播放器托管，大多場景下，一個頁面只有一個播放器在播放，這就可以通過管理唯一的播放器實作頁面播放器復用，從而優化記憶體和體驗，

下一期我們將繼續分享盒馬 iOS / Android 端短視頻續播的體驗優化實踐，

「視頻云技術」你最值得關注的音視頻技術公眾號，每周推送來自阿里云一線的實踐技術文章，在這里與音視頻領域一流工程師交流切磋，公眾號后臺回復【技術】可加入阿里云視頻云產品技術交流群，和業內大咖一起探討音視頻技術，獲取更多行業最新資訊，

標籤：其他

上一篇：Vulnhub——DarkHole_2

下一篇：任意檔案讀取與下載漏洞