知道了那么多關于iOS上界面渲染的理論知識后，終于可以回歸最開始的問題，將一張 png/jpg 格式的圖片渲染到頁面上顯示有哪些流程？先來區分幾個東西。
1.PNG，JPG的區別。
JPG
JPEG是一種針對相片影像而廣泛使用的一種失真壓縮標準方法。JPEG的壓縮方式通常是破壞性資料壓縮（lossy compression），意即在壓縮過程中圖像的品質會遭受到可見的破壞。JPEG不支持動畫，不支持半透明。
PNG
便攜式網絡圖片（Portable Network Graphics），簡稱PNG，是一種無損數據壓縮位圖圖形文件格式。PNG格式是無損數據壓縮的，允許使用類似于GIF格式的調色板技術，支持真彩色圖像，并具備Alpha（半透明）等特性。
最基本的區別就是jpg圖片不支持透明，并且是有損壓縮。而png圖片支持透明度，無損壓縮
2.iOS加載本地圖片的方式
imageNamed：
+ (nullable UIImage *)imageNamed:(NSString *)name; // load from main bundle
這個方法用一個指定的名字在系統緩存中查找并返回一個圖片對象如果它存在的話。如果緩存中沒有找到相應的圖片，這個方法從指定的文檔中加載然后緩存并返回這個對象。
特點：
1.imageNamed加載圖片會進行緩存
2.這個方法會在加載圖片之后立刻進行解壓
imageWithContentsOfFile:
+ (nullable UIImage *)imageWithContentsOfFile:(NSString *)path;
僅加載圖片，圖像數據不會緩存。因此對于較大的圖片以及使用情況較少時，那就可以用該方法，降低內存消耗。
3.圖片加載的工作流
進入正題，當我們從磁盤中加載一張圖片，并將它顯示到頻幕上，中間的主要流程如下：
1.假設我們使用 +imageWithContentsOfFile: 方法從磁盤中加載一張圖片，這個時候的圖片并沒有解壓縮；
2.然后將生成的 UIImage 賦值給 UIImageView ；
3.接著一個隱式的 CATransaction 捕獲到了 UIImageView 圖層樹的變化；
4.在主線程的下一個 run loop 到來時，Core Animation 提交了這個隱式的 transaction ，這個過程可能會對圖片進行 copy 操作，而受圖片是否字節對齊等因素的影響，這個 copy 操作可能會涉及以下部分或全部步驟：
·分配內存緩沖區用于管理文件 IO 和解壓縮操作；
·將文件數據從磁盤讀到內存中；
·將壓縮的圖片數據解碼成未壓縮的位圖形式，這是一個非常·耗時的 CPU 操作；
·最后 Core Animation 使用未壓縮的位圖數據渲染 UIImageView 的圖層。
在上面的步驟中，圖片的解壓縮是一個非常耗時的 CPU 操作，并且它默認是在主線程中執行的。那么當需要加載的圖片比較多時，就會對我們應用的響應性造成嚴重的影響，尤其是在快速滑動的列表上，這個問題會表現得更加突出。
為什么需要解壓縮
什么是位圖
位圖就是一個像素數組，數組中的每個像素就代表著圖片中的一個點。我們在應用中經常用到的 JPEG 和 PNG 圖片就是位圖。
事實上，不管是 JPEG 還是 PNG 圖片，都是一種壓縮的位圖圖形格式。只不過 PNG 圖片是無損壓縮，并且支持 alpha 通道，而 JPEG 圖片則是有損壓縮，可以指定 0-100% 的壓縮比。
因此，在將磁盤中的圖片渲染到屏幕之前，必須先要得到圖片的原始像素數據，才能執行后續的繪制操作，這就是為什么需要對圖片解壓縮的原因。
明白了，我們總不能直接把壓縮包拿來用吧。。。
補充：壓縮前與壓縮后的大小關系
一張 PNG 圖片，像素為 30?×?30 ，文件大小為 843B，使用以下代碼：
UIImage *image = [UIImage imageNamed:@"check_green"];
CFDataRef rawData = CGDataProviderCopyData(CGImageGetDataProvider(image.CGImage));
就可以獲取到這個圖片的原始像素數據，大小為 3600B
也就是說，這張文件大小為 843B 的 PNG 圖片解壓縮后的大小是 3600B ，是原始文件大小的 4.27 倍。那么這個 3600B 是怎么得來的呢？與圖片的文件大小或者像素有什么必然的聯系嗎？事實上，解壓縮后的圖片大小與原始文件大小之間沒有任何關系，而只與圖片的像素有關：
解壓縮后的圖片大小 = 圖片的像素寬 30 * 圖片的像素高 30 * 每個像素所占的字節數 4
為了加深理解，我把這個圖片拖進 Sublime Text 2 中，得到了這個圖片的二進制數據，大小與原始文件大小一致，為 843B
強制解壓縮的原理
我們前面已經提到了，當未解壓縮的圖片將要渲染到屏幕時，系統會在主線程對圖片進行解壓縮，而如果圖片已經解壓縮了，系統就不會再對圖片進行解壓縮。因此，也就有了業內的解決方案，在子線程提前對圖片進行強制解壓縮。
而強制解壓縮的原理就是對圖片進行重新繪制，得到一張新的解壓縮后的位圖。其中，用到的最核心的函數是 CGBitmapContextCreate：
這個函數用于創建一個位圖上下文，用來繪制一張寬 width 像素，高 height 像素的位圖。
好吧，這個函數除了前三個，后面的我基本都不知道。下面挨個兒來說說參數代表什么。
像素格式
我們前面已經提到了，位圖其實就是一個像素數組，而像素格式則是用來描述每個像素的組成格式，它包括以下信息：
Bits per component ：一個像素中每個獨立的顏色分量使用的 bit 數；
Bits per pixel ：一個像素使用的總 bit 數；
Bytes per row ：位圖中的每一行使用的字節數。
顏色空間
在 Quartz 中，一個顏色是由一組值來表示的，比如 0, 0, 1 。而顏色空間則是用來說明如何解析這些值的，離開了顏色空間，它們將變得毫無意義。比如，下面的值都表示藍色：
位圖布局信息 CGBitmapInfo：
它主要提供了三個方面的布局信息：
alpha 的信息；
顏色分量是否為浮點數；
像素格式的字節順序。
其中，alpha 的信息由枚舉值 CGImageAlphaInfo 來表示：
它同樣也提供了三個方面的 alpha 信息：
·是否包含 alpha ；
·如果包含 alpha ，那么 alpha 信息所處的位置，在像素的最低有效位，比如 RGBA ，還是最高有效位，比如 ARGB ；
·如果包含 alpha ，那么每個顏色分量是否已經乘以 alpha 的值，這種做法可以加速圖片的渲染時間，因為它避免了渲染時的額外乘法運算。比如，對于 RGB 顏色空間，用已經乘以 alpha 的數據來渲染圖片，每個像素都可以避免 3 次乘法運算，紅色乘以 alpha ，綠色乘以 alpha 和藍色乘以 alpha 。
根據 Which CGImageAlphaInfo should we use 和官方文檔中對 UIGraphicsBeginImageContextWithOptions
函數的討論：
You use this function to configure the drawing environment for rendering into a bitmap. The format for the bitmap is a ARGB 32-bit integer pixel format using host-byte order. If the opaque parameter is YES, the alpha channel is ignored and the bitmap is treated as fully opaque (kCGImageAlphaNoneSkipFirst | kCGBitmapByteOrder32Host). Otherwise, each pixel uses a premultipled ARGB format (kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host).
我們可以知道，當圖片不包含 alpha 的時候使用 kCGImageAlphaNoneSkipFirst ，否則使用 kCGImageAlphaPremultipliedFirst 。另外，這里也提到了字節順序應該使用 32 位的主機字節順序 kCGBitmapByteOrder32Host
至于顏色分量是否為浮點數，直接邏輯或 kCGBitmapFloatComponents 就可以了。
然后是字節順序，它是由枚舉值 CGImageByteOrderInfo 來表示的：
它主要提供了兩個方面的字節順序信息：
小端模式還是大端模式；
數據以 16 位還是 32 位為單位。
對于 iPhone 來說，采用的是小端模式，但是為了保證應用的向后兼容性，我們可以使用系統提供的宏，來避免 Hardcoding ：
根據前面的討論，我們知道字節順序的值應該使用的是 32 位的主機字節順序 kCGBitmapByteOrder32Host ，這樣的話不管當前設備采用的是小端模式還是大端模式，字節順序始終與其保持一致。
好了，了解完這些相關知識后，我們再回過頭來看看 CGBitmapContextCreate
函數中每個參數所代表的具體含義：
data：如果不為 NULL，那么它應該指向一塊大小至少為 bytesPerRow * height字節的內存；如果 為 NULL ，那么系統就會為我們自動分配和釋放所需的內存，所以一般指定 NULL、即可；
width和 height：位圖的寬度和高度，分別賦值為圖片的像素寬度和像素高度即可；
bitsPerComponent：像素的每個顏色分量使用的 bit 數，在 RGB 顏色空間下指定 8 即可；
bytesPerRow：位圖的每一行使用的字節數，大小至少為 width * bytes per pixel 字節。有意思的是，當我們指定 0 時，系統不僅會為我們自動計算，而且還會進行 cache line alignment 的優化
space：就是我們前面提到的顏色空間，一般使用 RGB 即可；
bitmapInfo：就是我們前面提到的位圖的布局信息。
具體的例子
參照YY大神的YYKit中的使用代碼：
CGImageRef YYCGImageCreateDecodedCopy(CGImageRef imageRef, BOOL decodeForDisplay) {
...
if (decodeForDisplay) { // decode with redraw (may lose some precision)
CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(imageRef) & kCGBitmapAlphaInfoMask;
BOOL hasAlpha = NO;
if (alphaInfo == kCGImageAlphaPremultipliedLast ||
alphaInfo == kCGImageAlphaPremultipliedFirst ||
alphaInfo == kCGImageAlphaLast ||
alphaInfo == kCGImageAlphaFirst) {
hasAlpha = YES;
}
// BGRA8888 (premultiplied) or BGRX8888
// same as UIGraphicsBeginImageContext() and -[UIView drawRect:]
CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;
CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, YYCGColorSpaceGetDeviceRGB(), bitmapInfo);
if (!context) return NULL;
CGContextDrawImage(context, CGRectMake(0, 0, width, height), imageRef); // decode
CGImageRef newImage = CGBitmapContextCreateImage(context);
CFRelease(context);
return newImage;
} else {
...
}
}
它接受一個原始的位圖參數 imageRef ，最終返回一個新的解壓縮后的位圖 newImage ，中間主要經過了以下三個步驟：
使用 CGBitmapContextCreate 函數創建一個位圖上下文；
使用 CGContextDrawImage 函數將原始位圖繪制到上下文中；
使用 CGBitmapContextCreateImage 函數創建一張新的解壓縮后的位圖。
小結：圖片加載到界面，其實就是從磁盤加載到內存解壓后再進行渲染。這里我們知道了解壓這個過程在主線程并且非常消耗CPU，往往卡頓都是因為它。為了解決這個問題，我們需要在子線程強行解壓圖片。強行解壓的方法其實就是對圖片進行重新繪制。
相關文章：
談談 iOS 中圖片的解壓縮
加載和潛伏
