iOS 下的圖片處理與性能優化

來自專欄 杏仁技術站

作者 | 錢凱

杏仁移動開發工程師，前嵌入式工程師，關注大前端技術新潮流。

移動開發中我們經常和多媒體數據打交道，對這些數據的解析往往需要耗費大量資源，屬於常見的性能瓶頸。

本文針對多媒體數據的一種———圖片，介紹下圖片的常見格式，它們如何在移動平台上被傳輸、存儲和展示，以及優化圖片顯示性能的一種方法：強制子線程解碼。

圖片在計算機世界中怎樣被存儲和表示？

圖片和其他所有資源一樣，在內存中本質上都是0和1的二進位數據，計算機需要將這些原始內容渲染成人眼能觀察的圖片，反過來，也需要將圖片以合適的形式保存在存儲器或者在網路上傳送。

下面是一張圖片在硬碟中的原始十六進位表示：

這種將圖片以某種規則進行二進位編碼的方式，就是圖片的格式。

常見的圖片格式

圖片的格式有很多種，除了我們熟知的 JPG、PNG、GIF，還有Webp，BMP，TIFF，CDR 等等幾十種，用於不同的場景或平台。

這些格式可以分為兩大類：有損壓縮和無損壓縮。

有損壓縮：相較於顏色，人眼對光線亮度信息更為敏感，基於此，通過合併圖片中的顏色信息，保留亮度信息，可以在盡量不影響圖片觀感的前提下減少存儲體積。顧名思義，這樣壓縮後的圖片將會永久損失一些細節。最典型的有損壓縮格式是 jpg。

無損壓縮：和有損壓縮不同，無損壓縮不會損失圖片細節。它降低圖片體積的方式是通過索引，對圖片中不同的顏色特徵建立索引表，減少了重複的顏色數據，從而達到壓縮的效果。常見的無損壓縮格式是 png，gif。

除了上述提到的格式，有必要再簡單介紹下 webp 和 bitmap這兩種格式:

Webp：jpg 作為主流的網路圖片標準可以向上追溯到九十年代初期，已經十分古老了。所以谷歌公司推出了Webp標準意圖替代陳舊的jpg，以加快網路圖片的載入速度，提高圖片壓縮質量。

webp 同時支持有損和無損兩種壓縮方式，壓縮率也很高，無損壓縮後的 webp 比 png 少了45%的體積，相同質量的 webp 和 jpg，前者也能節省一半的流量。同時 webp 還支持動圖，可謂圖片壓縮格式的集大成者。

webp 的缺點是瀏覽器和移動端支持還不是很完善，我們需要引入谷歌的 libwebp 框架，編解碼也會消耗相對更多的資源。

bitmap：bitmap 又叫點陣圖文件，它是一種*非壓縮*的圖片格式，所以體積非常大。所謂的非壓縮，就是圖片每個像素的原始信息在存儲器中依次排列，一張典型的1920*1080像素的 bitmap 圖片，每個像素由 RGBA 四個位元組表示顏色，那麼它的體積就是 1920 * 1080 * 4 = 1012.5kb。

由於 bitmap 簡單順序存儲圖片的像素信息，它可以不經過解碼就直接被渲染到 UI 上。實際上，其它格式的圖片一般都需要先被首先解碼為 bitmap，然後才能渲染到界面上。

如何判斷圖片的格式？

在一些場景中，我們需要手動去判斷圖片數據的格式，以進行不同的處理。一般來說，只要拿到原始的二進位數據，根據不同壓縮格式的編碼特徵，就可以進行簡單的分類了。以下是一些圖片框架的常用實現，可以複製使用：

+ (XRImageFormat)imageFormatForImageData:(nullable NSData *)data { if (!data) { return XRImageFormatUndefined; } uint8_t c; [data getBytes:&c length:1]; switch (c) { case 0xFF: return XRImageFormatJPEG; case 0x89: return XRImageFormatPNG; case 0x47: return XRImageFormatGIF; case 0x49: case 0x4D: return XRImageFormatTIFF; case 0x52: if (data.length < 12) { return XRImageFormatUndefined; } NSString *testString = [[NSString alloc] initWithData:[data subdataWithRange:NSMakeRange(0, 12)] encoding:NSASCIIStringEncoding]; if ([testString hasPrefix:@"RIFF"] && [testString hasSuffix:@"WEBP"]) { return XRImageFormatWebP; } } return XRImageFormatUndefined;}

