从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)
A 26.7MB 51.1MB(51107659Byte) 51.2MB(51150883Byte)
B 26MB 27.5mb(27526648Byte) 27.0MB(27030870Byte)
16.4MB 15.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)
A 24.5MB(降低8%) 49.6MB(49581795 Byte) 49.6MB(49625076 Byte)(降低3.1%)
B 25.1MB(降低3.4%) 26.9MB 26.2MB(降低3%)
C 13.09(降低20%) 12.1MB 12MB(降低21%)
压缩的效果并不如网上所说的那么好。而且是否开启Compress PNG Files,也没有附文1说的差异(为什么我的验证结果跟附文1的结果有差异,还有待分析)。

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



附文1:
那如果同时经过ImageOptim和Xcode的优化,岂不是两全其美?引用另外一个网友的验证,这个方案是行不通的,Xcode的优化,会将ImageOptim的压缩成果还原回去((不止是该工具,可能其他压缩工具同样如此,这还有待验证)
一开始,使用ImageOptim对图片进行压缩,效果良好
但是,压缩后的图片,经过Xcode的优化,又再次打回原型。图片大小会反弹,变得跟未经过压缩的图片一样大。




附文2:
参考文章:
imageOptim介绍
网友使用imageOptim进行优化
使用ImageOptim但未关闭xcode优化,会降低优化效果
写了这篇文章好久之后,发现了类似的一篇文章,也在介绍
Compress PNG选项
http://www.cnblogs.com/xitang/p/3905590.html

发布了49 篇原创文章 · 获赞 12 · 访问量 30万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览