摘要

本文主要介紹以下內(nèi)容：

• 動態(tài)圖片的定義、發(fā)展歷史與現(xiàn)狀，動態(tài)圖片相關(guān)的術(shù)語和概念
• 動態(tài)圖片各主要格式，及簡要對比
• 在 Android 平臺對比 GIF 與 WebP 格式的各項性能參數(shù)，為技術(shù)選型提供參考

一、概述

1.1 動態(tài)圖片

動態(tài)圖片格式泛指基于靜態(tài)圖片格式，擴展其編碼規(guī)則，以幀動畫形式實現(xiàn)動態(tài)展示的一類圖片格式。

動態(tài)圖片與視頻等流媒體技術(shù)在實現(xiàn)上有一定的區(qū)別，但定義的界限比較模糊。總的來說，動態(tài)圖片的編碼規(guī)則更簡潔、更輕量，不采用流式傳輸、較少考慮幀間關(guān)系、無固定幀率，更適合幀數(shù)較少、幀間關(guān)系復(fù)雜的場合。

“表情包”是動態(tài)圖片的常見業(yè)務(wù)形式，是典型的幀數(shù)少、幀間關(guān)系復(fù)雜的案例

1.2 動態(tài)圖片的歷史與現(xiàn)狀

以 GIF89a 為代表的早期動態(tài)圖片技術(shù)出現(xiàn)于 1980 年代末。作為動態(tài)圖片中最具生命力的格式，GIF 在協(xié)議設(shè)計上，已經(jīng)具有不設(shè)固定幀率、可定義單幀區(qū)域等動態(tài)圖片的特性，并被后期動態(tài)圖片格式的規(guī)范所借鑒。

GIF 為早期 Web 頁面實現(xiàn)動態(tài)效果做出了卓越的貢獻，目前依然在表情包、視頻片段截取等業(yè)務(wù)場景中應(yīng)用廣泛。但 GIF 在顏色支持、壓縮率、格式規(guī)范等方面也有其明顯的能力局限性。

諸多方案在試圖解決 GIF 的弊端。在 PC 為主流終端的時期，出現(xiàn)于 20 世紀末的 Flash 是實現(xiàn)效果更優(yōu)的動態(tài)展示方式，具有視覺效果更豐富、媒體承載能力更強等特點，也曾一度取代 GIF 在動態(tài)效果展示方面的地位。但是隨著移動終端的發(fā)展，F(xiàn)lash 的功耗、安全性問題日趨凸顯，F(xiàn)lash 漸漸淡出主流，應(yīng)用場景一再被壓縮。目前，主流瀏覽器已開始有計劃地逐漸阻止 Flash 顯示或運行。

《電腦迷》 2006 第 11 期刊文。從中可以得知，當時的 QQ 采用 Flash 作為動態(tài)圖片展示方式

而在靜態(tài)圖片格式動畫化擴展方面，出現(xiàn)了 Motion JPEG、MNG（基于 PNG）、APNG、WebP、sharpP 等“次時代”格式規(guī)范。其中由 Google 主導(dǎo)開發(fā)并支持的 WebP 格式具有最強的發(fā)展勢頭，尤其是在 Android 平臺上得到了官方支持。但是這些“次時代”規(guī)范推廣速度比較緩慢，且各個平臺、各個瀏覽器的支持程度不一，并未成為事實的標準。這使得 GIF 仍然是目前使用場景最廣泛的一種動圖格式。

1.3 術(shù)語和概念

為了便于后面的介紹，首先引入動態(tài)圖片與靜態(tài)圖片相比具有的新術(shù)語和新概念。

1.3.1 幀

“幀”即動態(tài)圖片中多幅靜態(tài)圖片中的一幅。在動態(tài)圖片編碼中，通常以幀作為單位，記錄圖片數(shù)據(jù)、間隔時間等信息。

后面提到的“幀”既表示一幅靜態(tài)圖片，也可以理解為動態(tài)圖片數(shù)據(jù)中的單個存儲靜態(tài)圖片及動畫信息的數(shù)據(jù)塊。

1.3.2 位置、尺寸、延遲時間、重復(fù)次數(shù)

與靜態(tài)圖片僅能定義尺寸有所差別，動態(tài)圖片在定義畫布的整體尺寸的基礎(chǔ)上，每幀還可以額外定義當前幀的位置和尺寸，從而不必占滿畫布的全部范圍，減小部分占用空間。

延遲時間即當前幀在展示下一幀之前停留的時間。區(qū)別于視頻，動態(tài)圖片的每幀具有獨立的延遲時間。重復(fù)次數(shù)指完整地循環(huán)播放全部幀的次數(shù)。

