Xcode 对于 png 图片的处理 (Compress PNG Files)

将数据写入图片，能够达到很好的隐藏信息的目的。看到一些地方有相关的方式，我也尝试了下，然后遇到了问题。Xcode 编译运行后 Products 里面的可执行文件 读取不到我的信息。但是我将工程中的 png 图片手动覆盖生成的 App 中的图片后 又能读取到信息了。

很显然这俩文件不一样，但是怎么会不一样呢？ 

通过比对文件md5  验证了我的想法。 一开始怀疑 Xcode 缓存，通过重新编译排除了。 或者 文件引用路径出了问题  一直在搜索这个文件哪里来的。将工程发给其他机器，编译发现问题依然存在，所以也排除了引用路径的可能

 

后来同事提醒  Xcode 会对图片进行优化，恍然大悟。

1、那么 Xcode 会做些什么呢？

Xcode 的 Build Setting 设置里面有一个 Compress PNG Files 的选项, 如果选择了 YES, 那么 Xcode 在编译阶段将会对所有 png 图片进行压缩。

调用这个路径下的脚本 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/iphoneos-optimize 进行优化 

 它减少PNG IDAT数据流的大小，通过尝试不同的压缩级别和PNG筛选方法。它也可以用来去除不必要的辅助块。

标准的24bit PNG文件存储方式是按照顺序(红/绿/蓝/透明度)这样来存每一个像素即RGBA，而经过Xcode优化之后的PNG文件像素顺序变成了BGRA，这样的非标准的PNG文件在一般操作系统也就没办法读了。
苹果这么做是有原因的，在OpenGL的wiki有一篇文章 提到了绝大部分GPU的图像/纹理显存每个单元都是24bit的，RGBA和BGRA都有，但BGRA是主流的。
这样就说得通了：苹果为了减少图像运算时花在数据交换（从文件系统到显示出来）的时间，运用了类似DMA的原理，图形数据可以在总线里直接走而不用花掉CPU的时间去协助处理。

 

最终变成了一个 优化后的 CgBI 格式的 png。有关 CgBI 的介绍这里有： http://iphonedevwiki.net/index.php/CgBI_file_format 。 它跟 png 的区别是

extra critical chunk (CgBI)     额外的关键数据块 CgBI
byteswapped (RGBA -> BGRA) pixel data, presumably for high-speed direct blitting to the framebuffer   字节转换 加快数据交换
zlib header, footer, and CRC removed from the IDAT chunk  移除 一些辅助性数据块
premultiplied alpha (color' = color * alpha / 255)    Alpha 预乘

它是通过 Xcode 自带的一个工具 pngcrush 来做的. 在这个位置 

/Applications/Xcode.app/Contents/Developer/usr/bin

这个工具是开源的.  地址在这里：  https://github.com/Kjuly/pngcrush

 

2、Xcode 是根据什么来做这些处理的呢？

由于对于每一个png 图片，在编译阶段进行处理 不可能根据数据内容来处理 如果这样，图片数量多的话 会极大的影响编译速度。我大胆推测是根据图片后缀来处理的

进行验证。果然，将 .png 去掉就没有处理了！

在这里  还找到一种方式能够避免 png 优化，就是修改 Xcode 对于 png 图片的类型识别

 改成：

3、在 OSX10.8之前 系统也无法识别压缩后的PNG，会导致 png 无法显示

xcrun -sdk iphoneos pngcrush -revert-iphone-optimizations -q Local.png Local-standard.png

通过这样可以恢复 标准的 png

 

参考：

apple 官方提供的 恢复优化前 png 方式

Xcode 执行优化的原理

另外：

iOS 开发中 各种压缩相关的软件介绍