簡介：短視頻作為內(nèi)容重要的承載方式，是吸引用戶的重點，短視頻的內(nèi)容與體驗直接關(guān)系到用戶是否愿意長時停留。因此，體驗的優(yōu)化就顯得尤為重要。上一篇我們分享了 iOS 短視頻秒播優(yōu)化，這篇我們來聊聊 Android 端的優(yōu)化。

作者｜少陽

審校｜泰一

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

• 滿足硬性指標：播放成功率、首幀時長、秒開率。

• 滿足用戶體感流暢度。

（為反應(yīng)用戶觀看短視頻過程中的真實體驗，盒馬新增秒播體感指標：從用戶劃到視頻，到視頻首幀播放的時間。）

優(yōu)化效果對比

首先我們來看一下優(yōu)化前后與其他 App 的效果對比：

環(huán)境

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

問題分析

◆?首頁閃屏盒馬最初為了保證進入畫面時不是空白頁面而增加了封面圖顯示，在播放時隱藏。從體感指標可以看出，即便是優(yōu)化前，體感播放時間很短，只有 200ms 左右（不包含滑動過程）。由于滑動過程中，到視頻正式播放有約 600ms 左右時間顯示封面，隨后又迅速顯示播放畫面，此時用戶仍有強烈的屏幕閃爍和頓挫感，體驗極差。

解決思路：在滑動過程中就顯示視頻首幀畫面，不再顯示封面，則播放時不再產(chǎn)生頓挫感。這里的優(yōu)化需要結(jié)合出流慢問題一起優(yōu)化。

◆?出流速度慢（播放體感慢）服務(wù)端：服務(wù)端造成的出流速度慢，一般是文件大，網(wǎng)絡(luò)鏈路差造成。可用 H.265 和 CDN 加速優(yōu)化

客戶端：客戶端播放需要經(jīng)歷下載 -> 加載 + 解碼 -> 渲染三個步驟，并且三個步驟為線性執(zhí)行。所以在窗口播放畫面前必然需要經(jīng)過 1s 左右的準備工作。這里可以考慮提前執(zhí)行下載 -> 加載 + 解碼。

優(yōu)化方案選型

在優(yōu)化前期，我們考慮了三種優(yōu)化方案。

方案一：雙播放器?+?預(yù)下載優(yōu)點：占內(nèi)存小，思路簡單。缺點：優(yōu)化力度有限，無法同時兼顧上滑和下滑。

方案二：自定義三播放器管理?+?預(yù)下載優(yōu)點：同時兼顧上下翻頁，體驗接近抖音。缺點：播放器管理與回收實現(xiàn)復雜，容易錯亂；占用內(nèi)存高。

方案三：三播放器（基于 RecyclerView 的緩存機制實現(xiàn)）+?預(yù)下載優(yōu)點：同時兼顧上下翻頁，體驗接近抖音，緩存機制由 RecyclerView 托管。缺點：占用內(nèi)存高，頻繁創(chuàng)建和銷毀播放器。

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

方案三原理：翻頁前

• current 播放器開始播放視頻 1。
• pre,next 播放器分別加載視頻數(shù)據(jù) 0 和 2。
• 同時視頻數(shù)據(jù) 3-7 加入預(yù)下載隊列。

方案三原理：翻頁后

• 被 RecyclerView 回收的 holder 銷毀播放器。

• RecyclerView onBind 中的 holder 創(chuàng)建新的 next 播放器。

• current 播放器開始播放視頻 2。

• pre 播放器 seek 0 并暫停， next 播放器創(chuàng)建并加載視頻 3 文件。

• 同時預(yù)下載清除未消費的隊列，視頻數(shù)據(jù) 4-8 加入預(yù)下載隊列開始下載（此處已有緩存的視頻不會被重復下載）。

具體優(yōu)化方案

多播放器改造

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

1. 設(shè)置緩存數(shù)量：利用 RecyclerView 特性，配置 setItemViewCacheSize，確保內(nèi)存中存在 3 個 holder（緩存的 1 個 holder，預(yù)創(chuàng)建 1 個 holder， 當前 holder）。

mRecyclerView.setItemViewCacheSize(1); // 設(shè)置緩存數(shù)量

2.?重寫 Adapter 的 onBindViewHolder， 用于創(chuàng)建播放器，并預(yù)加載解碼視頻內(nèi)容，播放器控制解析到首幀時暫停。此時 onSurfaceCreated 尚未回調(diào)，畫面未渲染至屏幕。

3. 監(jiān)聽 onPageRelase 控制即將移除屏幕的播放器暫停，并 seekTo (0)，方便滑回屏幕時立即播放。

4. 監(jiān)聽 onPageSelected 控制即將進入屏幕的播放器開始播放。注意：由于在 onBindViewHolder 期間已解碼完成，這里只需要進入屏幕 1px，就會立即觸發(fā) Surface 的繪制（只會執(zhí)行一次），即進入窗口的內(nèi)容會顯示視頻的首幀畫面。

5. 重寫 Adapter 的 onViewRecycled， 由于當前 holder 即將移出屏幕，移出方向上屏幕外的 holder 將被回收。此時回收并銷毀播放器。