主流動態(tài)圖片格式都支持定義幀的位置、尺寸、延遲時間和重復(fù)次數(shù)。

1.3.3 Alpha 混合方式與處置方式

與靜態(tài)圖片相比，由于“幀”的引入，動態(tài)圖片還會涉及到幀間關(guān)系的處理。Alpha 混合方式和處置方式是存儲在幀中，用于控制幀間關(guān)系的字段。

簡單來說，Alpha 混合方式用于控制半透明效果的實現(xiàn)方式；處置方式用于說明下一幀將展示時，當前幀應(yīng)如何處理。

Alpha 混合方式支持的配置及意義

處置方式支持的配置及意義

主流動態(tài)圖片格式都包含處置方式字段；APNG、WebP 等格式包含對 Alpha 混合方式的支持。

1.3.4 實例

以信號燈換色的 GIF 動態(tài)圖片為例。

其中，圖 a 為第 1 幀的數(shù)據(jù)，圖 b 為第 2 幀，第 2 幀可以僅存儲需要變化的部分。在設(shè)定第 1 幀的處置方式為“疊加”的條件下，第 2 幀的展示效果即如圖 c 所示。

信號燈換色的例子

二、動態(tài)圖片常用格式

2.1 GIF

2.1.1 幀編碼方式

2.1.1.1 調(diào)色板與顏色量化

GIF 格式引入了調(diào)色板的概念，限定每幀最多可支持的顏色數(shù)量，并建立顏色的索引。圖片數(shù)據(jù)的記錄方式從傳統(tǒng)的色值變?yōu)樗饕?，減少了圖片數(shù)據(jù)的占用空間。

GIF 支持全局調(diào)色板，也支持每幀有自己獨立的調(diào)色板；每個調(diào)色板最多包含 256 種顏色。

在 Photoshop 中將一幅原始圖片存儲為 GIF 格式時，可見其生成的調(diào)色板

為了使調(diào)色板中的顏色盡可能地還原圖片的原始數(shù)據(jù)，調(diào)色板中包含哪些顏色就尤為重要。顏色量化即是“挑選”顏色的過程，以減少顏色并減少失真為目的。顏色量化算法有很多種，較為常用的有八叉樹量化、標準調(diào)色板+誤差擴散等算法，這里不再展開。

從編碼方式的角度，顏色量化和調(diào)色板的引入，是 GIF 區(qū)別于其他主要圖片格式的最大特點。它使 GIF 格式的圖片文件更小，更易于傳輸和分發(fā)。雖然它大幅犧牲了圖片顏色數(shù)量和圖片質(zhì)量，但當圖片本身顏色就較少時，調(diào)色板的優(yōu)勢就尤為明顯。

2.1.1.2 LZW 壓縮

圖像數(shù)據(jù)可經(jīng)調(diào)色板查詢獲得，索引的存儲自然也有優(yōu)化空間。LZW (Lempel-Ziv-Welch) 用于在出現(xiàn)重復(fù)的顏色索引時進行壓縮。這是一個無損的壓縮過程。

簡單來說，LZW 內(nèi)部維護一個字典，首先添加所有出現(xiàn)的原始索引，接下來遍歷并記錄原始數(shù)據(jù)時新出現(xiàn)的子串，并按索引規(guī)則放在字典中，在后面的遍歷中，先嘗試是否可以匹配字典已有的子串，如果沒有則新增一個子串。這個字典可以通過壓縮過程生成，也可以通過解壓過程還原；因此在存儲時，只需存儲壓縮后的內(nèi)容即可。

假定有兩個值（1、2），LZW執(zhí)行過程如下。各操作的執(zhí)行時機與原始數(shù)據(jù)的讀取進度通過背景色一一對應(yīng)。

生成的字典

2.1.2 透明、動態(tài)圖片特性

GIF 支持透明色，不支持透明度和 Alpha 通道。

為 GIF 指定透明色，僅需指定每幀采用調(diào)色板中的哪個顏色作為透明色，并啟用透明色模式即可。在寫圖片數(shù)據(jù)時需要注意，任何出現(xiàn)這個顏色索引的像素都將被置為透明。

動態(tài)圖片特性方面，由于 GIF 沒有透明度的概念，自然也沒有 Alpha 混合方式可供指定。除此之外，章節(jié) 1.3 中提及的特性，GIF 均可實現(xiàn)。

2.1.3 格式結(jié)構(gòu)

GIF 的文件組織方式比較原始，未引入“容器”的概念，一般采用“邏輯頭”或規(guī)定每個分塊的長度來確定分塊位置。

GIF 格式各分塊及其解釋

關(guān)于 GIF 格式及顏色量化的更多信息，可以閱讀本公眾號 GIF簡述及其在QQ音樂的應(yīng)用 一文。

