可以看出在开发的时候，如果scrollView中有很多图片，那么在拖动的过程中，会有明显的卡顿，这是因为每次显示一个UIImageView的时候都需要将图片文件解压缩并渲染到屏幕上这一系列工作上，然而UIimage仅仅在图片将要显示的时候进行这个解压缩操作，而这个操作又是在主线程中执行的，所以造成了卡顿；
图片的两种格式，jpeg和png，苹果推荐使用png作为用户界面图片的显示格式，png图片的格式会被一个叫做pngcrush开源的框架优化，可以更快的解压缩，但是可能会造成app过大，png图片对于应用中自带的图片来说非常好，但对于从internet上下载的图片就不一定了
对于从internet，png格式的图片有alpha通道，jpeg没有，png无损压缩，jpeg允许你选择压缩质量，也就是说如果你不需要一个完美的图片，那么就可以使用jpeg，jpeg会忽略你看不到的东西，一般60%以上的压缩质量都不会有明显的影响，对于要求高的图片则需要选择高压缩质量的了比如文字
对于一个图片的显示时间上有三个方面的考量1.从磁盘上alloc init的时间2.解压缩的时间.3解压缩后的byte转换成CGContext的时间
空间上1.磁盘空间通过internet传输小号的空间。2.解压缩消耗的空间3.显示一个view，view本身需要空间存储layer
在非主线程上进行了解压缩操作，但是渲染绘制图片仍然会占用很长的时间，这时候可以用CATiledLayer来显示完成，将图片分为小块使用
在显示图片中，解压缩是消耗时间最多的，渲染的时间与压缩品质无关，只与图片的分辨率有关
100%品质的jpeg和png时间开销相同，但是png无法动态创建
jpeg压缩品质10-90%之间，空间开销成线性增长，90-100%增长很快
要保持scrollView不卡，解决办法是
当第一次使用图片，iOS会解压他，然后自己讲图片渲染成一个新的图片来解压这个图片，这样你将会获得两个解压版本
- (void)decompressImage:(UIImage *)image
{
UIGraphicsBeginImageContext(CGSizeMake(1, 1));
[image drawAtPoint:CGPointZero];
UIGraphicsEndImageContext();
}
上面的代码会解压这个图片如果我们的UIimage只是通过initWithContentOfFile创建的话，我不能保存这个解压缩版本，所以必须使用imageIO中提供的一个选项来显示这个解压缩版本
NSDictionary *dict = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES]
forKey:(id)kCGImageSourceShouldCache];
CGImageSourceRef source = CGImageSourceCreateWithURL((CFURLRef)url, NULL);
CGImageRef cgImage = CGImageSourceCreateImageAtIndex(source, 0, (CFDictionaryRef)dict);
UIImage *retImage = [UIImage imageWithCGImage:cgImage];
CGImageRelease(cgImage);
CFRelease(source);
结论
如果你需要alpha通道或者必须使用PNG格式，那么我推荐你在你的web服务器上安装pngcrush并处理好所有的png图片。其他情况下，高质量的jpeg能带来较小的文件大小以及更快的解压缩和渲染。
事实证明，png格式对于那些使用在UI元素中的小图片来说非常好，但是对于那些全屏显示图片的应用来说则完全不是。替代png的通常是60-80%压缩质量的jpeg，至于压缩质量取多少合适，这取决于你的图片内容。
你可能希望所有显示过的图片都能保持他们的解压缩版本，但是这也将带来大量的内存开销并导致你的App进程被杀掉。此时使用NSCache就是一个很好的解决方案。它可以自动在内存短缺的时候照看好这些图片。
虽然不幸的是我们不能知道一个图片是否需要解压缩，同样一个图片的解压缩版本消失时我们也不会获得任何通知（这或许非常适合提交到Apple的bug反馈网站上）。但幸运的是，通过上述方法访问的解压缩后的图片不会再在解压缩上消耗时间。所以你可以同时在恰当的时间和恰当的条件下使用这种方法而不造成额外的开销。
原文地址：http://longtimenoc.com/archives/ios如何避免图像解压缩的时间开销
对文章进行了整理和学习，仅供参考
