作者| 阿裡文娛無線開發專家 風吟
一、背景
在目前直播和短視訊領域，各家公司為了吸引使用者和提升使用者體驗都在創新各種視訊玩法， 例如美顔、美妝、虛拟形象等。這些酷炫的效果背後其實是強大的渲染技術。優酷和來瘋也在 布局這一領域，我們亟需一個底層渲染架構來高效地支撐我們的業務疊代。于是，自主開發一個跨平台、可擴充、高性能的渲染引擎就被提上了日程。
二、引擎設計
1. 引擎特點
前面說了我們的目标是開發一個跨平台、可擴充、高性能的渲染引擎。怎麼了解？下面詳細闡述一下：
1）跨平台。
我們的業務場景涵蓋了移動端和 PC 端。為了提高開發效率，我們要把平台無關的邏輯抽象成公共元件，例如渲染管線、後處理算法等，實作一份代碼，多端共用。
2）可擴充。
跨平台解決了橫向的平台差異問題，而可擴充就是解決業務疊代的縱向問題。 我們将渲染邏輯分解成一個一個的小“零件”，業務方可以像搭積木一樣自由組合這些“零件”， 而算法同學也可以很容易的造“零件”。這樣業務疊代就簡化成了簡單的加減法，效率大大提升。
3）高性能。
音視訊渲染，尤其是視訊渲染，是很耗費計算資源的。在端側有限的計算資源 前提下，還要能實作快速、高品質的渲染效果，就需要我們厘清渲染鍊路中的每個環節，剔除 備援邏輯，實作高效渲染。
2. 引擎架構
在以上思想的指導下，我将渲染引擎分成了兩層： 引擎層（ Engine ）和業務封裝層 （MediaSDK）。
1）引擎層是平台無關的，使用 C++開發，渲染後端使用了各平台都支援的 OpenGL 架構。 核心思想是把渲染鍊路抽象成有向無環圖（DAG），最基礎的元件抽象成插件（Plugin），所有 的資料源（Source）、算法（Filter）、輸出終端（End）都是插件，再定義好插件的輸入/輸出協 議，隻要上下遊插件的資料互動滿足協定就可以自由組合。引擎層的架構圖如下：
2）業務封裝層封裝了引擎層的調用邏輯，在 Android、iOS 和 Windows 平台上對業務方提 供統一調用接口，友善業務同學使用，并提供日志、監控和資源管理等能力。業務封裝層的架 構圖如下：
三、實踐
1. 技術挑戰 實作過程有兩個挑戰，一個是跨平台，一個是高性能。
1）跨平台
a）引擎層雖然使用了 OpenGL 作為渲染後端，但 Android 和 iOS 系統提供的是 OpenGL ES， Windows 提供的是 OpenGL，這兩個版本在 shader 文法上是有差别的，這就需要引擎和算法去 做适配。其次，要使用 OpenGL 需要在每個平台上都實作一個上下文環境，iOS 是 EAGL，Android 是 EGL，Windows 是 WGL。各平台雖然都有封裝好的 GL 元件，但是都不太好用（有 Bug）, 最好的辦法還是自己調用底層 API，這就需要對 OpenGL 有一定的了解；
b）業務封裝層封裝了引擎層的底層接口，對外提供統一業務接口。而業務開發是平台相關 的，語言也不盡相同，Android 是 Java，iOS 是 OC，Windows 是 C++。并且像相機、編/解碼器、 View 這些系統元件各平台實作并不統一。是以開發業務封裝層需要對各語言和系統特性都有較 深入的了解，才能實作易用性和性能的統一。
2）高性能
a）一個思路是盡可能的使用 GPU，解放 CPU，因為 GPU 在視訊處理方面有天然優勢，引 擎裡的計算基本上都放在了 GPU 側，包括圖像色彩空間轉換、後處理等。而且在某些場景下還 會對圖像做下采樣，進一步降低 GPU 使用率；
b）即使算法都使用 GPU 實作，但是還要面對顯存-記憶體資料互傳的問題，從記憶體上載資料 到顯存和從顯存下載下傳資料到記憶體都會阻塞 CPU，導緻 CPU 占用率高。解決方法一是引擎内部 資料都使用紋理傳遞，盡可能減少顯存-記憶體資料互傳。二是使用雙 PBO，異步傳輸資料，但這 個方案需要注意資料同步的問題。
2. 引擎落地
1）算法接入 由于引擎的算法實作都抽象成了插件，而且将渲染的公共邏輯都提取到基類，算法同學接入算法時隻需要關注 shader 本身就可以了，接入是很友善的。理論上隻要符合插件規範，任何算法甚至二方或者三方SDK 都是可以做成插件接入進來的。目前引擎接入的算法能力有：人臉 檢測、美顔、濾鏡、2D 貼紙，未來還将接入美妝、美體、3D 貼紙、Avatar 等。
2）業務接入
渲染引擎提供了多種輸入，如相機采集、幀序列等；多種輸出，如 UI、編碼、幀序列等， 結合前面提到的算法能力，業務方隻需要調用簡單的幾個接口就可以定制自己的渲染管線，從 而實作自己的業務需求。目前渲染引擎接入了來瘋 iOS 和 Android 雙端，來瘋 PC 浏覽器插件， 優來播 iOS 和 Android 雙端。并且穩定疊代了若幹個版本，在多個業務場景中使用，例如秀場直播、電台直播、錄屏直播等。
四、總結與展望
1.沉澱
回顧整個渲染引擎的開發過程，其實是踩了很多坑，也是對渲染技術的一次深入挖掘。整個架構的設計經受住了業務的考驗，也為今後類似 SDK 的開發提供了寶貴的經驗。
2.引擎存在的不足
雖然渲染引擎在目前的應用場景中運作良好，但還是存在一些不足，主要有兩點，一個是 OpenGL 天生的缺陷，即 OpenGL 上下文和線程是強相關的，導緻渲染引擎設計上雖然是一個 DAG，但實際上管線的所有繪制操作都是串行的，不能充分發揮 GPU 性能；二是引擎内部數 據傳輸隻支援 push 的方式，即隻能上遊推動下遊消費資料，而不能下遊主動從上遊拉取資料消 費，這就制約了引擎的使用方式。
3.引擎 2.0
前面提到渲染引擎在低端機上性能不佳，主要原因是 OpenGL 渲染耗時。其實谷歌和蘋果 都已經在最新的代碼中将 OpenGL 标記為 deprecated，分别在推廣新一代渲染架構，即 Vulkan 和 Metal，而微軟也有自家的渲染架構，即 DirectX：
這些新架構思路大同小異，相比 OpenGL 的優點有：支援預編譯 shader、支援多 CPU 線程、 支援直接通路 GPU CommandBuffer 等，對開發者更友好，運作效率更高，甚至能達到成倍性能提升。是以，未來渲染引擎的 2.0 版本将會支援多 backends，包括 Vulkan、Metal 和 DirectX， 以實作更好的性能。