除了上面说过的字段之外，还多了一个Interlace Flag，表示帧点阵的存储方式，有两种，顺序和隔行交错，为 1 时表示图像数据是以隔行方式存放的。最初 GIF 标准设置此标志的目的是考虑到通信设备间传输速度不理想情况下，用这种方式存放和显示图像，就可以在图像显示完成之前看到这幅图像的概貌，慢慢的变清晰，而不觉得显示时间过长。

帧数据扩展是89a标准增加的，主要包括四个部分。

1、程序扩展结构（Application Extension）主要定义了生成该gif的程序相关信息

2、注释扩展结构（Comment Extension）一般用来储存图片作者的签名信息

3、图形控制扩展结构（Graphic Control Extension）这部分对图片的渲染比较重要

除了前面说过的Dispose Method、Delay、Background Color之外，User Input用来定义是否接受用户输入后再播放下一帧，需要图像解码器对应api的配合，可以用来实现一些特殊的交互效果。

4、平滑文本扩展结构（Plain Text Control Extension）

89a标准允许我们将图片上的文字信息额外储存在扩展区域里，但实际渲染时依赖解码器的字体环境，所以实际情况中很少使用。

以上扩展块都是可选的，只有Label置位的情况下，解码器才会去渲染

说完了基本原理，来分析一下我们的实际问题。

给大量表情包生成缩略图，在不损耗原画质的前提下，尽可能减少图片体积，节省用户流量。

之前说过，单纯依靠resize大法不能满足我们的要求，没办法，只能损耗画质了，主要有两个思路，减少颜色和减少帧数。

减少颜色——图片情况各异，标准难以控制，而且会造成缩略图和原图视觉差异比较明显

减少帧数——通过提取一些间隔帧，比如对于一张10帧的动画，提取其中的提取1,3,5,7,9帧。来减少图片的整体体积，似乎更可行。

先看一个成果，就拿文章开头的图做栗子吧

看上去连贯性不如以前，但是差别不大，作为缩略图的视觉效果可以接受，由于帧数减小，体积也可以得到明显的优化。体积从428K缩到了140K

但是，在开发初期，我们尝试暴力间隔提取帧，把帧重新连接压成新的GIF图，这时，会得到这样的图片。

主要有两个问题。

1、帧数过快

2、能看到明显的残留噪点

分析我们上面的原理，不难找到原因，正是因为大部分GIF存储时采用了公共区域排除和透明区域叠加的优化，如果我们直接间隔抽帧，再拼起来，就破坏了原来的叠加规则，不该露出来的帧露出来了，所以才会产生噪点。

所以，我们首先要把原始信息恢复出来。

两个命令行工具，gifsicle和ImageMagick都提供这样的命令。

还原之后抽帧，重建新的GIF，就可以解决问题2了。

注意重建的时候，可以应用工具再进行对透明度和公共区域的优化压缩。

至于问题1，也是因为我们没有对帧延迟参数Delay Time做处理，直接取原帧的参数，帧数减少了，速度一定会加快。

所以，我们需要把抽去的连续帧的总延时加起来，作为新的延迟数据，这样可以保持缩略图和原图频率一致，看起来不会太过鬼畜，也不会太过迟缓。