动态图片技术 : 历史、格式与性能

摘要

本文主要介绍以下内容：

• 动态图片的定义、发展历史与现状，动态图片相关的术语和概念
• 动态图片各主要格式，及简要对比
• 在 Android 平台对比 GIF 与 WebP 格式的各项性能参数，为技术选型提供参考

一、概述

1.1 动态图片

动态图片格式泛指基于静态图片格式，扩展其编码规则，以帧动画形式实现动态展示的一类图片格式。

动态图片与视频等流媒体技术在实现上有一定的区别，但定义的界限比较模糊。总的来说，动态图片的编码规则更简洁、更轻量，不采用流式传输、较少考虑帧间关系、无固定帧率，更适合帧数较少、帧间关系复杂的场合。

“表情包”是动态图片的常见业务形式，是典型的帧数少、帧间关系复杂的案例

1.2 动态图片的历史与现状

以 GIF89a 为代表的早期动态图片技术出现于 1980 年代末。作为动态图片中最具生命力的格式，GIF 在协议设计上，已经具有不设固定帧率、可定义单帧区域等动态图片的特性，并被后期动态图片格式的规范所借鉴。

GIF 为早期 Web 页面实现动态效果做出了卓越的贡献，目前依然在表情包、视频片段截取等业务场景中应用广泛。但 GIF 在颜色支持、压缩率、格式规范等方面也有其明显的能力局限性。

诸多方案在试图解决 GIF 的弊端。在 PC 为主流终端的时期，出现于 20 世纪末的 Flash 是实现效果更优的动态展示方式，具有视觉效果更丰富、媒体承载能力更强等特点，也曾一度取代 GIF 在动态效果展示方面的地位。但是随着移动终端的发展，Flash 的功耗、安全性问题日趋凸显，Flash 渐渐淡出主流，应用场景一再被压缩。目前，主流浏览器已开始有计划地逐渐阻止 Flash 显示或运行。

《电脑迷》 2006 第 11 期刊文。从中可以得知，当时的 QQ 采用 Flash 作为动态图片展示方式

而在静态图片格式动画化扩展方面，出现了 Motion JPEG、MNG（基于 PNG）、APNG、WebP、sharpP 等“次时代”格式规范。其中由 Google 主导开发并支持的 WebP 格式具有最强的发展势头，尤其是在 Android 平台上得到了官方支持。但是这些“次时代”规范推广速度比较缓慢，且各个平台、各个浏览器的支持程度不一，并未成为事实的标准。这使得 GIF 仍然是目前使用场景最广泛的一种动图格式。

1.3 术语和概念

为了便于后面的介绍，首先引入动态图片与静态图片相比具有的新术语和新概念。

1.3.1 帧

“帧”即动态图片中多幅静态图片中的一幅。在动态图片编码中，通常以帧作为单位，记录图片数据、间隔时间等信息。

后面提到的“帧”既表示一幅静态图片，也可以理解为动态图片数据中的单个存储静态图片及动画信息的数据块。

1.3.2 位置、尺寸、延迟时间、重复次数

与静态图片仅能定义尺寸有所差别，动态图片在定义画布的整体尺寸的基础上，每帧还可以额外定义当前帧的位置和尺寸，从而不必占满画布的全部范围，减小部分占用空间。

延迟时间即当前帧在展示下一帧之前停留的时间。区别于视频，动态图片的每帧具有独立的延迟时间。重复次数指完整地循环播放全部帧的次数。

主流动态图片格式都支持定义帧的位置、尺寸、延迟时间和重复次数。

1.3.3 Alpha 混合方式与处置方式

与静态图片相比，由于“帧”的引入，动态图片还会涉及到帧间关系的处理。Alpha 混合方式和处置方式是存储在帧中，用于控制帧间关系的字段。

简单来说，Alpha 混合方式用于控制半透明效果的实现方式；处置方式用于说明下一帧将展示时，当前帧应如何处理。

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

处置方式支持的配置及意义

主流动态图片格式都包含处置方式字段；APNG、WebP 等格式包含对 Alpha 混合方式的支持。

1.3.4 实例

以信号灯换色的 GIF 动态图片为例。

其中，图 a 为第 1 帧的数据，图 b 为第 2 帧，第 2 帧可以仅存储需要变化的部分。在设定第 1 帧的处置方式为“叠加”的条件下，第 2 帧的展示效果即如图 c 所示。

信号灯换色的例子

二、动态图片常用格式

2.1 GIF

2.1.1 帧编码方式

2.1.1.1 调色板与颜色量化

GIF 格式引入了调色板的概念，限定每帧最多可支持的颜色数量，并建立颜色的索引。图片数据的记录方式从传统的色值变为索引，减少了图片数据的占用空间。

GIF 支持全局调色板，也支持每帧有自己独立的调色板；每个调色板最多包含 256 种颜色。