UIImageView 的性能瓶頸

如上文所說，大部分格式的圖片，都需要被首先解碼為bitmap，然後才能渲染到UI上。

UIImageView 顯示圖片，也有類似的過程。實際上，一張圖片從在文件系統中，到被顯示到 UIImageView，會經歷以下幾個步驟：

1. 分配內存緩衝區和其它資源。
2. 從磁碟拷貝數據到內核緩衝區
3. 從內核緩衝區複製數據到用戶空間
4. 生成UIImageView，把圖像數據賦值給UIImageView
5. 將壓縮的圖片數據，解碼為點陣圖數據（bitmap），如果數據沒有位元組對齊，Core Animation會再拷貝一份數據，進行位元組對齊。
6. CATransaction捕獲到UIImageView layer樹的變化，主線程Runloop提交CATransaction，開始進行圖像渲染
7. GPU處理點陣圖數據，進行渲染。

由於 UIKit 的封裝性，這些細節不會直接對開發者展示。實際上，當我們調用[UIImage imageNamed:@"xxx"]後，UIImage 中存儲的是未解碼的圖片，而調用 [UIImageView setImage:image]後，會在主線程進行圖片的解碼工作並且將圖片顯示到 UI 上，這時候，UIImage 中存儲的是解碼後的 bitmap 數據。

而圖片的解壓縮是一個非常消耗 CPU 資源的工作，如果我們有大量的圖片需要展示到列表中，將會大大拖慢系統的響應速度，降低運行幀率。這就是 UIImageView 的一個性能瓶頸。

解決性能瓶頸：強制解碼

如果 UIImage 中存儲的是已經解碼後的數據，速度就會快很多，所以優化的思路就是：在子線程中對圖片原始數據進行強制解碼，再將解碼後的圖片拋回主線程繼續使用，從而提高主線程的響應速度。

我們需要使用的工具是 Core Graphics 框架的 CGBitmapContextCreate 方法和相關的繪製函數。總體的步驟是：

A. 創建一個指定大小和格式的 bitmap context。

B. 將未解碼圖片寫入到這個 context 中，這個過程包含了*強制解碼*。

C. 從這個 context 中創建新的 UIImage 對象，返回。

下面是 SDWebImage 實現的核心代碼，編號對應的解析在下文中：

// 1.CGImageRef imageRef = image.CGImage;// 2.CGColorSpaceRef colorspaceRef = [UIImage colorSpaceForImageRef:imageRef]; size_t width = CGImageGetWidth(imageRef);size_t height = CGImageGetHeight(imageRef);// 3.size_t bytesPerRow = 4 * width;// 4.CGContextRef context = CGBitmapContextCreate(NULL, width, height, kBitsPerComponent, bytesPerRow, colorspaceRef, kCGBitmapByteOrderDefault|kCGImageAlphaNoneSkipLast);if (context == NULL) { return image;} // 5.CGContextDrawImage(context, CGRectMake(0, 0, width, height), imageRef);// 6.CGImageRef newImageRef = CGBitmapContextCreateImage(context);// 7.UIImage *newImage = [UIImage imageWithCGImage:newImageRef scale:image.scale orientation:image.imageOrientation];CGContextRelease(context);CGImageRelease(newImageRef);return newImage;

對上述代碼的解析：

1、從 UIImage 對象中獲取 CGImageRef 的引用。這兩個結構是蘋果在不同層級上對圖片的表示方式，UIImage 屬於 UIKit，是 UI 層級圖片的抽象，用於圖片的展示；CGImageRef 是 QuartzCore 中的一個結構體指針，用C語言編寫，用來創建像素點陣圖，可以通過操作存儲的像素位來編輯圖片。這兩種結構可以方便的互轉：

