通常計算機在顯示是CPU與GPU協同合作完成一次渲染.接下來我們瞭解一下CPU/GPU等在這樣一次渲染過程中,具體的分工是什麼?
- CPU: 計算視圖frame，圖片解碼，需要繪製紋理圖片通過數據總線交給GPU
- GPU: 紋理混合，頂點變換與計算,像素點的填充計算，渲染到幀緩衝區。
- 時鐘信號：垂直同步信號V-Sync / 水平同步信號H-Sync。
- iOS設備雙緩衝機制：顯示系統通常會引入兩個幀緩衝區，雙緩衝機制
圖片顯示到屏幕上是CPU與GPU的協作完成
對應應用來說，圖片是最佔用手機內存的資源，將一張圖片從磁盤中加載出來，並最終顯示到屏幕上，中間其實經過了一系列複雜的處理過程。
二.圖片加載的工作流程
- 假設我們使用 +imageWithContentsOfFile: 方法從磁盤中加載一張圖片，這個時候的圖片並沒有解壓縮；
- 然後將生成的 UIImage 賦值給 UIImageView ；
- 接著一個隱式的 CATransaction 捕獲到了 UIImageView 圖層樹的變化；
- 在主線程的下一個 runloop 到來時，Core Animation 提交了這個隱式的 transaction ，這個過程可能會對圖片進行 copy 操作，而受圖片是否字節對齊等因素的影響，這個 copy 操作可能會涉及以下部分或全部步驟：
- 分配內存緩衝區用於管理文件 IO 和解壓縮操作；
- 將文件數據從磁盤讀到內存中；
- 將壓縮的圖片數據解碼成未壓縮的位圖形式，這是一個非常耗時的 CPU 操作；
- 最後 Core Animation 中CALayer使用未壓縮的位圖數據渲染 UIImageView 的圖層。
- CPU計算好圖片的Frame,對圖片解壓之後.就會交給GPU來做圖片渲染
- 渲染流程
- GPU獲取獲取圖片的座標
- 將座標交給頂點著色器(頂點計算)
- 將圖片光柵化(獲取圖片對應屏幕上的像素點)
- 片元著色器計算(計算每個像素點的最終顯示的顏色值)
- 從幀緩存區中渲染到屏幕上
我們提到了圖片的解壓縮是一個非常耗時的 CPU 操作，並且它默認是在主線程中執行的。那麼當需要加載的圖片比較多時，就會對我們應用的響應性造成嚴重的影響，尤其是在快速滑動的列表上，這個問題會表現得更加突出。
三.為什麼要解壓縮圖片
既然圖片的解壓縮需要消耗大量的 CPU 時間，那麼我們為什麼還要對圖片進行解壓縮呢？是否可以不經過解壓縮，而直接將圖片顯示到屏幕上呢？答案是否定的。要想弄明白這個問題，我們首先需要知道什麼是位圖
其實，位圖就是一個像素數組，數組中的每個像素就代表著圖片中的一個點。我們在應用中經常用到的 JPEG 和 PNG 圖片就是位圖
大家可以嘗試
打印rawData,這裡就是圖片的原始數據.
事實上，不管是 JPEG 還是 PNG 圖片，都是一種壓縮的位圖圖形格式。只不過 PNG 圖片是無損壓縮，並且支持 alpha 通道，而 JPEG 圖片則是有損壓縮，可以指定 0-100% 的壓縮比。值得一提的是，在蘋果的 SDK 中專門提供了兩個函數用來生成 PNG 和 JPEG 圖片：
因此，在將磁盤中的圖片渲染到屏幕之前，必須先要得到圖片的原始像素數據，才能執行後續的繪製操作，這就是為什麼需要對圖片解壓縮的原因。
四.解壓縮原理
既然圖片的解壓縮不可避免，而我們也不想讓它在主線程執行，影響我們應用的響應性，那麼是否有比較好的解決方案呢？
我們前面已經提到了，當未解壓縮的圖片將要渲染到屏幕時，系統會在主線程對圖片進行解壓縮，而如果圖片已經解壓縮了，系統就不會再對圖片進行解壓縮。因此，也就有了業內的解決方案，在子線程提前對圖片進行強制解壓縮。
而強制解壓縮的原理就是對圖片進行重新繪製，得到一張新的解壓縮後的位圖。其中，用到的最核心的函數是 CGBitmapContextCreate ：
data ：如果不為 NULL ，那麼它應該指向一塊大小至少為 bytesPerRow * height 字節的內存；如果 為 NULL ，那麼系統就會為我們自動分配和釋放所需的內存，所以一般指定 NULL 即可；
width 和height ：位圖的寬度和高度，分別賦值為圖片的像素寬度和像素高度即可；
bitsPerComponent ：像素的每個顏色分量使用的 bit 數，在 RGB 顏色空間下指定 8 即可；
bytesPerRow ：位圖的每一行使用的字節數，大小至少為 width * bytes per pixel 字節。當我們指定 0/NULL 時，系統不僅會為我們自動計算，而且還會進行 cache line alignment的優化
space ：就是我們前面提到的顏色空間，一般使用 RGB 即可；
bitmapInfo ：位圖的佈局信息
.kCGImageAlphaPremultipliedFirst
五.YYImage\SDWebImage開源框架實現
- 用於解壓縮圖片的函數 YYCGImageCreateDecodedCopy 存在於 YYImageCoder 類中，核心代碼如下
它接受一個原始的位圖參數 imageRef ，最終返回一個新的解壓縮後的位圖 newImage ，中間主要經過了以下三個步驟：
- 使用 CGBitmapContextCreate 函數創建一個位圖上下文；
- 使用 CGContextDrawImage 函數將原始位圖繪製到上下文中；
- 使用 CGBitmapContextCreateImage 函數創建一張新的解壓縮後的位圖。
事實上，SDWebImage 中對圖片的解壓縮過程與上述完全一致，只是傳遞給 CGBitmapContextCreate 函數的部分參數存在細微的差別
性能對比:
- 在解壓PNG圖片,SDWebImage>YYImage
- 在解壓JPEG圖片,SDWebImage
總結
- 圖片文件只有在確認要顯示時,CPU才會對齊進行解壓縮.因為解壓是非常消耗性能的事情.解壓過的圖片就不會重複解壓,會緩存起來.
- 圖片渲染到屏幕的過程: 讀取文件->計算Frame->圖片解碼->解碼後紋理圖片位圖數據通過數據總線交給GPU->GPU獲取圖片Frame->頂點變換計算->光柵化->根據紋理座標獲取每個像素點的顏色值(如果出現透明值需要將每個像素點的顏色*透明度值)->渲染到幀緩存區->渲染到屏幕
- 面試中如果能按照這個邏輯闡述,應該沒有大的問題.不過,如果細問到離屏渲染和渲染中的細節處理.就需要掌握OpenGL ES/Metal 這個2個圖形處理API. 面試過程可能會遇到不在自己技術能力範圍問題,儘量知之為知之不知為不知.