在 Photoshop 中将一幅原始图片存储为 GIF 格式时，可见其生成的调色板

为了使调色板中的颜色尽可能地还原图片的原始数据，调色板中包含哪些颜色就尤为重要。颜色量化即是“挑选”颜色的过程，以减少颜色并减少失真为目的。颜色量化算法有很多种，较为常用的有八叉树量化、标准调色板+误差扩散等算法，这里不再展开。

从编码方式的角度，颜色量化和调色板的引入，是 GIF 区别于其他主要图片格式的最大特点。它使 GIF 格式的图片文件更小，更易于传输和分发。虽然它大幅牺牲了图片颜色数量和图片质量，但当图片本身颜色就较少时，调色板的优势就尤为明显。

2.1.1.2 LZW 压缩

图像数据可经调色板查询获得，索引的存储自然也有优化空间。LZW (Lempel-Ziv-Welch) 用于在出现重复的颜色索引时进行压缩。这是一个无损的压缩过程。

简单来说，LZW 内部维护一个字典，首先添加所有出现的原始索引，接下来遍历并记录原始数据时新出现的子串，并按索引规则放在字典中，在后面的遍历中，先尝试是否可以匹配字典已有的子串，如果没有则新增一个子串。这个字典可以通过压缩过程生成，也可以通过解压过程还原；因此在存储时，只需存储压缩后的内容即可。

假定有两个值（1、2），LZW执行过程如下。各操作的执行时机与原始数据的读取进度通过背景色一一对应。

生成的字典

2.1.2 透明、动态图片特性

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

为 GIF 指定透明色，仅需指定每帧采用调色板中的哪个颜色作为透明色，并启用透明色模式即可。在写图片数据时需要注意，任何出现这个颜色索引的像素都将被置为透明。

动态图片特性方面，由于 GIF 没有透明度的概念，自然也没有 Alpha 混合方式可供指定。除此之外，章节 1.3 中提及的特性，GIF 均可实现。

2.1.3 格式结构

GIF 的文件组织方式比较原始，未引入“容器”的概念，一般采用“逻辑头”或规定每个分块的长度来确定分块位置。

GIF 格式各分块及其解释

关于 GIF 格式及颜色量化的更多信息，可以阅读本公众号 GIF简述及其在QQ音乐的应用 一文。

2.2 APNG

2.2.1 从 PNG 到 APNG

APNG 出现于 2004 年，主要由 Mozilla 社区支持。但不是 PNG 的官方标准。

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

Chromium 代码库中，对 APNG 添加支持的提交记录

APNG 由 PNG 发展而来，其格式结构在 PNG 的基础上进行了扩展，与 PNG 有很强的关联性。

APNG 格式结构与 PNG 的关系，相同背景色的分块具有相同的数据 APNG 新增分块及其解释

由于 PNG 采用块的方式组织文件内容，即使解码器不支持 APNG 的动态图片功能，也能正常读取并以静态图片形式展示其首帧。因此 APNG 具有向下兼容的能力。

2.2.2 透明、动态图片特性

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

APNG 支持章节 1.3 所述的全部动态图片特性。

2.3 WebP

2.3.1 WebP 概述

WebP 由 Google 于 2010 年发布，2011 年的版本支持动态图片，2012 年的版本支持无损图片存储。

WebP 格式的设计目的是在不牺牲图片质量的条件下，减少文件大小。为了达成这一目的，从帧编码方式的角度，WebP 引入了无损和有损编码方式，无损由 WebP 自研，有损使用 VP8 编码。新编码方式的引入均使文件大小得到了显著的改善。

目前的支持情况：Android 有原生支持（4.2 仅支持有损，4.3 及以上支持无损；仅支持静态图片）；Chrome 32 以上版本支持动态图片；自编译 libwebp 可以实现 Android 全版本支持。

2.3.2 帧编码方式

由于有损编码（也即 VP8 编码）使用更广泛，本节主要讨论有损编码在减少图片占用空间方面的能力。

2.3.2.1 块预测

首先，把每一帧的图片数据分成微小的分块（Macro Block，宏块），一般为 4 像素 × 4 像素。

一个分块的内容可以通过其周边的块预测；可通过预测获得的部分就可以直接记录预测方式，而不记录实际色值。

例如，确认下图中 4 × 4 分块的内容，可以通过其左、上两方向的像素信息，经各种预测方法获得预测结果，并与原始数据匹配，验证哪个预测结果最接近原始数据。

块预测

2.3.2.2 可适应的块量化

图像可以被分为最多 4 个区域，并为每个区域设置独立的压缩参数。例如对细节更复杂的区域设置较小的拟合阈值，对细节简单的区域设置较大的拟合阈值。

可适应的块量化