// CGImageRef 轉換成 UIImageCGImageRef imageRef = CGBitmapContextCreateImage(context);UIImage *image = [UIImage imageWithCGImage:imageRef]; // UIImage 轉換成 CGImageRefUIImage *image=[UIImage imageNamed:@"xxx"];CGImageRef imageRef=loadImage.CGImage;

2、調用 UIImage 的 +colorSpaceForImageRef: 方法來獲取原始圖片的顏色空間參數。

什麼叫顏色空間呢，就是對相同顏色數值的解釋方式，比如說一個像素的數據是(FF0000FF)，在 RGBA 顏色空間中，會被解釋為紅色，而在 BGRA 顏色空間中，則會被解釋為藍色。所以我們需要提取出這個參數，保證解碼前後的圖片顏色空間一致。

CoreGraphic中支持的顏色空間類型：

3、計算圖片解碼後每行需要的比特數，由兩個參數相乘得到：每行的像素數 width，和存儲一個像素需要的比特數4。

這裡的4，其實是由每張圖片的像素格式和像素組合來決定的，下表是蘋果平台支持的像素組合方式。

表中的bpp，表示每個像素需要多少位；bpc表示顏色的每個分量，需要多少位。具體的解釋方式，可以看下面這張圖：

我們解碼後的圖片，默認採用 kCGImageAlphaNoneSkipLast RGB 的像素組合，沒有 alpha 通道，每個像素32位4個位元組，前三個位元組代表紅綠藍三個通道，最後一個位元組廢棄不被解釋。

4、最關鍵的函數：調用 CGBitmapContextCreate() 方法，生成一個空白的圖片繪製上下文，我們傳入了上述的一些參數，指定了圖片的大小、顏色空間、像素排列等等屬性。

5、調用 CGContextDrawImage() 方法，將未解碼的 imageRef 指針內容，寫入到我們創建的上下文中，這個步驟，完成了隱式的解碼工作。

6、從 context 上下文中創建一個新的 imageRef，這是解碼後的圖片了。

7、從 imageRef 生成供UI層使用的 UIImage 對象，同時指定圖片的 scale 和orientation 兩個參數。

scale 指的是圖片被渲染時需要被壓縮的倍數，為什麼會存在這個參數呢，因為蘋果為了節省安裝包體積，允許開發者為同一張圖片上傳不同解析度的版本，也就是我們熟悉的@2x，@3x後綴圖片。不同屏幕素質的設備，會獲取到對應的資源。為了繪製圖片時統一，這些圖片會被set自己的scale屬性，比如@2x圖片，scale 值就是2，雖然和1x圖片的繪製寬高一樣，但是實際的長是width * scale。

orientation 很好理解，就是圖片的旋轉屬性，告訴設備，以哪個方向作為圖片的默認方向來渲染。

通過以上的步驟，我們成功在子線程中對圖片進行了強制轉碼，回調給主線程使用，從而大大提高了圖片的渲染效率。這也是現在主流 App 和大量三方庫的最佳實踐。

總結

總結一下本文內容：

• 圖片在計算機世界中被按照不同的封裝格式進行壓縮，以便存儲和傳輸。
• 手機會在主線程中將壓縮的圖片解壓為可以進行渲染的點陣圖格式，這個過程會消耗大量資源，影響App性能。
• 我們使用 Core Graphics 的繪製方法，強制在子線程中先對 UIImage 進行轉碼工作，減少主線程的負擔，從而提升App的響應速度。

和 UIImageView 類似，UIKit 隱藏了很多技術細節，降低開發者的學習門檻，但另一方面，卻也限制了我們對一些底層技術的探究。文中提到的強制解碼方法，其實也是CGBitmapContextCreate 方法的一個『副作用』，屬於比較hack方式，這也是iOS平台的一個局限：蘋果過於封閉了。

用戶對軟體性能（幀率、響應速度、閃退率等等）其實非常敏感，作為開發者，必須不斷探究性能瓶頸背後的原理，並且嘗試解決，移動端開發的性能優化永無止境。

全文完

歡迎搜索關注微信公眾號：杏仁技術站（微信號 xingren-tech）。

我們正在招聘Java工程師，歡迎有興趣的同學投遞簡歷到 rd-hr@xingren.com