從350ms到80ms,打造新零售場景下 iOS 短影片的極致絲滑體驗

語言: CN / TW / HK

作者:李凱(神捕)

盒馬 Android 短影片秒播優化方案 :拒絕卡頓,揭祕盒馬鮮生 APP Android 短影片秒播優化方案

“ 內容作為 App 產品新的促活點,受到了越來越多的重視與投入,短影片則是增加使用者粘性、增加使用者停留時長的一把利器。短影片的內容與體驗直接關係到使用者是否願意長時停留,盒馬也提出全鏈路內容影片化的規劃,以實現商品力表達的提升。目前已有短影片場景包括:首頁、搜尋、商品詳情、達人秀、沉浸式影片、真香影片、盒區首頁 feeds 流、話題、UGC 內容、話題合集落地頁、社群、菜譜、盒拍一鍵剪、直播回放、weex 等。”

本次優化的目標是將盒馬 App 與主流短影片 App 體驗對齊,如抖音、手淘等。優化具體的硬性指標有播放成功率、卡頓率、秒開率。另外,為了反應使用者觀看短影片過程中的真實體驗,盒馬還新增了體感指標:首幀渲染時長。

優化效果對比

效果影片可點選檢視:從350ms到80ms,打造新零售場景下 iOS 短影片的極致絲滑體驗

以上影片測試基於 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 請求,渲染業務資料。這樣保證了影片與業務資料的載入可以非同步執行,由於使用者主要目光是集中在影片上的,所以從使用者的視角直觀的來看,頁面載入速度變快了。

音訊體驗優化

早期盒馬這邊沒關注音訊方面的優化,也收到了不少反饋,目前制定優化策略如下:

  1. App 啟動不打斷音樂;

  2. 進入音訊獨佔頁面(如真香影片、沉浸式影片)時,打斷音樂;

  3. 退出 App 或退到後臺時,恢復音樂;

  4. 音訊播放不受靜音鍵控制(類似抖音)。

後續優化方向

  1. 播放器層提供進一步封裝:封裝影片載入、預載入、雙播放器、螢幕內首個影片判斷、退出、暫停等所有邊界邏輯,目前各個業務需要考慮較多這種邊界情況,可以考慮在封裝層收掉;

  2. 頁面之間播放進度無縫切換:從小尺寸影片點選切換到沉浸式全屏過程,實現無縫切換,播放進度承接上個頁面,音訊也不打斷。這樣可以進一步優化沉浸式頁面首個影片的體驗,徹底實現“0 耗時”體感;

  3. 多影片同時播放的效能優化:盒馬大多數場景下只會同時播放 1 個影片,但部分業務需要同時播放多個影片,此時對記憶體、滾動效能提出較高挑戰;

  4. 影片轉 Gif:針對部分場景下滿屏都是影片又需要同時播放的情況,如果同時例項化 N 個播放器,效果可想而知。考慮嘗試在影片內容生產階段,同步生產 gif 圖源,特定場景下 APP 可使用 gif 替換播放器實現預覽;

  5. 影片剪輯—語音轉字幕:之前已基於淘拍能力在盒馬上建立起了影片剪輯功能,為內容生產者提供常見、簡單易用的編輯能力。考慮新增語音轉字幕模組,用於增強影片內盒馬商品力表達。

下一期我們將繼續分享盒馬 iOS / Android 端短影片的體驗優化實踐。

關注【阿里巴巴移動技術】微信公眾號,每週 3 篇移動技術實踐&乾貨給你思考!