2.3.3 透明、动态图片特性

WebP 支持透明度通道，也有对透明度的完整支持。但有损 WebP 在透明度通道上的实现与传统格式有所区别。有损 WebP 包含一个专门存储透明度通道的分区。独立透明度通道分区也可以针对性地优化图片的占用空间。

WebP 除在处置方式字段的取值范围上与其他格式有所区别（未支持“回退”方式），其他的动态图片特性均得到了良好的支持。

2.3.4 格式结构

在容器的选择上，WebP 选用了 RIFF（Resource Interchange File Format，资源交换文件格式）。其格式明确且易于识别。其一，每个 RIFF 块包含三个部分（识别字、块大小、实际内容）；其二，块之间可以嵌套，整个文件可以视为一个 RIFF 块，其中可以包含多层、多个 RIFF 块。

一个 RIFF 容器的例子

因此，对于 WebP 的格式结构，主要关注各 RIFF 块的名称、含义和功能。

WebP 格式各分块

三、性能对比与解释

Android 通过 FrameSequence 库，提供了 GIF 和 WebP 格式的动态图片展示能力。

通过 FrameSequence 库 Demo，在接入 libgif 和 libwebp 两个官方提供的编解码库后，设定图片尺寸、帧率、机型、格式、同时展示的实例数等前置条件，对比各主要性能参数。

参数解释

• 实例数：同时异步加载并显示的实例数量。用于模拟未经优化的多幅动态图片同时展示时，实际性能开销情况。
• 加载时间：多个实例同时异步加载，取最终加载完成的时间。
• 卡顿：实际帧率与文件帧率不符的程度。

3.1 帧率、图片分辨率

以下参数不变： 图片格式：GIF / 机型：高配机型 / 实例数：3

1. 帧率对CPU占用情况影响明显；不影响图片文件大小、内存大小和加载时间。
2. 帧率过高时，可能引起卡顿情况；帧率越低，对性能影响越小。
3. 图片分辨率对图片文件大小、加载时间、内存变化影响较大；对CPU占用影响较小。

3.2 格式

以下参数不变： 帧率：5 / 机型：高配机型 / 实例数：3

1. 图片文件大小方面，同参数的 WebP 图片比 GIF 图片小。

2 .加载时间方面，同参数的 WebP 图片远快于 GIF 图片。

从格式组织方式上的差异上看，不难发现 WebP 快于 GIF 的原因。WebP 采用 Chunk 组织各个数据区域，便于直接通过 Chunk 大小完成寻址；GIF 的分块采用起始/结束标记实现，拆分分块需要读取起始标记后的整个数据流，造成确定分块的速度偏慢。

3 .CPU 占用方面，同参数的 WebP 图片远高于 GIF 图片。

CPU 占用偏高的问题，一定程度上制约了在业务中使用 WebP 格式。造成该问题的原因与 FrameSequence 的实现方式有关，在展示时，FrameSequence 未直接缓存每帧的 Bitmap，每次请求重绘时都对当前帧进行了一次解码。WebP 的解码消耗远大于 GIF，导致了 CPU 消耗偏大。

3.3 机型

以下参数不变： 帧率：5 / 图片分辨率：810*338 / 实例数：3

机型的差异，对加载时间和 CPU 占用的影响较大。 对于实际业务，有一定必要按机型区分下发不同参数的动态图片，必要时用静态图取代动态图展示。

3.4 实例数（同时异步加载并显示的实例数量）

以下参数不变： 帧率：5 / 图片分辨率：810*338 / 机型：高配机型

实例数越多，内存、CPU 和加载时间均有一定幅度的增加。因此在同一页面展示多张动态图片，并均处于播放状态时，需要将性能开销考虑在内。

3.5 综合结论

下表以“★”的数量代表各性能参数与各前提参数的相关程度。

通过上述性能测试结果，可以导出如下在实际开发中可供参考的结论和指引：

在未进行特定优化的条件下，受动态图片影响最大的性能参数是 CPU 占用情况，WebP 格式更易受到影响。 加载时间和文件大小方面，WebP 格式比 GIF 具有较大优势，因此在图片访问量较大，需要优化后台带宽和本地 I/O 的场景下，适合引入 WebP。 在实际业务中使用动态图片时，需要做好同时展示的实例数的控制，关注动画的暂停和 Drawable 的回收。

四、结论

对于不同的动态图片格式，通过对编码方式、格式特性、性能参数等角度进行分析，得出如下对比结果：

从选型的角度来看，如果需要考虑兼容性和展示时的性能消耗，GIF 是不二之选；如果需要考虑传输速度、文件大小和图片质量，APNG 和 WebP 会提供更优的表现。从未来的发展上看，WebP 的发展势头最强，在 Android 平台上，WebP 也最有希望取代 GIF，作为动态图片的首选格式。