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

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

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

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

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

我會通過以下幾點的調研來評估哪個框架對于我們的業務而言是更好的選擇。

工作流

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

PAG 的流程。

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

• 由 AE 生成動畫

• 附帶 AE 插件，可以通過插件導出動畫

  • lottie 的 bodymovin

  • PAG 的 PAG Exporter

• 預覽

• 導出文件

• 端上的渲染 SDK

配置文件

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

lottie 選擇了 json

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

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

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

先看一個簡單動畫。

動畫大致流程如下：

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

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

lottie 的 json

導出的json 文件大致如下。

PAG

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

我這里就不顯示 PAG 的導出文件了。

文件尺寸比對

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

• lottie 導出的 json 文件差不多 5kb。

• PAG 導出的二進制文件只有 2kb。

差不多少了60%的尺寸。

當然，孤例不能充分證明。我通過調研發現有類似的benchmark. 結果如下。

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

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

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

這讓我產生了極大地興趣。閱讀了 PAG 相關的文檔，大致歸納如下。

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

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

PAG 采用動態比特位壓縮，所以壓縮比極高

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

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

渲染性能

經過我調研了 lottie 和 PAG 的底層渲染機制。他們的區別大致如下。

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

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

矢量動畫渲染性能

可以發現幾個重要的指標。

文件解碼耗時

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

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

每幀渲染耗時兩者近似

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

內存兩者接近

不同端的渲染效果

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

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

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

時間靜態區間的不同策略

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

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

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

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

web 端的支持

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

我們可以對比一下兩者的不同 web 實現思路。

• web 端，Lottie使用Web的HTML、CSS 和 Javascript 重新實現了一遍。

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

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

總結

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

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

官網：https://pag.io/

官方qq群：893379574

總結

以上是生活随笔為你收集整理的【PAG组件】-从解码渲染层面对比 PAG 与 lottie的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。