在iOS開(kāi)發(fā)中，圖片(UIImage)是我們?cè)陂_(kāi)發(fā)中，占用手機(jī)內(nèi)存比較大的對(duì)象，如果在運(yùn)行過(guò)程中，內(nèi)存占用過(guò)大，對(duì)電池壽命會(huì)造成影響，如果超過(guò)了內(nèi)存占用的最大值，會(huì)造成App的crash。這篇文章從圖片的加載原理和SDWebImage的源碼實(shí)現(xiàn)的角度來(lái)介紹圖片加載。

圖片的渲染流程

在iOS中使用 UIImage和UIImageView來(lái)記載圖片，他倆遵守經(jīng)典的MVC架構(gòu)，UIImage相當(dāng)于Model，UIImageView相當(dāng)于View:

UIImage負(fù)責(zé)加載圖片，UIImageView負(fù)責(zé)渲染圖片。

圖片的渲染流程分為3個(gè)階段:加載(Load)，解碼（Decoder)和渲染(Render)

如果你正在面試，或者正準(zhǔn)備跳槽，不妨看看我精心總結(jié)的面試資料：https://gitee.com/Mcci7/i-oser 來(lái)獲取一份詳細(xì)的大廠(chǎng)面試資料 為你的跳槽加薪多一份保障

在每個(gè)階段都會(huì)有相對(duì)應(yīng)的緩沖區(qū):數(shù)據(jù)緩沖區(qū)(DataBuffer)，圖像緩沖區(qū)(imageBuffer)和幀緩沖區(qū)(framebuffer)。

我們以加載一個(gè)圖片的尺寸為:2048 px * 1536 px，在磁盤(pán)上的大小為:590kb的圖片為例，來(lái)分析前兩個(gè)階段的緩沖區(qū)。

DataBuffer

DataBuffer只是一種包含一系列字節(jié)的緩沖區(qū)。通常以某些元數(shù)據(jù)開(kāi)頭,元數(shù)據(jù)描述了存儲(chǔ)在數(shù)據(jù)緩沖區(qū)中的圖像大小，包含圖形數(shù)據(jù)本身，圖像數(shù)據(jù)以某種形式編碼 如 JPEG壓縮或PNG，這意味著，該字節(jié)并不直接描述圖像中像素的任何內(nèi)容。此時(shí)的 DataBuffer大小為 590kb。

SD源碼分析

在SDWebImage中，圖片加載完成后，在 sd_imageFormatForImageData的方法中，是通過(guò)DataBuffer的第一個(gè)字節(jié)來(lái)判斷圖片的格式的。

    uint8_t c;
    [data getBytes:&c length:1];
    switch (c) {
        case 0xFF:
            return SDImageFormatJPEG;
        case 0x89:
            return SDImageFormatPNG;
        case 0x47:
            retur SDImageFormatGIF;
        case 0x49:
        case 0x4D:
            return SDImageFormatTIFF;

        ......
   }
復(fù)制代碼

ImageBuffer

在圖片加載完后，需要將Data Buffer的JPEG，PNG或其他編碼的數(shù)據(jù)，轉(zhuǎn)換為每個(gè)像素的圖像信息，這個(gè)過(guò)程，稱(chēng)為Decoder(解碼)，將像素信息存放在ImageBuffer。

占用內(nèi)存大小

圖片占用的內(nèi)存大小與圖像的尺寸有關(guān)，與它的文件大小無(wú)關(guān)，在iOSSRGB顯示格式中(4byte空間顯示一個(gè)像素)，如果解析所有的像素，需要 2048 px * 1536 px * 4 byte/px = 10MB的空間，此時(shí)的 ImageBuffer的大小為10MB。

在ImageBuffer解析完后，提交給frameBuffer進(jìn)行渲染顯示。

總的來(lái)說(shuō)，圖片加載過(guò)程和消耗的內(nèi)存如下圖所示：

Xcode測(cè)試

在Xcode工程中，當(dāng)push新頁(yè)面的時(shí)候，只加載一個(gè)圖片。

加載前內(nèi)存值:

加載后內(nèi)存值：

大多數(shù)情況下，我們并不需要如此高精度的顯示圖片，占用了這么多的內(nèi)存，能否減少加載圖片時(shí)占用的內(nèi)存值呢?

如何減少圖像占用內(nèi)存

向下采樣

在蘋(píng)果官方文檔中，建議我們使用向下采樣（Downsampleing)的技術(shù)，來(lái)加載圖片，減少ImageBuffer的大小。

方法如下：

func downsample(imageAt imageURL: URL, to pointSize:CGSize, scale:CGFloat) ->UIImage {
    let imageSourcesOptions = [kCGImageSourceShouldCache: false] as CFDictionary

    let imageSource = CGImageSourceCreateWithURL(imageURL as CFURL, imageSourcesOptions)!
    let maxDimensionInPixels = max(pointSize.width, pointSize.height) * scale
    let downsampleOptions = [
            kCGImageSourceCreateThumbnailFromImageAlways: true,
            kCGImageSourceShouldCacheImmediately: true,
            kCGImageSourceCreateThumbnailWithTransform: true,
            kCGImageSourceThumbnailMaxPixelSize:maxDimensionInPixels
        ] as CFDictionary
    let downsampledImage = CGImageSourceCreateThumbnailAtIndex(imageSource, 0, downsampleOptions)!

    return UIImage(cgImage: downsampledImage)
 }
復(fù)制代碼

