內容作為 App 產品新的促活點，受到了越來越多的重視與投入，短視頻則是增加用戶粘性、增加用戶停留時長的一把利器，短視頻的內容與體驗直接關系到用戶是否愿意長時停留，盒馬也提出全鏈路內容視頻化的規劃，以實作商品力表達的提升，目前已有短視頻場景包括：首頁、搜索、商品詳情、達人秀、沉浸式視頻、真香視頻、盒區首頁 feeds 流、話題、UGC 內容、話題合集落地頁、社群、菜譜、盒拍一鍵剪、直播回放、weex 等，
作者｜神捕
審校｜泰一
本次優化的目標是將盒馬 App 與主流短視頻 App 體驗對齊，如抖音、手淘等，優化具體的硬性指標有播放成功率、卡頓率、秒開率，另外，為了反應用戶觀看短視頻程序中的真物體驗，盒馬還新增了體感指標：首幀渲染時長，
優化效果對比
https://v.youku.com/v_show/id_XNTgwMTI2MzgxNg==.html
以上視頻測驗基于 iPhone 6S，可以看到抖音在大多數情況下，在滑到下個視頻后，可以立即開始播放；而盒馬優化前，滑到下個視頻后，會先展示封面圖，再繼續播放，有個閃跳的程序，優化后的盒馬，效果已經與抖音效果接近，
為了衡量優化前后與抖音的體驗對比，目前采用錄屏數幀的方式，算出視頻頁面完全展示到首幀渲染時刻的耗時，體感資料如下：
此外還有一些硬性指標的優化，結果如下：
優化方案
在本次優化前期，調研了阿里集團內不少優秀的方案，大多數都是接入了手淘播放器，內核基于開源的 ijkPlayer，但播放器層面本身門檻較高，且手淘已優化較好了，所以本次的優化方向主要集中在上層業務的預加載方案上，具體從以下幾個方面入手：
統一視頻播放代理與快取
視頻的加載速度，很大程度上取決于從網路下載的耗時，增加視頻快取可以有效提高視頻二次播放速度，為實作快取機制，需要引入代理服務器，接手視頻資料下載流程，如下：
A. 優化前播放流程：
B. 優化后播放流程：
業務層往播放器設定 videoUrl 前，先對原始 videoUrl 加密，替換成 127.0.0.1 的本地 proxyUrl, 將請求引導到代理 webServer，此時呼叫 proxy 模塊進行視頻原始視頻 url 的決議、快取的讀取或遠程請求，最終再通過 server 回傳資料給播放器，
視頻播放增加中間代理也是業界常見手段，盒馬依賴的手淘播放器也有現成的代理服務，但其代理功能放在另一個獨立的 DW 庫中，對盒馬是冗余的，且目前 SDK 暫未支持獨立的預下載介面，上層無法做首播優化，所以目前盒馬做了獨立的代理層，以支持上層靈活的定制，
自建代理還有個好處是，一些業務并非使用統一手淘播放器的場景也能同時享受到快取服務，比如一些 flutter 頁面使用的系統播放器，至少快取的管理，目前設定了快取區最大值的保護，在每次 App 回到前臺時，進行視頻快取的清理，
針對 m3u8 的代理與快取
除了常見的 mp4 視頻外，日常還會遇到 m3u8 的視頻，比如盒馬中的直播回放視頻，（視頻鏈接）
該類視頻與 mp4 不同，在請求 url 時并非直接回傳視頻流，而是先回傳 playlist 文本，playlist 中才是可播放的各個視頻片斷，如下：
這種視頻的快取處理，采用的是修改 m3u8 playlist 中的 url，替換為代理 url 實作，就可以走代理了，之前 iOS 側對 m3u8 的快取支持有問題會 crash，原因是修改了 m3u8 的 Playlist 的第 1 個視頻的 url 為代理 proxyUrl 后，播放第一片段正常，但后續的片段 url 仍是原始 url，手淘播放器在加載這種原始相對 url 路徑時，內部會拼接上第一小段的域名和 path，導致第二段以后的 url 有問題，直接 crash，目前的處理方式是，把 playlist 中所有 url 全部改成代理 url 的 fullpath 即可，
這樣有了 mp4 和 m3u8 兩種視頻后，完整流程如下：
獨立預加載能力
上述的代理快取，能提升二次播放速度，但對首次播放的視頻，仍然無快取可用，下載程序依然很耗時，所以需要獨立的預加載能力，配合業務層，在合適的時機提前進行視頻資料的下載（無渲染），
目前底層提供 [HMVideoLoader preLoadUrls:URLS] 方法，內部根據 url 進行視頻快取，下載大小限制 1M，多個視頻同時預下載時，串行執行，保證不過多占用帶寬，影響業務處理，等用戶劃動到視頻位置時，可以直接開始播放，達到首開速度優化，
需要提下的是，此處的預加載，復用了上述代理類，也以 url 為 key 進行資料快取，這樣后續的二次播放也可以讀取同一個的快取，如果預加載程序中，滑到了該視頻開始播放，則先停止預加載任務，避免同個視頻的重復下載引起快取沖突，
視頻碼率、解析度優化
視頻的預加載、代理快取，都是基于提前準備視頻資料角度考慮，這有個前提，就是準備時間很短，業務可以及時使用，如果視頻很大，網路較差，業務又需要立即消費，則可能無法享受到優化效果，所以需要在視頻碼率、解析度上進一步優化，
早期盒馬都是播的 H264 視頻，并且都是高清視頻，這在很多 feeds 流上其實是用不上這么大的，影響加載速度且浪費流量，目前已在 cloudVideo 上申請配置了 H265 轉碼，盒馬視頻上傳后可同時獲取 265，264 兩路視頻，且有高清、標清、普清 3 種解析度，這樣就給端上按業務場景選擇帶來了自由度，先看下切換后同個視頻大小的對比：
A. H264 切為 H265（都是高清）：原始 H264 大小為 10.6M，切換后變為 7.1M
B. 切到 H265 并且修改解析度：原始 H264 為 21M，切換后變為 8.3M
從這兩個例子可以看到，同個視頻都是高清前提下，切到 H265 視頻后，大小下降了約 30%，如果同時又降低解析度到標清，視頻大小減小非常明顯，這意味視頻碼率下降了，用戶可以更快下載到首幀資料，
目前盒馬服務端介面已改造支持直接回傳 H265 視頻地址，iOS 這邊的策略是：優先使用 h265，并按當前環境，請求不同解析度：
A. iOS11 以下，使用 h264；iOS11 及以上，使用 h265 (手淘播放器默認已開啟硬解)
B. 解析度，按當前機型（高、中、低）、網路型別（wifi/4g）、當前網路情況（強、弱）定義不同的解析度請求順序，如下，最侄訓傳的陣列按順序拼成解析度引數優先級，比如 hd#sd#ld 表示優先高清，
static NSString * const VIDEO_HD = @"hd";
static NSString * const VIDEO_SD = @"sd";
static NSString * const VIDEO_LD = @"ld";
static NSString * const VIDEO_HD_H265 = @"hd_265";
static NSString * const VIDEO_SD_H265 = @"sd_265";
static NSString * const VIDEO_LD_H265 = @"ld_265";
+ (NSArray*) getExpectedVideoDefinition {
NSArray *VIDEO_PRIORITY_GOOD_ENV = nil;
NSArray *VIDEO_PRIORITY_NORMAL_ENV = nil;
NSArray *VIDEO_PRIORITY_BAD_ENV = nil;
if ([[[UIDevice currentDevice] systemVersion] compare:@"11.0" options:NSNumericSearch] == NSOrderedAscending) {
VIDEO_PRIORITY_GOOD_ENV = @[VIDEO_HD, VIDEO_SD, VIDEO_LD];
VIDEO_PRIORITY_NORMAL_ENV = @[VIDEO_SD, VIDEO_LD, VIDEO_HD];
VIDEO_PRIORITY_BAD_ENV = @[VIDEO_LD, VIDEO_SD, VIDEO_HD];
}
else{
VIDEO_PRIORITY_GOOD_ENV = @[VIDEO_HD_H265, VIDEO_SD_H265, VIDEO_LD_H265];
VIDEO_PRIORITY_NORMAL_ENV = @[VIDEO_SD_H265, VIDEO_LD_H265, VIDEO_HD_H265];
VIDEO_PRIORITY_BAD_ENV = @[VIDEO_LD_H265, VIDEO_SD_H265, VIDEO_HD_H265];
}
AliHADeviceEvaluationLevel deviceLevel = [AliHADeviceEvaluation evaluationForDeviceLevel];
NetworkQualityStatus networkQualityStatus = [[NWNetworkQualityMonitor shareInstance] currentNetworkQualityStatus];
NetworkStatus nwStatus = [[NWReachabilityManager shareInstance] currentNetworkStatus];
NSArray *videoPriority = VIDEO_PRIORITY_NORMAL_ENV;
if (networkQualityStatus == SEMP_StrongSemaphore) {
if (deviceLevel == HIGH_END_DEVICE) {
videoPriority = VIDEO_PRIORITY_GOOD_ENV;
} else {
if (nwStatus == ReachableViaWiFi) {
videoPriority = VIDEO_PRIORITY_NORMAL_ENV;
} else {
videoPriority = VIDEO_PRIORITY_BAD_ENV;
}
}
} else {
if (deviceLevel == HIGH_END_DEVICE || deviceLevel == MEDIUM_DEVICE) {
videoPriority = VIDEO_PRIORITY_NORMAL_ENV;
} else {
videoPriority = VIDEO_PRIORITY_BAD_ENV;
}
}
return videoPriority;
}
沉浸式視頻翻頁體感優化
上述方案上線完，回頭看資料，平均加載速度提升了，但仍然有近 200ms 的加載時長，這其中包括了播放器初始化以及下載或加載快取資料、渲染首幀的程序，究其原因，在大量用戶復雜網路環境下，很難保證所有人都有最佳體驗，200ms 在全屏的沉浸式視頻場景中，雖然比之前快了很多，還是會讓用戶感受到瞬間的不流暢，即用戶翻到下一頁后，仍停留了一小段時間才播放了首幀，更糟糕的是，盒馬上的視頻，很多視頻的封面圖是達人自行上傳的，很有可能與首幀不一樣，這樣從封面圖跳到首幀的停頓感就更明顯了，
為達到抖音那種絲滑的感覺，除了上述措施外，還需要在上層體感上再做一層預處理，這里采用了雙播放器策略，如下：
基本流程是，播放當前視頻的同時，預先實體化第二個播放器，加載視頻 url 并播放到首幀后暫停，第 3、4 個視頻進行串行預下載（預下載是純下載的程序，無渲染邏輯），在增加了下一個視頻的 “預播” 機制后，用戶滑到下個視頻時，可以立即從首幀的暫停狀態恢復為播放，不再需要預先顯示封面圖，也提高了播放體感上的速度，除視頻以外的業務資料的渲染，可以放在用戶滑動翻頁的程序中進行，
首個視頻的加載優化
上述優化了用戶翻頁的體驗，但這種沉浸式頁面的第一個視頻的加載體驗，仍需要單獨拿出來優化，因為進入頁面時，并沒有給它留下預加載時機，如下：
如圖所示，進入沉浸式頁面時，總需要先請求頁面 videoList 資料，然后再串行請求第一個視頻的資料，就算加了封面圖，也會讓用戶感受到慢，為此，現在修改策略為右圖，在跳到沉浸式頁面時需要前個頁面提前傳入 videoUrl，提前進行播放，同時進行 mtop 請求，渲染業務資料，這樣保證了視頻與業務資料的加載可以異步執行，由于用戶主要目光是集中在視頻上的，所以從用戶的視角直觀的來看，頁面加載速度變快了，
音頻體驗優化
早期盒馬這邊沒關注音頻方面的優化，也收到了不少反饋，目前制定優化策略如下：
- App 啟動不打斷音樂，
- 進入音頻獨占頁面（如真香視頻、沉浸式視頻）時，打斷音樂，
- 退出 App 或退到后臺時，恢復音樂，
- 音頻播放不受靜音鍵控制（類似抖音），
后續優化方向
-
播放器層提供進一步封裝：封裝視頻加載、預加載、雙播放器、螢屏內首個視頻判斷、退出、暫停等所有邊界邏輯，目前各個業務需要考慮較多這種邊界情況，可以考慮在封裝層收掉，
-
頁面之間播放進度無縫切換：從小尺寸視頻點擊切換到沉浸式全屏程序，實作無縫切換，播放進度承接上個頁面，音頻也不打斷，這樣可以進一步優化沉浸式頁面首個視頻的體驗，徹底實作 “0 耗時” 體感，
-
多視頻同時播放的性能優化：盒馬大多數場景下只會同時播放 1 個視頻，但部分業務需要同時播放多個視頻，此時對記憶體、滾動性能提出較高挑戰，
-
視頻轉 Gif：針對部分場景下滿屏都是視頻又需要同時播放的情況，如果同時實體化 N 個播放器，效果可想而知，考慮嘗試在視頻內容生產階段，同步生產 gif 圖源，特定場景下 APP 可使用 gif 替換播放器實作預覽，
-
視頻剪輯 — 語音轉字幕：之前已基于淘拍能力在盒馬上建立起了視頻剪輯功能，為內容生產者提供常見、簡單易用的編輯能力，考慮新增語音轉字幕模塊，用于增強視頻內盒馬商品力表達，
下一期我們將繼續分享盒馬 iOS / Android 端短視頻的體驗優化實踐，
「視頻云技術」你最值得關注的音視頻技術公眾號，每周推送來自阿里云一線的實踐技術文章，在這里與音視頻領域一流工程師交流切磋，公眾號后臺回復【技術】可加入阿里云視頻云產品技術交流群，和業內大咖一起探討音視頻技術，獲取更多行業最新資訊，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/296110.html
標籤：其他