從“叉手禮”、“水盆羊湯”、“酒暈妝”這些唐朝人生活細節，到精美的坊間造型、充滿意境的詩詞歌賦，《長安十二時辰》不僅以縝密劇情贏得讚譽，更還原了一個真實的大唐長安。在精良製作之上，如何讓觀衆感受 1000 多年前的長安風情、更深度的理解劇情呢？
想必細心的觀衆已經發現，優酷《長安》中出現了很多有人情味的“黑科技”，比如百科 tips、角色伴侶、劇情進展圖等，讓用戶“邊看劇邊互動”，這就是優酷的酷看模式。酷看模式在移動端採用了多路流的同屏展示、智能平滑切換、精準同步和動態化渲染等技術。其中動態化渲染、子母屏和多路流同步播放是酷看模式在端側的核心能力，能夠做到多路流、多機位視頻幀級同步播放。本文接下來要講一講和《長安》相關的背後的一些核心技術。
一、播放器業務框架
優酷的播放器業務框架以一個簡單而優雅的模型解構了所有的播放器業務，在該框架下播放業務是由一組彼此獨立的插件組合實現的。它適應了複雜的播放業務場景，支持着衆多圍繞播放業務的團隊並行開發。通過技術架構的解耦帶來與之相關的技術團隊的組織架構的解耦。
- 播放器視圖模型
如上圖所示，該模型可以描述爲：
1）播放器由多個層組成；
2）層容器中佈局插件；
3）播放器發佈消息；
4）插件訂閱消息；
5）層和插件信息來自配置文件。
- 核心特性
該框架在設計之初就確定了一系列的優良特性作爲設計目標，核心的特性列舉如下：
1）基於消息，事件驅動
引入事件/訂閱的消息機制，插件按需訂閱播放器的事件，根據優先級響應和消費消息；
2）按需配置，自由組合
支持從 xml 配置文件加載層和插件的配置信息，各個業務方在接入業務框架時以搭積木的方式排列組合構造播放器；
3）插件解耦，互不依賴
將所有的播放功能及業務模塊解耦爲彼此獨立的插件，插件之間以消息機制進行通信；
4）標準明確，支持擴展
框架會提供一批功能豐富的標準插件，插件可分組管理，業務方可根據自己的需求定製插件來替換默認實現，也可以新增插件；
5）多例共存，彼此隔離
即可有多個播放器在一個頁面內同時運行，並且從不同的配置創建。
- 爲業務開發帶來的變化
1）技術架構開放化
以插件的形式隔離和封裝不同的業務，清除業務之間的顯式依賴。基於新的業務框架，業務方一方面可以將標準插件排列組合創建個性化的播放器，尤其是一些基礎插件避免重複勞動；另一方面可以自定義新插件替換默認實現或者添加新業務插件，技術框架層面上支持業務團隊獨立完成播放器一整套的個性化定製。
2）業務開發標準化
在該播放器框架下，業務插件的頂層設計是統一的、標準化的。包括一致的構造函數、一致的創建過程、一致的生命週期、一致的播放器事件響應機制等。對於不同團隊業務代碼之間的相互理解和跨團隊統一作戰都有優勢。在標準化的過程中，更容易產出一些通用插件被更多的業務所複用；
3）播放能力服務化
通過引入中間層，播放服務與播放業務邊界逐漸清晰，徹底結束業務代碼與播放能力代碼犬牙交錯的局面，彼此鬆綁，並行前進，播放服務的內聚收斂也具備了向 OTT 等業務類庫級輸出的可能性。
二、酷看百科
酷看百科主要是在視頻播放過程中給出一些類似百科的，輔助用戶觀看的介紹性內容。技術上的需求主要來自兩個方面：
一方面面向運營，運營希望有一個常態化的運營工具，簡單的通過運營後臺修改配置就完成投放，無需技術同學輔助，客戶端也不需要頻繁發版本；
另一方面面向用戶體驗，產品希望能夠根據用戶的偏好和視頻的內容做到 UI 風格多樣可動態調整的展示，能夠較好的與內容融合。
核心技術點
爲了實現“動態化的內容投放和播放模式切換”，就必須解決兩個具體問題。即：
1）播放器如何進行不同播放模式的切換；
2）端側採用什麼技術來實現動態化渲染。
對於問題 1，在播放器業務框架下我們將百科相關的業務也作爲一組插件來實現，並且對播放器的業務插件進行分組，利用框架中插件管理器的插件熱拔插能力動態的啓用和禁用不同組的業務插件。
對於問題 2，我們採用了阿里開源的 Weex 來實現 UI 動態化渲染，無需發版即可實現動態化佈局，再結合後端的定投能力，就能夠實現按照不同樣式模版來動態的投放組件。
三、子母屏
子母屏是酷看中使用較多的一種形態。
所謂子母屏就是將設備區域劃分爲兩大部分，同時投放多屏內容。佔據主視頻焦點的區域稱爲母屏，一般用來播放正片；側邊較小的區域稱爲子屏，一般用來投放與正片內容相關的輔助或者互動性內容。類似於直播比賽時，在畫面中引入場邊教練採訪或者賽況數據。
核心思想：分離母屏正片和子屏的可運營資源
傳統做法是直接將“要在副屏展示的內容”通過後期製作，以合流方式直接壓入正片視頻流中，不過在《長安十二時辰》中我們沒有采用這種方式。因爲這種方式的缺點很明顯：
1）對用戶不友好，缺乏互動性且難以按照用戶的偏好差異投放；
2）對製作不友好，互動資源和正片資源直接耦合；
3）對運營不友好，嚴重依賴後期製作無法獨立運營；
4）對商業化不友好，廣告內容和正片資源直接固化。
這些問題的癥結在於合流的方式導致相關內容以一種較爲粗放的、固化的方式投放給觀衆，無視觀衆的偏好；同樣也忽略了多層次精細化的運營需求，這種基於媒體資源的強綁定關係使得正片內容和運營內容組合關係變得固化且單一。
基於此，我們將母屏和子屏的資源解耦。即不在製作時合流，而是讓正片內容和運營內容嚴格分離，分開存儲和投放。副屏的內容投放將完全交由運營同學，運營同學從模版庫中選擇相應的模版即可快速預覽和投放，不再依賴後期製作。
核心技術點
我們這裏只講一個較爲核心的點即播放器雙屏容器，雙屏的內容投放是彼此分離的，它是我們後續各種玩法的載體。
- 播放器雙屏容器
首先要解決的是子母屏容器的搭建問題。
對於雙屏容器有一些具體的特性要求：
1）母屏的縮放尺寸能夠根據不同的屏幕寬度和視頻資源寬度自適應；
2）子屏同母屏一樣具有交互性，能夠響應用戶的手勢；
3）母屏上下區域都是可投放可交互的運營位；
4）彈幕、進度條等組件可以根據需求跟隨或者脫離母屏。
設計師給出了母屏和子屏可以相互交錯疊壓的酷炫方案，甚至還有延伸至背景的異形遮罩效果，對於動效同步的要求也較高，母屏縮放和子屏移入的動效同步。爲了解決縮放適配問題，我們寫了一套自適應的容器佈局算法，基本的思路是對母屏的佈局按照統一規則進行劃分，將子屏嵌入到母屏的某一層中，能夠基於服務端下發的配置和視頻的尺寸計算出最終子母屏容器的佈局模型和動效參數，然後再根據這套模型驅動渲染視圖以達到預期效果。
雙屏想要具備交互性響應用戶手勢主要的阻礙在於 Z 軸上有覆蓋在視頻層上的諸如彈幕等其他的遮罩層會攔截掉系統的觸屏事件，爲此我們設計了手勢插件作爲觸屏事件的代理，由這個代理按照優先級轉發手勢事件相關的訂閱者，這樣就突破了視圖層級對手勢的限制。
四、雙流同步播放
在解決了子母屏的自動佈局和交互性問題之後，用子母屏來承載雙路流的視頻同步播放則是更具挑戰的問題。
雙路流播放有兩個備選方案：
1）單播放器實例，子屏和母屏共同作爲一個或者一組播放器插件存在，共享上下文；
2）雙播放器實例，子屏和母屏各作爲一個播放器實例存在，具有各自的上下文；
我們選擇了雙實例的方案，因爲：
1）產品形體來看，主副屏之間的主從關係是相對明確的，體現爲副屏對主屏的單向狀態訂閱和同步；
2）工程角度來看，保持模型的簡單性是有益的，避免因爲有兩個播放器引入複雜的上下文結構；
雙路流的觀影體驗設計較爲超前的，在當前的硬件條件下，能夠讓配置不是很高的用戶也能夠暢享酷看模式是非常有挑戰的。
- 主要的困難點：
1）系統性的誤差控制，需要全鏈路來保證
從視頻生產開始，視頻剪輯工具可能就具有 10ms 的以上誤差，然後再經過運營平臺錄入錨點，如果運營工具做不到幀對齊級別的錨點自動計算，那麼最終對齊的效果也會受人工計算錨點偏差的影響；事實上，從生產到投放，再到端側解碼渲染，這個系統誤差一直在累積傳遞，對於這個誤差的控制是個系統工程。
2）播放器對做精準對齊提供的工具有限
播放器基礎 Api 本身執行也在 10m 這個量級，例如啓動、暫停、Seek、變速等接口以及一些狀態回調都是異步的，甚至系統的 sleep 精度也是有限的，這些方法本身的執行時機和耗時都是不確定的，調用這些 Api 實現 40ms 級別的同步就好像大象捉老鼠一般困難。
3）設備多樣性和運行時隨機性造成的適配困難
Android 設備碎片化嚴重，性能分佈頻譜寬廣，在單次追幀同步過程中，運行時狀態滿隨機性較大，無法事先給出全局通用的經驗值作爲參數進行補償。
- 兩個播放器同步的解決思路：
1）首先要解決同步位置的錨定，這個位置目前是以主視頻時間軸爲基準，這裏採納主視頻的時鐘，有音頻時鐘，視頻時鐘或者外部時鐘三種選擇；
2）要解決對齊的技術手段本身不精準的問題，對齊的技術手段較多，對齊的過程根本上是一個“調節-反饋-修正”的遞歸過程，雖然模型相對簡單，但是需要達到想要的效果具體實現並不容易，涉及較多的實現技巧，例如提供更加精準的 seek 接口，儘量讓這些 Api 產生的誤差偏離方向一致，這樣我們就便於在累積誤差上做補償；
3）由於機型千差萬別，運行時狀態又充滿隨機性。這裏就需要逐一梳理，消除隨機性的影響。例如，爲了適應網絡狀態的隨機性，實現全局統一的緩存策略；爲了平抑個體性能差異，我們引入了部分統計學的方法來做追幀補償，統計當前設備最近幾次追幀差值的方差和標準差作爲下一次補償追幀的參數；針對人眼對播放速度變化的敏感性，訓練變速追幀的最佳變速曲線等。
通過架構設計、工程優化、算法升級和有針對性適配，打出全鏈路的組合拳，最終實現了多路流精準的同步播放，呈現了不錯的效果。
作者 | 阿里文娛無線開發專家 卜道