多播放器 + RecyclerView 原理圖

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

• 上下滑動過程中，進入屏幕的畫面為視頻的第一幀畫面，并且不會有視覺上的頓挫。

• 正式播放前預(yù)創(chuàng)建播放器，并加載和解碼，節(jié)省了播放視頻之前的準備工作。（ps：這里還包括了下載的過程）。

• 由于提前加載和解碼，進入屏幕時，觸發(fā) Surface 瞬間渲染，視覺上無感知，因此播放視頻前不再需要封面圖，避免了封面圖和首幀不一致導致的閃屏問題。

預(yù)下載優(yōu)化

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

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

關(guān)于預(yù)下載，我們首先要知道播放器內(nèi)部播放過程。這里的本地代理是視頻緩存機制實現(xiàn)的，具體參照下一章節(jié)。

播放器內(nèi)部流程

◆?預(yù)下載策略

這里，我們?yōu)榱斯?jié)約請求網(wǎng)絡(luò)數(shù)據(jù)的過程，在播放之前提前下載視頻的首幀片段，采用如下策略：

• 文件大小：下載 1MB 視頻文件的方式進行提前首幀下載。（ps：經(jīng)測試 1MB 已包含了首幀，且文件相對較小）。

• 提前量：提前 5 個下載量（pageSize 為 10 的情況）。

• 并發(fā)情況：下載采用同步隊列下載（避免異步下載導致帶寬占用，正常播放的視頻卡頓）。

• 快滑優(yōu)化：快滑清除下載隊列，避免快滑過程中頻繁觸發(fā)下載。

• 下載時機：loadMore 時將前 5 個推入隊列；onPageSelected 時，跳過下一個開始起算 5 個視頻推入隊列（下一個視頻由預(yù)加載的播放器自動下載，這里重復下載會導致視頻花屏）。

◆?快滑定義

當用戶快速翻頁時（onPageSelected 調(diào)用之前又滑了一下），onPageSelected 不會觸發(fā)，onPageRelease 會觸發(fā)多次。在 onPageRelease 中判斷? release position 與 current postion 的差值如果?> 1 則表示用戶至少快速翻頁 1 次，此時定義為快滑狀態(tài)，應(yīng)當停止預(yù)下載和播放器預(yù)加載。

當 onPageSelected 回調(diào)時，說明用戶沒有繼續(xù)翻頁，此時取消快滑狀態(tài)。開始執(zhí)行預(yù)下載和恢復播放器預(yù)加載。

預(yù)下載流程圖

緩存優(yōu)化

目前盒馬使用的播放器為淘寶內(nèi)部播放器。?播放器本身不存在文件緩存和預(yù)下載功能。在播放器重新創(chuàng)建后，即便是同一個視頻也不會有文件緩存，需要重新下載。這里引入一個開源緩存框架?“com.danikula:videocache”。?

◆?方案原理

播放器播放的地址代理給本地的緩存服務(wù)，緩存服務(wù)負責轉(zhuǎn)發(fā)數(shù)據(jù)流的同時進行文件保存如：

視頻地址為：https://****.mp4。

本地代理地址為：http://127.0.0.1:8888 (假設(shè)端口號分配為 8888)。

代理后的地址為：?本地代理地址 + 視頻地址（URL 編碼）。

即：http://127.0.0.1:8888/https%3A%2F%2F****.mp4

后續(xù)優(yōu)化展望

關(guān)于多媒體的優(yōu)化工作還有很多可以做。除了沉浸式秒播的場景外，我們還可以：

1. 對播放器的一般性場景進行秒播優(yōu)化，如首頁列表的卡片視頻。目前首頁平均首幀畫面需要 550ms，較長的有 1000s 以上，有明顯的頓挫感。在沉浸式的方案基礎(chǔ)上，我們可以提供一般性的預(yù)下載能力，從而減少播放器的下載渲染時長。

2. 續(xù)播和內(nèi)存優(yōu)化。續(xù)播是另一個提升體驗的方面，用戶能夠非常直觀的感受連貫與否。

3. 頁面單播放器托管。大多場景下，一個頁面只有一個播放器在播放，這就可以通過管理唯一的播放器實現(xiàn)頁面播放器復用，從而優(yōu)化內(nèi)存和體驗。

下一期我們將繼續(xù)分享盒馬 iOS / Android 端短視頻續(xù)播的體驗優(yōu)化實踐。
歡迎關(guān)注「視頻云技術(shù)」公眾號。

「視頻云技術(shù)」你最值得關(guān)注的音視頻技術(shù)公眾號，每周推送來自阿里云一線的實踐技術(shù)文章，在這里與音視頻領(lǐng)域一流工程師交流切磋。公眾號后臺回復【技術(shù)】可加入阿里云視頻云產(chǎn)品技術(shù)交流群，和業(yè)內(nèi)大咖一起探討音視頻技術(shù)，獲取更多行業(yè)最新信息。

原文鏈接：https://developer.aliyun.com/article/789527?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的拒绝卡顿，揭秘盒马鲜生 Android 短视频秒播优化方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。