從350ms到80ms，揭秘阿里工程師 iOS 短視頻優化方案
內容作為 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 端短視頻的體驗優化實踐。
「視頻雲技術」你最值得關注的音視頻技術公眾號，每周推送來自阿里雲一線的實踐技術文章，在這裡與音視頻領域一流工程師交流切磋。公眾號後台回復【技術】可加入阿里雲視頻雲產品技術交流群，和業內大咖一起探討音視頻技術，獲取更多行業最新信息。
