可以看出在開發的時候，如果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如何避免圖像解壓縮的時間開銷
對文章進行了整理和學習，僅供參考
