從解碼渲染層面對比 PAG 與 lottie

最近由于業(yè)務(wù)需求，需要調(diào)研一下業(yè)界的知名動畫渲染框架。經(jīng)過一些時間的調(diào)研與探索，我將目光聚焦在兩款不錯的動畫框架上。一款是知名的 lottie，一款是騰訊出品的 PAG。

lottie 相信大部分端上的研發(fā)都會或多或少的聽過， lottie 是 airbnb 開源的一款業(yè)界知名的開源動畫框架,通過 AE 制作動畫之后，通過附帶的插件 bodymovin 導(dǎo)出 動畫的 json 文件，端上再通過 json 解析渲染。

lottie 不單單包含端上的渲染 SDK，其實是一套完整的動畫制作工作流。

PAG（Portable Animated Graphics）是騰訊自主研發(fā)的一套完整的動畫工作流解決方案。

我會通過以下幾點的調(diào)研來評估哪個框架對于我們的業(yè)務(wù)而言是更好的選擇。

工作流

我們先來看一下使用 lottie 的簡單流程。

PAG 的流程。

從兩個框架的流程圖可以看出，工作流大體相似，如

由 AE 生成動畫

附帶 AE 插件，可以通過插件導(dǎo)出動畫

lottie 的 bodymovin

PAG 的 PAG Exporter

預(yù)覽

導(dǎo)出文件

端上的渲染 SDK

配置文件

工作流兩者大體相似。所以我將注意力放在了兩者中很顯著的不同點。即 AE 導(dǎo)出的配置文件。

lottie 選擇了 json

PAG 選擇了類似于 protocolbuff 的自研二進制文件。

本篇文章會著重從配置文件的大小和解析性能等角度來分析兩者的性能。

lottie 的 json 配置文件與 PAG 二進制配置文件

先看一個簡單動畫。

動畫大致流程如下：

0s 至 3s，scale?屬性值從 100% 變到 50%。

3s 至 6s，scale?屬性值從 50% 變到 100%，完成動畫。

lottie 的 json

導(dǎo)出的json 文件大致如下。

PAG

由于 PAG 生成的是二進制文件，所以需要對應(yīng)的軟件 PAGViewer 來查看。

我這里就不顯示 PAG 的導(dǎo)出文件了。

文件尺寸比對

從剛才同樣動畫生成的文件來看。

lottie 導(dǎo)出的 json 文件差不多 5kb。

PAG 導(dǎo)出的二進制文件只有 2kb。

差不多少了60%的尺寸。

當(dāng)然，孤例不能充分證明。我通過調(diào)研發(fā)現(xiàn)有類似的benchmark. 結(jié)果如下。

可以看到在導(dǎo)出的配置文件上，PAG 在文件尺寸和壓縮比率上還是有比較大的優(yōu)勢。我思考可能原因如下，PAG 采用了二進制的數(shù)據(jù)結(jié)構(gòu)來存儲動畫信息。二進制數(shù)據(jù)結(jié)構(gòu)能夠非常方便的單文件集 成任何資源，在解碼速度上比 Lottie 所使用的 JSON 文本數(shù)據(jù)快幾十倍。

而在文件大小上，PAG 通過利用動畫文件本身的特點，獲得了極高的壓縮率。通過跳過大 量默認值的存儲，使用動態(tài)比特位來緊湊存儲，相同動畫內(nèi)容可以比同類型方案平均減少 50%左右的文件大小。

為何 PAG 生成的動畫文件如此小

這讓我產(chǎn)生了極大地興趣。閱讀了 PAG 相關(guān)的文檔，大致歸納如下。

PAG 的生成的文件是純二進制文件，解析采用自己的解析引擎

由于采取了二進制格式，所以避免了 json 格式無法避免的冗余字段

PAG 采用動態(tài)比特位壓縮，所以壓縮比極高

PAG 還支持圖片和音頻信息編碼

所以在動畫文件的這一層面，PAG 無疑是更優(yōu)秀的選擇

渲染性能

經(jīng)過我調(diào)研了 lottie 和 PAG 的底層渲染機制。他們的區(qū)別大致如下。

Lottie和渲染層面的實現(xiàn)依賴平臺端接口，因此不同平臺會存在支持的AE特性有所差異、渲染效果不一致等問題。PAG渲染層面使用C++實現(xiàn)，所有平臺共享同一套實現(xiàn)，平臺端只是封裝接口調(diào)用，提供渲染環(huán)境，因此PAG所有平臺支持特性一致，渲染效果一致。并且 lottie 的 bodymovin 支持的AE特性不全，也不支持文本，序列幀等。

