从Xcode编译时自带的“图片压缩”说起

 在Xcode的设置中，默认设置“Compress PNG Files”为True,从字面的理解，在最终编译打包时，Xcode将对项目中的PNG图片进行“压缩”。实质上，是否果真如此？这项自带的图片压缩，效果如何呢？本文将就此进行分析，并对图片压缩这个主题进行延伸。

文章很长，无非是想告诉大家两个事情：

1.所谓的Compress PNG Files并不是为了减少图片的大小，而是为了加快应用运行时的速度

2.使用ImageOptim这款工具对几个项目进行图片压缩，优化效果存在差异。三个验证项目中，压缩率分别是3.1%,3%,21% 。大家可以拿自己的项目试试。

一、“Compress PNG Files”对包大小的影响

首先选取了两个项目进行实测（项目名，图片文件原始大小，开启图片压缩后的项目大小，编译时间，未开启图片压缩，编译时间)

项目图片文件原始大小编译后的ipa大小（开启Compress PNG Files）编译后的ipa大小（关闭Compress PNG Files)A26.7MB51.1MB(51107659Byte)51.2MB(51150883Byte)B26MB27.5mb(27526648Byte)27.0MB(27030870Byte)C 16.4MB15.3MB(15257564Byte) 15.2MB(15165717Byte)

从验证结果来看，这个选项非但没有减少最终安装包的大小，甚至还略有增大。那么，“Compress PNG Files"究竟是什么呢？

二、Compress PNG Files究竟是什么？

“Compress PNG Files"实际上是将图片像素的颜色信息，转换成iPhone能够更快渲染的格式。

PNG图片采用的颜色空间，一般是RGBA。也就是说，一个像素点的颜色，是由四个分表代表红色，绿色，蓝色，透明度的字节来存储。而iPhone的图像内存，使用的是一种非标准的颜色空间（BGRA,对应的图片格式叫做CgBI))。从读取图片像素点RGBA的信息，到最终计算出，屏幕渲染所需的BGR，会有更大的耗时。如果图片一开始就是以BGR保存的，那渲染时要做的，就仅仅是个简单的内存拷贝操作。因此，在项目进行编译，也就是“Compress PNG Files"时，Xcode会对图片中的颜色信息进行计算转换。假设图片中某个像素是这样的一个颜色（R:0.0,  G:0.0, B:1.0,  A:0.5),那么在编译时，这个像素点会被转换成（B:0.5, G:0.0, R:0.0, A:0.5.大家可以看到，蓝色的部分，已经被乘以50%的透明度。通过这样的预处理，在程序运行时就不用再对颜色进行转换。但是，A（透明值）仍然会保存在图片信息中，这是因为我们的项目可能需要对同个位置的两张图片进行混合，在这种情况下，iPhone就需要通过透明值来计算，最终呈现给用户的，是怎样一个颜色。在iOS项目中，将你的UIImageView属性的opaque （不透明）设为YES，iPhone便会知道图片中的alpha通道是无需使用到的，直接将GRB的值渲染出来即可，省去重计算颜色值的过程。 

三、使用ImageOptim进行图片压缩

但是，图像最终展示出来，需要两个过程，一个是从“硬盘”加载到“内存”的过程，一个是上一段内容说的渲染过程。那如果先将图片进行有效压缩，缩减了第一个过程的时间，同样能达到加快应用运行的目的。这种思路是否可行呢？

1.网友的验证：更小的图片，带来更高的应用运行速度

对此，有网友进行了验证，使用了ImageOptim对他的应用进行压缩。(下面摘抄了文章的部分内容）     

Tweetbot是一款iOS应用，大小约为33.4MB，而其中图片资源为26MB，978个文件。

以下为图片经过压缩后，占用空间的对比

以下为应用在载入图片时的耗时对比

以UIImageView creation为例，经过Xcode优化，耗时8.6s，而经过ImageAlpha和ImageOptim优化的，却只有1.2S。经过Xcode优化的图片，载入速度，比ImageOptim压缩图片 更慢。这说明，对于这款应用来讲，png图片转换成iOS可显示图像的耗时，要小于文件大小差异带来的I/O损耗。

2.在我们的项目上使用ImageOptim的效果（包大小的压缩效果）

耳听为虚，眼见为实。拿A、B项目进行验证，结果如下

使用ImageOptim进行压缩

项目图片资源经过压缩后大小包大小（开启Compress PNG Files)包大小（关闭Compress PNG Files)A24.5MB(降低8%）49.6MB(49581795 Byte)49.6MB(49625076 Byte)（降低3.1%)B25.1MB(降低3.4%）26.9MB26.2MB(降低3%）C13.09(降低20%）12.1MB12MB(降低21%）

压缩的效果并不如网上所说的那么好。而且是否开启Compress PNG Files，也没有附文1说的差异（为什么我的验证结果跟附文1的结果有差异，还有待分析）。

把整个过程记录下来，希望后来者进行研究时，可以少走一些弯路

附文1：

那如果同时经过ImageOptim和Xcode的优化，岂不是两全其美？引用另外一个网友的验证，这个方案是行不通的，Xcode的优化，会将ImageOptim的压缩成果还原回去（（不止是该工具，可能其他压缩工具同样如此，这还有待验证）

一开始，使用ImageOptim对图片进行压缩，效果良好

但是，压缩后的图片，经过Xcode的优化，又再次打回原型。图片大小会反弹，变得跟未经过压缩的图片一样大。

附文2：

参考文章：

cgBi图片格式介绍

http://iphonedevwiki.net/index.php/CgBI_file_format

imageOptim介绍

http://imageoptim.com/

网友使用imageOptim进行优化

http://imageoptim.com/tweetbot.html

使用ImageOptim但未关闭xcode优化，会降低优化效果

http://bjango.com/articles/pngcompression/

写了这篇文章好久之后，发现了类似的一篇文章，也在介绍

Compress PNG选项

http://www.cnblogs.com/xitang/p/3905590.html