我們來(lái)測(cè)試一下:

   let imageStr = Bundle.main.path(forResource: "view_site.jpeg", ofType: nil)
   let imageURL =  URL(string: "file://" + (imageStr ?? ""))
   guard let imgURL = imageURL else {
       return
   }
   imageView.image = downsample(imageAt:imgURL , to: CGSize(width: 200, height: 200), scale: UIScreen.main.scale)
復(fù)制代碼

加載之前時(shí)是13M，加載之后是 17M，效果是很明顯的，節(jié)省了大約 5M的內(nèi)存空間。

在對(duì)圖片進(jìn)行壓縮時(shí)，我們應(yīng)首選向下采樣技術(shù)。

SD源碼分析解碼過(guò)程

在SDWebIamge中，一共有3種類(lèi)型的解碼器：SDImageIOCoder, SDImageGIFCoder, SDImageAPNGCoder，根據(jù)DataBuffer的編碼類(lèi)型，使用相對(duì)應(yīng)的編碼器。

在 -(UIImage *)decodedImageWithData:(NSData *)data方法中，配置解碼參數(shù)，開(kāi)始進(jìn)行解碼操作。

在 + (UIImage *)createFrameAtIndex:(NSUInteger)index source:(CGImageSourceRef)source scale:(CGFloat)scale preserveAspectRatio:(BOOL)preserveAspectRatio thumbnailSize:(CGSize)thumbnailSize options:(NSDictionary )options 中，完成圖像解碼

選擇正確的圖片渲染格式

渲染格式

在 iOS中，渲染圖片格式有4種

• Alpha 8 Format:1字節(jié)顯示1像素，擅長(zhǎng)顯示單色調(diào)的圖片。
• Luminance and alpha 8 format: 亮度和 alpha 8 格式，2字節(jié)顯示1像素，擅長(zhǎng)顯示有透明度的單色調(diào)圖片。
• SRGB Format: 4個(gè)字節(jié)顯示1像素。
• Wide Format: 廣色域格式，8個(gè)字節(jié)顯示1像素。適用于高精度圖片，

如何正確的選擇渲染格式

正確的思路是：不選擇渲染格式，讓渲染格式選擇你。

使用 UIGraphicsImageRender來(lái)替換UIGraphicsBeginImageContextWithOptions，前者在iOS12以后，會(huì)自動(dòng)選擇渲染格式，后者默認(rèn)都會(huì)選擇SRGB Format。

func render() -> UIImage{
   let bounds = CGRect(x: 0, y: 0, width: 300, height: 100)
   let render = UIGraphicsImageRenderer(size: bounds.size)
   let image = render.image { context in
       UIColor.blue.setFill()
           let path = UIBezierPath(roundedRect: bounds, byRoundingCorners: UIRectCorner.allCorners, cornerRadii: CGSize(width: 20, height: 20))
       path.addClip()
       UIRectFill(bounds)
    }
    return image
}
復(fù)制代碼

此時(shí)，系統(tǒng)為自動(dòng)選擇Alpha 8 Format格式，內(nèi)容空間占用，將會(huì)減少75%。

減少后備存儲(chǔ)器的使用

減少或者不使用 draw(rect:) 方法

在需要繪制帶有子視圖的View時(shí)，不使用 draw(rect:)方法，使用系統(tǒng)的View屬性或者添加子視圖的方式，將繪制工作交給系統(tǒng)來(lái)處理。

背景色直接通過(guò)UIView.backgroundColor設(shè)置，而非使用draw(rect:)

如何在列表中加載圖片

我們?cè)陂_(kāi)發(fā)中，一般會(huì)對(duì)圖片進(jìn)行子線(xiàn)程異步加載，在后臺(tái)進(jìn)行 解碼和下采樣。在列表中，有時(shí)會(huì)加載很多圖片，此時(shí)應(yīng)該注意線(xiàn)程爆炸問(wèn)題。

線(xiàn)程爆炸

當(dāng)我們要求系統(tǒng)去做比CPU能夠做的工作更多的工作時(shí)就會(huì)發(fā)生這種情況，比如我們要顯示8張圖片，但我們只有兩個(gè)CPU，就不能一次完成所有這些工作，無(wú)法在不存在的CPU上進(jìn)行并行處理，為了避免向一個(gè)全局隊(duì)列中異步的分配任務(wù)時(shí)發(fā)生死鎖，GCD將創(chuàng)建新線(xiàn)程來(lái)捕捉我們要求它所做的工作，然后CPU將花費(fèi)大量時(shí)間，在這些線(xiàn)程之間進(jìn)行切換，嘗試在所有工作上取得我們要求操作系統(tǒng)為我們做的漸進(jìn)式進(jìn)展，在這些線(xiàn)程之間不停切換，實(shí)際上是相當(dāng)大的開(kāi)銷(xiāo)，現(xiàn)在不是簡(jiǎn)單地將工作分派到全局異步隊(duì)列之一，而是創(chuàng)建一個(gè)串行隊(duì)列，在預(yù)取的方法中，異步的將工作分派到該隊(duì)列，它的確意味著單個(gè)圖像的加載，可能要比以前晚才能開(kāi)始取得進(jìn)展，但CPU將花費(fèi)更少的時(shí)間，在它可以做的小任務(wù)之間來(lái)回切換。

在SDWebImage中，解碼的隊(duì)列 _coderQueue.maxConcurrentOperationCount = 1就是一個(gè)串行隊(duì)列。這樣就很好的解決了多圖片異步解碼時(shí)，線(xiàn)程爆炸問(wèn)題。

作者：Bel李玉
鏈接：https://juejin.cn/post/7019623908500324389