2.2 APNG

2.2.1 從 PNG 到 APNG

APNG 出現(xiàn)于 2004 年，主要由 Mozilla 社區(qū)支持。但不是 PNG 的官方標準。

目前的支持情況：Android 未原生支持，iOS 8 以上版本的 Safari 支持，Chromium 即將支持。

Chromium 代碼庫中，對 APNG 添加支持的提交記錄

APNG 由 PNG 發(fā)展而來，其格式結(jié)構(gòu)在 PNG 的基礎(chǔ)上進行了擴展，與 PNG 有很強的關(guān)聯(lián)性。

APNG 格式結(jié)構(gòu)與 PNG 的關(guān)系，相同背景色的分塊具有相同的數(shù)據(jù) APNG 新增分塊及其解釋

由于 PNG 采用塊的方式組織文件內(nèi)容，即使解碼器不支持 APNG 的動態(tài)圖片功能，也能正常讀取并以靜態(tài)圖片形式展示其首幀。因此 APNG 具有向下兼容的能力。

2.2.2 透明、動態(tài)圖片特性

PNG 本身支持透明度通道，APNG 也具有對透明度的全面支持。

APNG 支持章節(jié) 1.3 所述的全部動態(tài)圖片特性。

2.3 WebP

2.3.1 WebP 概述

WebP 由 Google 于 2010 年發(fā)布，2011 年的版本支持動態(tài)圖片，2012 年的版本支持無損圖片存儲。

WebP 格式的設(shè)計目的是在不犧牲圖片質(zhì)量的條件下，減少文件大小。為了達成這一目的，從幀編碼方式的角度，WebP 引入了無損和有損編碼方式，無損由 WebP 自研，有損使用 VP8 編碼。新編碼方式的引入均使文件大小得到了顯著的改善。

目前的支持情況：Android 有原生支持（4.2 僅支持有損，4.3 及以上支持無損；僅支持靜態(tài)圖片）；Chrome 32 以上版本支持動態(tài)圖片；自編譯 libwebp 可以實現(xiàn) Android 全版本支持。

2.3.2 幀編碼方式

由于有損編碼（也即 VP8 編碼）使用更廣泛，本節(jié)主要討論有損編碼在減少圖片占用空間方面的能力。

2.3.2.1 塊預(yù)測

首先，把每一幀的圖片數(shù)據(jù)分成微小的分塊（Macro Block，宏塊），一般為 4 像素 × 4 像素。

一個分塊的內(nèi)容可以通過其周邊的塊預(yù)測；可通過預(yù)測獲得的部分就可以直接記錄預(yù)測方式，而不記錄實際色值。

例如，確認下圖中 4 × 4 分塊的內(nèi)容，可以通過其左、上兩方向的像素信息，經(jīng)各種預(yù)測方法獲得預(yù)測結(jié)果，并與原始數(shù)據(jù)匹配，驗證哪個預(yù)測結(jié)果最接近原始數(shù)據(jù)。

塊預(yù)測

2.3.2.2 可適應(yīng)的塊量化

圖像可以被分為最多 4 個區(qū)域，并為每個區(qū)域設(shè)置獨立的壓縮參數(shù)。例如對細節(jié)更復(fù)雜的區(qū)域設(shè)置較小的擬合閾值，對細節(jié)簡單的區(qū)域設(shè)置較大的擬合閾值。

可適應(yīng)的塊量化

2.3.3 透明、動態(tài)圖片特性

WebP 支持透明度通道，也有對透明度的完整支持。但有損 WebP 在透明度通道上的實現(xiàn)與傳統(tǒng)格式有所區(qū)別。有損 WebP 包含一個專門存儲透明度通道的分區(qū)。獨立透明度通道分區(qū)也可以針對性地優(yōu)化圖片的占用空間。

WebP 除在處置方式字段的取值范圍上與其他格式有所區(qū)別（未支持“回退”方式），其他的動態(tài)圖片特性均得到了良好的支持。

2.3.4 格式結(jié)構(gòu)

在容器的選擇上，WebP 選用了 RIFF（Resource Interchange File Format，資源交換文件格式）。其格式明確且易于識別。其一，每個 RIFF 塊包含三個部分（識別字、塊大小、實際內(nèi)容）；其二，塊之間可以嵌套，整個文件可以視為一個 RIFF 塊，其中可以包含多層、多個 RIFF 塊。

一個 RIFF 容器的例子

因此，對于 WebP 的格式結(jié)構(gòu)，主要關(guān)注各 RIFF 塊的名稱、含義和功能。

WebP 格式各分塊

三、性能對比與解釋

Android 通過 FrameSequence 庫，提供了 GIF 和 WebP 格式的動態(tài)圖片展示能力。