所以初步來看，PAG 的性能應(yīng)該會更優(yōu)秀。但是光從調(diào)研角度并不嚴謹，所以還是需要實際的測試才能論證。

矢量動畫渲染性能

可以發(fā)現(xiàn)幾個重要的指標。

文件解碼耗時

lottie 的 json 對比 PAG 的二進制文件有巨大的劣勢，解碼速度幾乎落后 PAG 的 20 倍

首幀渲染耗時 lottie 比 PAG 落后 6 倍

每幀渲染耗時兩者近似

總耗時上 lottie 比 PAG 落后差不多 9 倍

內(nèi)存兩者接近

不同端的渲染效果

不同端的渲染效果指在 iOS 端， android 端或者 web 端，能否通過同一個動畫文件得到同樣的動畫效果。

PAG的整套動畫方案是基于C++跨平臺架構(gòu)研發(fā)的，一直從最底層的動畫插值器，還原到上層的時間軸和圖層渲染樹系統(tǒng)，雖然開發(fā)成本較高，但是所有端共享同一套代碼，天然的能保障跨端渲染一致性。

但是 lottie 采用了各端使用 native 語言的研發(fā)策略，從而導(dǎo)致，不同端上的渲染效果由于平臺的差異性，很難達到一致。所以這里 PAG 的多端一致性更優(yōu)秀。

時間靜態(tài)區(qū)間的不同策略

在動畫文件的特效中，其實大部分的動畫素材實際上并不是整個時間軸上都在變化，或多或少會存在一些畫面靜止的區(qū)間。那么，此時其實就有比較大的優(yōu)化空間。這里我調(diào)研了兩個框架不同的處理方式。

PAG在刷新時，如果遇到這些靜態(tài)區(qū)間，會直接返回上一幀的動畫內(nèi)容，自動跳過任何重復(fù)的繪制。極限情況下，假設(shè)有一個一分鐘的動畫素材，但實際上全程都是靜止的。它對PAG來說就相當(dāng)于一張靜態(tài)圖片，整個刷新的過程中都是0開銷。

Lottie方案中，整個刷新過程都是全量的開銷，因為它每幀都會清空屏幕重新刷新。

這也就意味著如果動畫中靜止區(qū)間較多，那么 PAG 會在渲染性能上比 lottie 有更低的系統(tǒng)開銷。

web 端的支持

刨除 iOS 和 Android 端，其實 web 也是很重要的一個平臺。熟悉 lottie 的人都知道，其實lottie 在 web 端有很多所謂的優(yōu)化技巧，其實這些技巧從某些層面反倒是一些 lottie 本來應(yīng)該規(guī)避的地方。

我們可以對比一下兩者的不同 web 實現(xiàn)思路。

web 端，Lottie使用Web的HTML、CSS 和 Javascript 重新實現(xiàn)了一遍。

PAG 內(nèi)部C++層通過 OpenGL ES 實現(xiàn)了紋理繪制、抗鋸齒、漸變色、blend 等功能，同樣也可以應(yīng)用于 Web 層，不需要用 Web 相關(guān)的技術(shù)重復(fù)實現(xiàn)。具體方案是把 C++ 代碼編譯成 WebAssembly 運行在 Web 中，這里使用了 Emscripten（https://emscripten.org/ ） 實現(xiàn)編譯。先用 CMake 把 libPAG 編譯成靜態(tài)庫，再用 emcc 把靜態(tài)庫和膠水層代碼連接生成 wasm 文件，這樣我們就擁有了一個完整版的 libPAG 庫，

可以看出，由于 PAG 將 C++ 代碼編譯成 WebAssembly運行，所以在 web 層面，PAG 也獲得了比較高的性能，但是 lottie 使用了原生的三件套來實現(xiàn) web 端動畫，性能往往會收到限制。

總結(jié)

在整個工作流中，由于 PAG 在文件生成和解碼都使用了 C++ 進行自研，包括利用 C++ 作為底層渲染工具，所以在端上渲染也保持了相對一致的渲染效果。

可以說 PAG 這套系統(tǒng)的工作流，能夠在使用體驗上獲得比 lottie 更優(yōu)秀的效果，而PAG也將在1月14日對外開源，看到本篇文章后感興趣的小伙伴也可以親身嘗試一下。

官網(wǎng)：https://pag.io/

官方qq群：893379574

web前端 渲染

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。