拓展-iOS 中圖片的解壓縮到渲染過(guò)程

一.圖像從文件到屏幕過(guò)程

image

通常計(jì)算機(jī)在顯示是CPU與GPU協(xié)同合作完成一次渲染.接下來(lái)我們了解一下CPU/GPU等在這樣一次渲染過(guò)程中,具體的分工是什么?

  • CPU: 計(jì)算視圖frame,圖片解碼,需要繪制紋理圖片通過(guò)數(shù)據(jù)總線交給GPU
  • GPU: 紋理混合,頂點(diǎn)變換與計(jì)算,像素點(diǎn)的填充計(jì)算,渲染到幀緩沖區(qū)。
  • 時(shí)鐘信號(hào):垂直同步信號(hào)V-Sync / 水平同步信號(hào)H-Sync
  • iOS設(shè)備雙緩沖機(jī)制:顯示系統(tǒng)通常會(huì)引入兩個(gè)幀緩沖區(qū),雙緩沖機(jī)制

圖片顯示到屏幕上是CPU與GPU的協(xié)作完成

對(duì)應(yīng)應(yīng)用來(lái)說(shuō),圖片是最占用手機(jī)內(nèi)存的資源,將一張圖片從磁盤(pán)中加載出來(lái),并最終顯示到屏幕上,中間其實(shí)經(jīng)過(guò)了一系列復(fù)雜的處理過(guò)程。

二.圖片加載的工作流程

  1. 假設(shè)我們使用 +imageWithContentsOfFile: 方法從磁盤(pán)中加載一張圖片,這個(gè)時(shí)候的圖片并沒(méi)有解壓縮;

  2. 然后將生成的 UIImage 賦值給 UIImageView

  3. 接著一個(gè)隱式的 CATransaction 捕獲到了 UIImageView 圖層樹(shù)的變化;

  4. 在主線程的下一個(gè) runloop 到來(lái)時(shí),Core Animation 提交了這個(gè)隱式的 transaction ,這個(gè)過(guò)程可能會(huì)對(duì)圖片進(jìn)行 copy 操作,而受圖片是否字節(jié)對(duì)齊等因素的影響,這個(gè) copy 操作可能會(huì)涉及以下部分或全部步驟:

    • 分配內(nèi)存緩沖區(qū)用于管理文件 IO 和解壓縮操作;
    • 將文件數(shù)據(jù)從磁盤(pán)讀到內(nèi)存中;
    • 將壓縮的圖片數(shù)據(jù)解碼成未壓縮的位圖形式,這是一個(gè)非常耗時(shí)的 CPU 操作;
    • 最后 Core AnimationCALayer使用未壓縮的位圖數(shù)據(jù)渲染 UIImageView 的圖層。
    • CPU計(jì)算好圖片的Frame,對(duì)圖片解壓之后.就會(huì)交給GPU來(lái)做圖片渲染
  5. 渲染流程

    • GPU獲取獲取圖片的坐標(biāo)
    • 將坐標(biāo)交給頂點(diǎn)著色器(頂點(diǎn)計(jì)算)
    • 將圖片光柵化(獲取圖片對(duì)應(yīng)屏幕上的像素點(diǎn))
    • 片元著色器計(jì)算(計(jì)算每個(gè)像素點(diǎn)的最終顯示的顏色值)
    • 從幀緩存區(qū)中渲染到屏幕上

我們提到了圖片的解壓縮是一個(gè)非常耗時(shí)的 CPU 操作,并且它默認(rèn)是在主線程中執(zhí)行的。那么當(dāng)需要加載的圖片比較多時(shí),就會(huì)對(duì)我們應(yīng)用的響應(yīng)性造成嚴(yán)重的影響,尤其是在快速滑動(dòng)的列表上,這個(gè)問(wèn)題會(huì)表現(xiàn)得更加突出。

三.為什么要解壓縮圖片

既然圖片的解壓縮需要消耗大量的 CPU 時(shí)間,那么我們?yōu)槭裁催€要對(duì)圖片進(jìn)行解壓縮呢?是否可以不經(jīng)過(guò)解壓縮,而直接將圖片顯示到屏幕上呢?答案是否定的。要想弄明白這個(gè)問(wèn)題,我們首先需要知道什么是位圖

其實(shí),位圖就是一個(gè)像素?cái)?shù)組,數(shù)組中的每個(gè)像素就代表著圖片中的一個(gè)點(diǎn)。我們?cè)趹?yīng)用中經(jīng)常用到的 JPEG 和 PNG 圖片就是位圖

大家可以嘗試

UIImage *image = [UIImage imageNamed:@"text.png"];
CFDataRef rawData = CGDataProviderCopyData(CGImageGetDataProvider(image.CGImage));

打印rawData,這里就是圖片的原始數(shù)據(jù).

事實(shí)上,不管是 JPEG 還是 PNG 圖片,都是一種壓縮的位圖圖形格式。只不過(guò) PNG 圖片是無(wú)損壓縮,并且支持 alpha 通道,而 JPEG 圖片則是有損壓縮,可以指定 0-100% 的壓縮比。值得一提的是,在蘋(píng)果的 SDK 中專門(mén)提供了兩個(gè)函數(shù)用來(lái)生成 PNG 和 JPEG 圖片:

// return image as PNG. May return nil if image has no CGImageRef or invalid bitmap format
UIKIT_EXTERN NSData * __nullable UIImagePNGRepresentation(UIImage * __nonnull image);