通過 FrameSequence 庫 Demo，在接入 libgif 和 libwebp 兩個官方提供的編解碼庫后，設(shè)定圖片尺寸、幀率、機型、格式、同時展示的實例數(shù)等前置條件，對比各主要性能參數(shù)。

參數(shù)解釋

• 實例數(shù)：同時異步加載并顯示的實例數(shù)量。用于模擬未經(jīng)優(yōu)化的多幅動態(tài)圖片同時展示時，實際性能開銷情況。
• 加載時間：多個實例同時異步加載，取最終加載完成的時間。
• 卡頓：實際幀率與文件幀率不符的程度。

3.1 幀率、圖片分辨率

以下參數(shù)不變： 圖片格式：GIF / 機型：高配機型 / 實例數(shù)：3

1. 幀率對CPU占用情況影響明顯；不影響圖片文件大小、內(nèi)存大小和加載時間。
2. 幀率過高時，可能引起卡頓情況；幀率越低，對性能影響越小。
3. 圖片分辨率對圖片文件大小、加載時間、內(nèi)存變化影響較大；對CPU占用影響較小。

3.2 格式

以下參數(shù)不變： 幀率：5 / 機型：高配機型 / 實例數(shù)：3

1. 圖片文件大小方面，同參數(shù)的 WebP 圖片比 GIF 圖片小。

2 .加載時間方面，同參數(shù)的 WebP 圖片遠快于 GIF 圖片。

從格式組織方式上的差異上看，不難發(fā)現(xiàn) WebP 快于 GIF 的原因。WebP 采用 Chunk 組織各個數(shù)據(jù)區(qū)域，便于直接通過 Chunk 大小完成尋址；GIF 的分塊采用起始/結(jié)束標記實現(xiàn)，拆分分塊需要讀取起始標記后的整個數(shù)據(jù)流，造成確定分塊的速度偏慢。

3 .CPU 占用方面，同參數(shù)的 WebP 圖片遠高于 GIF 圖片。

CPU 占用偏高的問題，一定程度上制約了在業(yè)務(wù)中使用 WebP 格式。造成該問題的原因與 FrameSequence 的實現(xiàn)方式有關(guān)，在展示時，F(xiàn)rameSequence 未直接緩存每幀的 Bitmap，每次請求重繪時都對當前幀進行了一次解碼。WebP 的解碼消耗遠大于 GIF，導(dǎo)致了 CPU 消耗偏大。

3.3 機型

以下參數(shù)不變： 幀率：5 / 圖片分辨率：810*338 / 實例數(shù)：3

機型的差異，對加載時間和 CPU 占用的影響較大。 對于實際業(yè)務(wù)，有一定必要按機型區(qū)分下發(fā)不同參數(shù)的動態(tài)圖片，必要時用靜態(tài)圖取代動態(tài)圖展示。

3.4 實例數(shù)（同時異步加載并顯示的實例數(shù)量）

以下參數(shù)不變： 幀率：5 / 圖片分辨率：810*338 / 機型：高配機型

實例數(shù)越多，內(nèi)存、CPU 和加載時間均有一定幅度的增加。因此在同一頁面展示多張動態(tài)圖片，并均處于播放狀態(tài)時，需要將性能開銷考慮在內(nèi)。

3.5 綜合結(jié)論

下表以“★”的數(shù)量代表各性能參數(shù)與各前提參數(shù)的相關(guān)程度。

通過上述性能測試結(jié)果，可以導(dǎo)出如下在實際開發(fā)中可供參考的結(jié)論和指引：

在未進行特定優(yōu)化的條件下，受動態(tài)圖片影響最大的性能參數(shù)是 CPU 占用情況，WebP 格式更易受到影響。 加載時間和文件大小方面，WebP 格式比 GIF 具有較大優(yōu)勢，因此在圖片訪問量較大，需要優(yōu)化后臺帶寬和本地 I/O 的場景下，適合引入 WebP。 在實際業(yè)務(wù)中使用動態(tài)圖片時，需要做好同時展示的實例數(shù)的控制，關(guān)注動畫的暫停和 Drawable 的回收。

四、結(jié)論

對于不同的動態(tài)圖片格式，通過對編碼方式、格式特性、性能參數(shù)等角度進行分析，得出如下對比結(jié)果：

從選型的角度來看，如果需要考慮兼容性和展示時的性能消耗，GIF 是不二之選；如果需要考慮傳輸速度、文件大小和圖片質(zhì)量，APNG 和 WebP 會提供更優(yōu)的表現(xiàn)。從未來的發(fā)展上看，WebP 的發(fā)展勢頭最強，在 Android 平臺上，WebP 也最有希望取代 GIF，作為動態(tài)圖片的首選格式。