在一切皆可視訊化的今天，短視訊内容作為移動端産品新的促活點，受到了越來越多的重視與投入。盒馬在秒播、卡頓率、播放成功率等基礎優化之外，在使用者使用體驗上引入了無痕續播能力，提升使用者觀看視訊内容的延續性。本篇将分享盒馬在 iOS 短視訊方面的實踐幹貨。
作者｜神捕
審校｜泰一
跨頁面續播是除秒播外另一個可以從體感上增加使用者體驗的能力。由于一些業務場景需要在不同頁面上播放同一個視訊内容的場景，而這些場景頁面切換往往是連續的，這就要求短視訊的播放也是連續。這樣才能使得體驗上會有連貫性，讓使用者在進入沉浸式頁面時，能流暢的過度，且無感覺的繼續播放，進而産生連續不間斷的感受。下面我們開始介紹盒馬短視訊的跨頁面續播能力和流暢的動畫切換效果的流暢性。
https://v.youku.com/v_show/id_XNTgwNTk4NzQ4MA==.html
如上視訊所示，視訊在清單頁預覽觀看後，使用者很可能繼續點選跳到下一個全屏頁面，進入沉浸式體驗。在這過程中，視訊視窗平滑變大至全屏，視訊進度是延續的，中間沒有感覺到視訊或音頻的停頓感。在頁面傳回後，視訊視窗也有相應的還原效果。
接入簡單，隻需要關心并加一個參數，其它邏輯内聚。
适配性好，支援裁剪模式的切換。
視訊、音頻無縫銜接，不能有任何停頓感。
頁面間播放狀态隔離，互不幹擾。
在方案選擇上，主要考慮了以下三種：
目前盒馬采用的是第 3 種 ——playerView 的複用方式，具體來說，無痕續播的實作，至少需要以下幾個步驟：
使用者點選，從 A 頁面跳轉到 B 頁面，如：domain/path?reusedPlayerView=0xyyyyyy, 在原有業務參數的基礎上，添加一個 reusedPlayerView 參數，把 playerView 傳給下個頁面 。
B 頁面 HMTBPlayerView 的執行個體化：内部執行個體化一個或複用 A 頁面的 reusedPlayerView。
playerView 的大小位置換算，實作切換動畫。
從 B 頁面傳回 A 時，實作退出動畫并返還 playerView。
以上步驟不多，但具體實作起來是比較複雜的，下面我們将圍繞 4 個主要問題的解決過程，來說明具體實作方式。
正常來說，隻要計算好 playerView 的原始 Rect，以及最終 Rect，基于 UIView 做 frame 動畫就可以簡單實作視窗變大效果。但實作時發現，手淘播放器内部重寫了 setFrame 方法，隻要修改了 frame，playerView 将直接顯示為終态，動畫沒有效果。
于是，這裡采用了 CGAffineTransform 的 scale 實作：先把 playerView 的 frame 設定為終态，計算好變化前後的尺寸比例 ratio，設定 <code>playerView.transform = CGAffineTransformMakeScale (ratio, ratio)</code>，将其尺寸等比縮小為初始位置大小，而後就可以執行 transform 的動畫實作從起點到終點的變換。
需要注意的是，此處 ratio 的計算方式，是以 playerView 内真實渲染的視訊尺寸計算，而不是 playerView 本身大小。
視訊渲染本身可以設定為 ScaleAspectFit 或 ScaleAspectFill，目前在盒馬的場景中，存在一種 A 頁面的播放器為 fill mode，且 playerView 固定正方形，但跳轉到 B 頁面時，變成 fit mode，這樣就出現了一個在尺寸變化動畫進行時的 mode 切換的問題。
上述通過 setFrame 并修改 transform 的方式，可以實作把 playerView 大小變換成與動畫前的初始大小一緻，但是，如果此時存在 mode 切換需求就有可能出現計算後的大小不一緻，比如從一個 9：16 長方形的 playerview 變成一個 1 : 1 且 mode 為 fill 的正方形 playerView，此時寬度一緻，但高度明顯多出了，直接做動畫會導緻初始狀态閃動。
這裡的解決方式，我們使用了 maskView 進行 mode 切換過渡：首先，計算 maskView 分别在寬高上的 scale，然後設定 <code>playerView.maskView.transform</code>。計算方式如下：
這樣就實作利用 maskView，把 9:16 的長方形顯示成 1:1 的可見區域，實作動畫的起始位置重合。最後，結合上述 playerView.transform 動畫，再添加一個 maskView.transform 動畫，二者配合，模拟出帶 mode 切換場景下的動畫過渡效果。
在實作了進場動畫之後，最重要的是需要考慮 playerView 複用邏輯，其中比較重要的一點就是 playerView 什麼時候歸還給 A 頁面。
目前我們采用的是租借思路：
有可借 playerView 時，進行借用；
複用的 playerview 不再使用時，及時主動歸還；
當出租方自己要使用時，發現租方還未返還，此時進行主動回收。
具體場景來說：進場時，判斷有 reusePlayerView，則進行複用；當沉浸式視訊（B 頁面，類似抖音）翻到下一個視訊時，上一個視訊進行主動歸還操作，如果使用者又劃回到第 1 個視訊，此時是 new 的 playerView 了；另外，當使用者點選頁面關閉時，主動歸還（如果還未還的話）；特别要注意的是，這裡還增加了一個主動回收機制，場景比如使用者通過一些我們未知的方式，回到了頁面 A，此時 reusePlayerView 是沒有主動歸還的，但頁面 A 自己又需要 play，此時就觸發了主動回收機制，保證目前頁面可用。
有一點需要提一下的是，在頁面傳回時也有動畫，實作方面與上述類似，唯一差別是，傳回時頁面可能 dealloc 了，動畫會有問題，是以我們做法是先把 playerView 從 B 頁面，添加到 window, 做好縮放動畫，結束後，再主動歸還給頁面 A。
在使用播放器複用時，需要考慮一個重要的問題，就是複用後，播放器狀态、設定的隔離。比如，在頁面 A 進入頁面 B 後，播放器無痕續播，但播放器的狀态對 A 來說是暫停，對于 B 來說必須是播放狀态，雖然二者使用的是同一個 playerView。
這種隔離是很有必要的，比如業務想要引導使用者進入頁面 A 的業務，在這裡觀看視訊可以得積分，那麼在他進入頁面 B 時，就不應該繼續結算積分（業務依賴了播放狀态通知）。還有，A 與 B 頁面的播放設定可能不同，A 可能是靜音，B 是有聲音，設定不同，也需要隔離。我們是這樣做的，如下圖（視圖層級）：
圖中，最外層的 view 是盒馬自己封裝的播放器 HMTBPlayerView，内部有一個手淘的 TBMPBPlayerView，大小一樣。我們拿來做複用的其實是 TBMPBPlayerView 這一層，而把業務層的所有設定放在 HMTBPlayerView，這樣的話，在 TBMPBPlayerView 被移走時，重新根據新的 HMTBPlayerView 設定它，做好關聯，而舊的 HMTBPlayerView 設定不受影響，包括播放器回調。
綜上，我們實作了一種播放器複用方式，在播放器内部實作了視窗切換、狀态隔離等邏輯，對 App 使用方來說是幾乎無感的。該方案不僅可用在無痕續播場景上，今後也可以用在 App 内全局播放器執行個體複用優化方向。
「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。公衆号背景回複【技術】可加入阿裡雲視訊雲産品技術交流群，和業内大咖一起探讨音視訊技術，擷取更多行業最新資訊。