从统计模块的设计谈代码的解耦和聚
APNG与客户端动图策略
Jun
2
在前端和App，现在最常用的图片资源文件，不用想肯定是PNG了。而作为客户端优化的重头戏，压缩PNG资源大小总是我们最关心的东西。有这么一个网站，tinypng，是现在主流压缩png的工具/服务中压缩率最高的没有之一，大家都很喜欢它。不过不开心的是，这个网站提供的是在线服务（虽然有接口访问）并且量大是要收费的。因此，我们需要寻求一个自己适用的PNG压缩方案，就算无法实现，也能对相关内容有更深入的了解。
PNG的构成
压缩PNG，我们首先要了解png的构成。谷歌一下可以参看png格式白皮书（https://www.w3.org/TR/PNG/），我们了解到以下基本信息：
PNG基本格式
png最基本的格式非常简单，只有一个png头和一大堆数据块（chunk）。
1. png头是完全固定的8个字节：0x89504E47 0x0D0A1A0A，里面包含平时看到的PNG三个字符。
2. 下面是复数个数据块，每个数据块包涵长度(ulong)，标题(char[4])，数据，和crc32的校验码(long)，可以直接写出输出数据块的方法：
结构如下：
当然，这个结构只是png的封装框架，并没有实际业务意义。我们可以考虑一下，作为一个图片最少需要什么：
1. 长宽信息
2. 每个像素的颜色
有了这两部分，就可以称为一个基本并且最小的图片了。因此回到白皮书上的内容，作为PNG的主要数据，我们最少需要这么两个Chunk，分别是IHDR，图片header块和IDAT，图片数据块。
IHDR
作为图片实际文件头信息，其中的信息是固定切明确的，数据不长直接上图：
除了长宽下面最关键的是图片类型和颜色深度。
1. PNG图片类型分为几大类，分别是：
- 0:灰度图像
- 2:彩色图像
- 3:索引彩色图像
- 4:带alpha灰度图像
- 6:带alpha彩色图像
灰度图我们使用的比较少，因此事实上最常见的应该是2,6,3这三种了，接下来会沿着这三种图像类型讲解。
2. 而颜色深度呢，是指的每个通道颜色的表示位数，比如我们常见的颜色如#ff0000，红色通道用0xff表示的，这就是8位。因此事实上非灰度图的一般图片，颜色深度都是常用的8。毕竟16位的颜色深度一般的显示器也显示不出来嘛。
后面三个数据，压缩方法一般是0，就是默认的压缩算法，下文解释；过滤器和隔行扫描就是更高级的功能了，而且对文件压缩没啥帮助，所以在此不提。
IDAT
图像的实际数据，PNG就是无损压缩，所以和上面想的一样，把每个像素的颜色罗列在一起就可以了。其实特定的规定是没一行开始有一个byte的标志为，暂时当它是0x00吧。所以实际储存的数据看起来是：
0x00 RGB RGB RGB RGB
0x00 RGB RGB RGB RGB
0x00 RGB RGB RGB RGB
0x00 RGB RGB RGB RGB
这样的东西。当然，这是原始数据，这些数据实际储存的时候经过了一次压缩，压缩算法虽然是通过上门那个header那儿制定的，不过业界事实上只实现了一个标准算法，即zlib的deflate算法（至于zlib是怎么回事儿，这又是一段孽缘了），就当是一个普通的无损压缩算法好了。最后，IDAT中储存的，就是压缩后的像素颜色数据了。
另外，每一行的0x00其实是一个当前行算法滤镜的枚举，一共有5种滤镜，比如如果是0x01的话是减法滤镜，每一个像素储存的颜色是 display - last 得到的数。不同的计算方法可以使得每一行实际储存的颜色数据有一些不同，当然，长度还是不会变的。
完成Hello World
有了以上信息，最后还有一个IEND，而且没有数据内容的块作为表示png文件的结束，我们就可以着手编写一个最基本的png了，直接看代码：
这里绘制了一个2x2的彩色图像(type=2)图像，其中4个像素的颜色分别是0xff0000,0x00ff00,0x00ff00,0xff0000，运行一下，就看到我们想要的东西了。
加上透明通道
刚才的图像是type=2没有alpha通道的，因此这里换成6这张图片就变成带透明通道的了。带透明通道后IDAT段储存的颜色将多出alpha数据，比如：
0x00 RGBA RGBA RGBA RGBA
因此对应我们稍作改动就可以完成了
PNG8
接下来就提到PNG8了，png8是各大png压缩主打的东西，即type=3的索引彩色图像。这种格式和gif类似，在图像数据前用了一个表格储存颜色，最多256个颜色。然后实际的像素数据就直接引用颜色索引就可以了。虽然颜色数大大的减少了，但是像素颜色数据一下子减少了66%，是非常爽的。
回到png，我们需要多一个块来储存颜色索引，是PLTE块，它的内容也非常非常简单，把所有的颜色罗列在一起就可以了，顺序数就是索引。因此，我们在helloworld上继续添加：
然后实际数据段改为填写索引id就可以了：
PNG8Alpha
png的索引彩色图像一开始设计的时候是没有考虑alpha的，然后需要来了，还是得加上。怎么办，不得已，我们再添加一个块，专门来描述每一个索引颜色的alpha值。因此继续改动helloworld，加上了描述索引颜色透明度的tRNS块：
当然，不同的透明度是不同的颜色，现在我们需要4个颜色来实现。
小结
到此为止，我们得到了世界上99%的png的基本格式的结构，世界上99%的png我们拆开看都逃不出这个结构，依赖这些信息，我们也可以进行接下来的分析了。
PNG压缩
裁剪无用块
从简入繁，最简单的，我们看到,普通的png加上IEND必要块有4块，png8多个PLTE块，带alpha的再多一个tRNS块，其它的多半是无关紧要的。标准的png可能有如下块：
可以看到，其中大部分非必要块主要是描述了拍摄的原始信息（如图像γ数据(gamma)块，图像直方图数据块，物理像素尺寸数据块），或者是辅助信息（各种文本信息数据块）之类的，这些东西在图像用于调整处理(PS)或者归档的时候意义巨大，但是对于web或者app使用，完全没有意义。比如ps默认保存出来的png，最少20kb，除了这些甚至还夹带了图层信息，对于我们来说是完全没用的。
还有是IDAT本身，PNG的图像数据本身是可以放在多个IDAT中以实现渐进加载等效果，没必要的话把它们合并到同一张图像上能很大程度上增加IDAT压缩率减小IDAT段大小。
所以作为PNG压缩的第一步，无用块删删删。
颜色优化
首先，我们的目标是把png都转换为png8。毕竟我们的实际使用场景大部分都是图标啊小icon啊什么的，现在又都是扁平化设计，颜色数肯定不多，因此压256色绰绰有余，而且显然，颜色数越少PLTE长度越短，并且IDAT数据复杂度降低压缩率也会增加。
除了这个角度，非常简单的icon，甚至8位颜色深度也没必要了，4，2，1往下降都是没问题的，不过对于颜色数本来就少的图像，这个做法难度高而且减小大小并不多，因此比较得不偿失。
当然，到底怎么把图像的颜色数压下来，这就和png无关是图像领域的另一个大坑了。
IDAT结构优化
IDAT的原生数据会通过deflate算法无损压缩，这种常见的算法意味着，原始数据中重复元素越多，压缩率就越高。那原始数据怎么优化呢，这就是一开始提到的IDAT行算法滤镜提供的功能了。算法滤镜的设计目的就是“The purpose of these filters is to prepare the image data for optimum compression.”
一共有4种算法滤镜：
- 1:Sub滤镜 储存数据 ＝ 显示数据 － 左数据
- 2:Up滤镜 储存数据 ＝ 显示数据 － 上数据
- 3:Average滤镜 储存数据 ＝ 显示数据 - floor((左数据 + 上数据) / 2)
- 4:Paeth滤镜 储存数据 ＝ 显示数据 - PaethPredictor(左数据, 上数据, 左上数据) magic多项式
比如，减滤镜非常适合过滤渐变性较强的数据，越稳定的渐变可以转换为非常单一的数据以方便压缩（一个减法且持续是#010000的数据可以成为从#000000到#ff0000的渐变）。双向和四向平均滤镜则用在更复杂的场景。
这个也是一个大坑，并且从实际上看做这个优化非常困难。
使用工具
分析结束，可以看到PNG的压缩点都需要大量图形学算法支持，清晰了解这一情况，我们还是选择使用工具来解决问题吧。压缩PNG的工具，除了最流行的tinypng网站，就要数开源的pngquant了（https://pngquant.org/）。因此，我们首先把pngquant和需要对标的tinypng放在一起比较。
小图压缩
提供的是颜色数远低于256的图，使用tinypng压缩，和用pngquant在30和90两个质量数进行压缩，结果如下：
注意到pngquant的图多包涵gAMA和sRGB两段，删除后和tinypng大小一致。
1. 颜色数低于256的图，两者都没进行有损压缩，直接转换为了png8。
2. pngquant转换时保留了和颜色有关的多余块（比如gamma信息），因此比tinypng稍大，删除后完全一致。
大图压缩
提供了一张颜色丰富的图进行类似测试，结果如下：
1. 都尝试压缩为了png8
2. 其实有损压缩算法上不分伯仲，差距不大，和大小相比基本是一分钱一分货
3. tinypng明显用了较多的平滑处理，使得画面细节相对柔和很多，没有明显的锯齿感，感官确实优于pngquant
结论
在web和app开发的大部分场景下，对于颜色数小于256的图像，用pngquant和用tinypng处理完全没有区别，pngquant需要增加脚本处理掉多余块，但是肯定比使用在线且受限的tinypng方便。
在处理复杂图像上，本身将复杂图像处理为png8是否合适就有待商榷，如果确实要这么做，tinypng优于pngquant。
PNG的构成
压缩PNG，我们首先要了解png的构成。谷歌一下可以参看png格式白皮书（https://www.w3.org/TR/PNG/），我们了解到以下基本信息：
PNG基本格式
png最基本的格式非常简单，只有一个png头和一大堆数据块（chunk）。
1. png头是完全固定的8个字节：0x89504E47 0x0D0A1A0A，里面包含平时看到的PNG三个字符。
2. 下面是复数个数据块，每个数据块包涵长度(ulong)，标题(char[4])，数据，和crc32的校验码(long)，可以直接写出输出数据块的方法：
def write_ chunk(f, title, data):
f.write(struct.pack('>L',len(data)))
f.write(title)
f.write(data)
f.write(struct.pack('>l',binascii.crc32(title + data)))结构如下：
当然，这个结构只是png的封装框架，并没有实际业务意义。我们可以考虑一下，作为一个图片最少需要什么：
1. 长宽信息
2. 每个像素的颜色
有了这两部分，就可以称为一个基本并且最小的图片了。因此回到白皮书上的内容，作为PNG的主要数据，我们最少需要这么两个Chunk，分别是IHDR，图片header块和IDAT，图片数据块。
IHDR
作为图片实际文件头信息，其中的信息是固定切明确的，数据不长直接上图：
除了长宽下面最关键的是图片类型和颜色深度。
1. PNG图片类型分为几大类，分别是：
- 0:灰度图像
- 2:彩色图像
- 3:索引彩色图像
- 4:带alpha灰度图像
- 6:带alpha彩色图像
灰度图我们使用的比较少，因此事实上最常见的应该是2,6,3这三种了，接下来会沿着这三种图像类型讲解。
2. 而颜色深度呢，是指的每个通道颜色的表示位数，比如我们常见的颜色如#ff0000，红色通道用0xff表示的，这就是8位。因此事实上非灰度图的一般图片，颜色深度都是常用的8。毕竟16位的颜色深度一般的显示器也显示不出来嘛。
后面三个数据，压缩方法一般是0，就是默认的压缩算法，下文解释；过滤器和隔行扫描就是更高级的功能了，而且对文件压缩没啥帮助，所以在此不提。
IDAT
图像的实际数据，PNG就是无损压缩，所以和上面想的一样，把每个像素的颜色罗列在一起就可以了。其实特定的规定是没一行开始有一个byte的标志为，暂时当它是0x00吧。所以实际储存的数据看起来是：
0x00 RGB RGB RGB RGB
0x00 RGB RGB RGB RGB
0x00 RGB RGB RGB RGB
0x00 RGB RGB RGB RGB
这样的东西。当然，这是原始数据，这些数据实际储存的时候经过了一次压缩，压缩算法虽然是通过上门那个header那儿制定的，不过业界事实上只实现了一个标准算法，即zlib的deflate算法（至于zlib是怎么回事儿，这又是一段孽缘了），就当是一个普通的无损压缩算法好了。最后，IDAT中储存的，就是压缩后的像素颜色数据了。
另外，每一行的0x00其实是一个当前行算法滤镜的枚举，一共有5种滤镜，比如如果是0x01的话是减法滤镜，每一个像素储存的颜色是 display - last 得到的数。不同的计算方法可以使得每一行实际储存的颜色数据有一些不同，当然，长度还是不会变的。
完成Hello World
有了以上信息，最后还有一个IEND，而且没有数据内容的块作为表示png文件的结束，我们就可以着手编写一个最基本的png了，直接看代码：
#!/usr/bin/python
import sys,os
import struct
import binascii
import zlib
def write_block(f, title, data):
f.write(struct.pack('>L',len(data)))
f.write(title)
f.write(data)
f.write(struct.pack('>l',binascii.crc32(title + data)))
f = open("hello.png", "wb")
#png
f.write(struct.pack('>L',0x89504E47))
f.write(struct.pack('>L',0x0D0A1A0A))
#IHDR
ihdr = ""
ihdr += struct.pack('>L',0x00000002) #w
ihdr += struct.pack('>L',0x00000002) #h
ihdr += struct.pack('B',0x08) #depth
ihdr += struct.pack('B',0x02) #type
ihdr += struct.pack('B',0x00) #compression
ihdr += struct.pack('B',0x00) #filter
ihdr += struct.pack('B',0x00) #interlace
write_block(f, "IHDR", ihdr)
#IDAT
idat = ""
idat += struct.pack('B',0x00)
idat += struct.pack('B',0xff) + struct.pack('B',0x00) + struct.pack('B',0x00)
idat += struct.pack('B',0x00) + struct.pack('B',0xff) + struct.pack('B',0x00)
idat += struct.pack('B',0x00)
idat += struct.pack('B',0x00) + struct.pack('B',0xff) + struct.pack('B',0x00)
idat += struct.pack('B',0xff) + struct.pack('B',0x00) + struct.pack('B',0x00)
idat = zlib.compress(idat)
write_block(f, "IDAT", idat)
#IEND
write_block(f, "IEND", "")
f.close()这里绘制了一个2x2的彩色图像(type=2)图像，其中4个像素的颜色分别是0xff0000,0x00ff00,0x00ff00,0xff0000，运行一下，就看到我们想要的东西了。
加上透明通道
刚才的图像是type=2没有alpha通道的，因此这里换成6这张图片就变成带透明通道的了。带透明通道后IDAT段储存的颜色将多出alpha数据，比如：
0x00 RGBA RGBA RGBA RGBA
因此对应我们稍作改动就可以完成了
idat += struct.pack('B',0x00)
idat += struct.pack('B',0xff) + struct.pack('B',0x00) + struct.pack('B',0x00) + struct.pack('B',0xff)
idat += struct.pack('B',0x00) + struct.pack('B',0xff) + struct.pack('B',0x00) + struct.pack('B',0xff)
idat += struct.pack('B',0x00)
idat += struct.pack('B',0x00) + struct.pack('B',0xff) + struct.pack('B',0x00) + struct.pack('B',0x33)
idat += struct.pack('B',0xff) + struct.pack('B',0x00) + struct.pack('B',0x00) + struct.pack('B',0x33)PNG8
接下来就提到PNG8了，png8是各大png压缩主打的东西，即type=3的索引彩色图像。这种格式和gif类似，在图像数据前用了一个表格储存颜色，最多256个颜色。然后实际的像素数据就直接引用颜色索引就可以了。虽然颜色数大大的减少了，但是像素颜色数据一下子减少了66%，是非常爽的。
回到png，我们需要多一个块来储存颜色索引，是PLTE块，它的内容也非常非常简单，把所有的颜色罗列在一起就可以了，顺序数就是索引。因此，我们在helloworld上继续添加：
#PLTE
plte = ""
plte += struct.pack('B',0xff) + struct.pack('B',0x00) + struct.pack('B',0x00)
plte += struct.pack('B',0x00) + struct.pack('B',0xff) + struct.pack('B',0x00)
write_block(f, "PLTE", plte)然后实际数据段改为填写索引id就可以了：
idat += struct.pack('B',0x00)
idat += struct.pack('B',0x01)
idat += struct.pack('B',0x00)
idat += struct.pack('B',0x00)
idat += struct.pack('B',0x00)
idat += struct.pack('B',0x01)PNG8Alpha
png的索引彩色图像一开始设计的时候是没有考虑alpha的，然后需要来了，还是得加上。怎么办，不得已，我们再添加一个块，专门来描述每一个索引颜色的alpha值。因此继续改动helloworld，加上了描述索引颜色透明度的tRNS块：
#tRNS
srns = ""
srns += struct.pack('B',0xff)
srns += struct.pack('B',0xff)
srns += struct.pack('B',0x33)
srns += struct.pack('B',0x33)
write_block(f, "tRNS", srns)当然，不同的透明度是不同的颜色，现在我们需要4个颜色来实现。
小结
到此为止，我们得到了世界上99%的png的基本格式的结构，世界上99%的png我们拆开看都逃不出这个结构，依赖这些信息，我们也可以进行接下来的分析了。
PNG压缩
裁剪无用块
从简入繁，最简单的，我们看到,普通的png加上IEND必要块有4块，png8多个PLTE块，带alpha的再多一个tRNS块，其它的多半是无关紧要的。标准的png可能有如下块：
可以看到，其中大部分非必要块主要是描述了拍摄的原始信息（如图像γ数据(gamma)块，图像直方图数据块，物理像素尺寸数据块），或者是辅助信息（各种文本信息数据块）之类的，这些东西在图像用于调整处理(PS)或者归档的时候意义巨大，但是对于web或者app使用，完全没有意义。比如ps默认保存出来的png，最少20kb，除了这些甚至还夹带了图层信息，对于我们来说是完全没用的。
还有是IDAT本身，PNG的图像数据本身是可以放在多个IDAT中以实现渐进加载等效果，没必要的话把它们合并到同一张图像上能很大程度上增加IDAT压缩率减小IDAT段大小。
所以作为PNG压缩的第一步，无用块删删删。
颜色优化
首先，我们的目标是把png都转换为png8。毕竟我们的实际使用场景大部分都是图标啊小icon啊什么的，现在又都是扁平化设计，颜色数肯定不多，因此压256色绰绰有余，而且显然，颜色数越少PLTE长度越短，并且IDAT数据复杂度降低压缩率也会增加。
除了这个角度，非常简单的icon，甚至8位颜色深度也没必要了，4，2，1往下降都是没问题的，不过对于颜色数本来就少的图像，这个做法难度高而且减小大小并不多，因此比较得不偿失。
当然，到底怎么把图像的颜色数压下来，这就和png无关是图像领域的另一个大坑了。
IDAT结构优化
IDAT的原生数据会通过deflate算法无损压缩，这种常见的算法意味着，原始数据中重复元素越多，压缩率就越高。那原始数据怎么优化呢，这就是一开始提到的IDAT行算法滤镜提供的功能了。算法滤镜的设计目的就是“The purpose of these filters is to prepare the image data for optimum compression.”
一共有4种算法滤镜：
- 1:Sub滤镜 储存数据 ＝ 显示数据 － 左数据
- 2:Up滤镜 储存数据 ＝ 显示数据 － 上数据
- 3:Average滤镜 储存数据 ＝ 显示数据 - floor((左数据 + 上数据) / 2)
- 4:Paeth滤镜 储存数据 ＝ 显示数据 - PaethPredictor(左数据, 上数据, 左上数据) magic多项式
比如，减滤镜非常适合过滤渐变性较强的数据，越稳定的渐变可以转换为非常单一的数据以方便压缩（一个减法且持续是#010000的数据可以成为从#000000到#ff0000的渐变）。双向和四向平均滤镜则用在更复杂的场景。
这个也是一个大坑，并且从实际上看做这个优化非常困难。
使用工具
分析结束，可以看到PNG的压缩点都需要大量图形学算法支持，清晰了解这一情况，我们还是选择使用工具来解决问题吧。压缩PNG的工具，除了最流行的tinypng网站，就要数开源的pngquant了（https://pngquant.org/）。因此，我们首先把pngquant和需要对标的tinypng放在一起比较。
小图压缩
提供的是颜色数远低于256的图，使用tinypng压缩，和用pngquant在30和90两个质量数进行压缩，结果如下：
注意到pngquant的图多包涵gAMA和sRGB两段，删除后和tinypng大小一致。
1. 颜色数低于256的图，两者都没进行有损压缩，直接转换为了png8。
2. pngquant转换时保留了和颜色有关的多余块（比如gamma信息），因此比tinypng稍大，删除后完全一致。
大图压缩
提供了一张颜色丰富的图进行类似测试，结果如下：
1. 都尝试压缩为了png8
2. 其实有损压缩算法上不分伯仲，差距不大，和大小相比基本是一分钱一分货
3. tinypng明显用了较多的平滑处理，使得画面细节相对柔和很多，没有明显的锯齿感，感官确实优于pngquant
结论
在web和app开发的大部分场景下，对于颜色数小于256的图像，用pngquant和用tinypng处理完全没有区别，pngquant需要增加脚本处理掉多余块，但是肯定比使用在线且受限的tinypng方便。
在处理复杂图像上，本身将复杂图像处理为png8是否合适就有待商榷，如果确实要这么做，tinypng优于pngquant。
渝公网安备 