內容作為 App 產品新的促活點，受到了越來越多的重視與投入，短視訊則是增加使用者粘性、增加使用者停留時長的一把利器。短視訊的內容與體驗直接關係到使用者是否願意長時停留，盒馬也提出全鏈路內容視訊化的規劃，以實現商品力表達的提升。目前已有短視訊場景包括：首頁、搜尋、商品詳情、達人秀、沉浸式視訊、真香視訊、盒區首頁 feeds 流、話題、UGC 內容、話題合集落地頁、社群、菜譜、盒拍一鍵剪、直播回放、weex 等。
作者｜神捕
審校｜泰一
本次優化的目標是將盒馬 App 與主流短視訊 App 體驗對齊，如抖音、手淘等。優化具體的硬性指標有播放成功率、卡頓率、秒開率。另外，為了反應使用者觀看短視訊過程中的真實體驗，盒馬還新增了體感指標：首幀渲染時長。
優化效果對比
以上視訊測試基於 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 端短視訊的體驗優化實踐。
「視訊雲技術」你最值得關注的音視訊技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。公眾號後臺回覆【技術】可加入阿里雲視訊雲產品技術交流群，和業內大咖一起探討音視訊技術，獲取更多行業最新資訊。
本作品採用《CC 協議》，轉載必須註明作者和本文連結