// return image as JPEG. May return nil if image has no CGImageRef or invalid bitmap format. compression is 0(most)..1(least)                           
UIKIT_EXTERN NSData * __nullable UIImageJPEGRepresentation(UIImage * __nonnull image, CGFloat compressionQuality);

因此,在將磁盤(pán)中的圖片渲染到屏幕之前,必須先要得到圖片的原始像素?cái)?shù)據(jù),才能執(zhí)行后續(xù)的繪制操作,這就是為什么需要對(duì)圖片解壓縮的原因。

四.解壓縮原理

既然圖片的解壓縮不可避免,而我們也不想讓它在主線程執(zhí)行,影響我們應(yīng)用的響應(yīng)性,那么是否有比較好的解決方案呢?

我們前面已經(jīng)提到了,當(dāng)未解壓縮的圖片將要渲染到屏幕時(shí),系統(tǒng)會(huì)在主線程對(duì)圖片進(jìn)行解壓縮,而如果圖片已經(jīng)解壓縮了,系統(tǒng)就不會(huì)再對(duì)圖片進(jìn)行解壓縮。因此,也就有了業(yè)內(nèi)的解決方案,在子線程提前對(duì)圖片進(jìn)行強(qiáng)制解壓縮。

而強(qiáng)制解壓縮的原理就是對(duì)圖片進(jìn)行重新繪制,得到一張新的解壓縮后的位圖。其中,用到的最核心的函數(shù)是 CGBitmapContextCreate :

CG_EXTERN CGContextRef __nullable CGBitmapContextCreate(void * __nullable data,
    size_t width, size_t height, size_t bitsPerComponent, size_t bytesPerRow,
    CGColorSpaceRef cg_nullable space, uint32_t bitmapInfo)
    CG_AVAILABLE_STARTING(__MAC_10_0, __IPHONE_2_0);
  • data :如果不為 NULL ,那么它應(yīng)該指向一塊大小至少為 bytesPerRow * height 字節(jié)的內(nèi)存;如果 為 NULL ,那么系統(tǒng)就會(huì)為我們自動(dòng)分配和釋放所需的內(nèi)存,所以一般指定 NULL 即可;
  • width 和height :位圖的寬度和高度,分別賦值為圖片的像素寬度和像素高度即可;
  • bitsPerComponent :像素的每個(gè)顏色分量使用的 bit 數(shù),在 RGB 顏色空間下指定 8 即可;
  • bytesPerRow :位圖的每一行使用的字節(jié)數(shù),大小至少為 width * bytes per pixel 字節(jié)。當(dāng)我們指定 0/NULL 時(shí),系統(tǒng)不僅會(huì)為我們自動(dòng)計(jì)算,而且還會(huì)進(jìn)行cache line alignment 的優(yōu)化
  • space :就是我們前面提到的顏色空間,一般使用 RGB 即可;
  • bitmapInfo :位圖的布局信息.kCGImageAlphaPremultipliedFirst

五.YYImage\SDWebImage開(kāi)源框架實(shí)現(xiàn)

  • 用于解壓縮圖片的函數(shù) YYCGImageCreateDecodedCopy 存在于 YYImageCoder 類中,核心代碼如下
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 {
        ...
    }
}

它接受一個(gè)原始的位圖參數(shù) imageRef ,最終返回一個(gè)新的解壓縮后的位圖 newImage ,中間主要經(jīng)過(guò)了以下三個(gè)步驟:

  • 使用 CGBitmapContextCreate 函數(shù)創(chuàng)建一個(gè)位圖上下文;
  • 使用 CGContextDrawImage 函數(shù)將原始位圖繪制到上下文中;
  • 使用 CGBitmapContextCreateImage 函數(shù)創(chuàng)建一張新的解壓縮后的位圖。

事實(shí)上,SDWebImage 中對(duì)圖片的解壓縮過(guò)程與上述完全一致,只是傳遞給 CGBitmapContextCreate 函數(shù)的部分參數(shù)存在細(xì)微的差別

性能對(duì)比:
  • 在解壓PNG圖片,SDWebImage>YYImage
  • 在解壓JPEG圖片,SDWebImage<YYImage

總結(jié)

  1. 圖片文件只有在確認(rèn)要顯示時(shí),CPU才會(huì)對(duì)齊進(jìn)行解壓縮.因?yàn)榻鈮菏欠浅O男阅艿氖虑?解壓過(guò)的圖片就不會(huì)重復(fù)解壓,會(huì)緩存起來(lái).

  2. 圖片渲染到屏幕的過(guò)程: 讀取文件->計(jì)算Frame->圖片解碼->解碼后紋理圖片位圖數(shù)據(jù)通過(guò)數(shù)據(jù)總線交給GPU->GPU獲取圖片F(xiàn)rame->頂點(diǎn)變換計(jì)算->光柵化->根據(jù)紋理坐標(biāo)獲取每個(gè)像素點(diǎn)的顏色值(如果出現(xiàn)透明值需要將每個(gè)像素點(diǎn)的顏色*透明度值)->渲染到幀緩存區(qū)->渲染到屏幕

  3. 面試中如果能按照這個(gè)邏輯闡述,應(yīng)該沒(méi)有大的問(wèn)題.不過(guò),如果細(xì)問(wèn)到離屏渲染和渲染中的細(xì)節(jié)處理.就需要掌握OpenGL ES/Metal 這個(gè)2個(gè)圖形處理API. 面試過(guò)程可能會(huì)遇到不在自己技術(shù)能力范圍問(wèn)題,盡量知之為知之不知為不知.

https://github.com/SDWebImage/SDWebImage
https://github.com/ibireme/YYImage

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容