iOS 圖像渲染原理

經過 圖形渲染原理 一文，大體可以瞭解圖形渲染過程當中硬件相關的原理。本文將進一步介紹 iOS 開發過程當中圖形渲染原理。

圖形渲染技術棧

下圖所示爲 iOS App 的圖形渲染技術棧，App 使用 Core Graphics、Core Animation、Core Image 等框架來繪製可視化內容，這些軟件框架相互之間也有着依賴關係。這些框架都須要經過 OpenGL 來調用 GPU 進行繪製，最終將內容顯示到屏幕之上。

iOS 渲染框架

UIKit

UIKit 是 iOS 開發者最經常使用的框架，能夠經過設置 UIKit 組件的佈局以及相關屬性來繪製界面。

事實上， UIKit 自身並不具有在屏幕成像的能力，其主要負責對用戶操做事件的響應（UIView 繼承自 UIResponder），事件響應的傳遞大致是通過逐層的 視圖樹 遍歷實現的。

Core Animation

Core Animation 源自於 Layer Kit，動畫只是 Core Animation 特性的冰山一角。

Core Animation 是一個複合引擎，其職責是 儘量快地組合屏幕上不一樣的可視內容，這些可視內容可被分解成獨立的圖層（即 CALayer），這些圖層會被存儲在一個叫作圖層樹的體系之中。從本質上而言，CALayer 是用戶所能在屏幕上看見的一切的基礎。

Core Graphics

Core Graphics 基於 Quartz 高級繪圖引擎，主要用於運行時繪製圖像。開發者可使用此框架來處理基於路徑的繪圖，轉換，顏色管理，離屏渲染，圖案，漸變和陰影，圖像數據管理，圖像建立和圖像遮罩以及 PDF 文檔建立，顯示和分析。

當開發者須要在 運行時建立圖像 時，可使用 Core Graphics 去繪製。與之相對的是 運行前建立圖像，例如用 Photoshop 提早作好圖片素材直接導入應用。相比之下，咱們更須要 Core Graphics 去在運行時實時計算、繪製一系列圖像幀來實現動畫。

Core Image

Core Image 與 Core Graphics 偏偏相反，Core Graphics 用於在 運行時建立圖像，而 Core Image 是用來處理 運行前建立的圖像 的。Core Image 框架擁有一系列現成的圖像過濾器，能對已存在的圖像進行高效的處理。

大部分狀況下，Core Image 會在 GPU 中完成工做，但若是 GPU 忙，會使用 CPU 進行處理。

OpenGL ES

OpenGL ES（OpenGL for Embedded Systems，簡稱 GLES），是 OpenGL 的子集。在前面的 圖形渲染原理綜述 一文中提到過 OpenGL 是一套第三方標準，函數的內部實現由對應的 GPU 廠商開發實現。

Metal

Metal 相似於 OpenGL ES，也是一套第三方標準，具體實現由蘋果實現。大多數開發者都沒有直接使用過 Metal，但其實全部開發者都在間接地使用 Metal。Core Animation、Core Image、SceneKit、SpriteKit 等等渲染框架都是構建於 Metal 之上的。

當在真機上調試 OpenGL 程序時，控制檯會打印出啓用 Metal 的日誌。根據這一點能夠猜想，Apple 已經實現了一套機制將 OpenGL 命令無縫橋接到 Metal 上，由 Metal 擔任真正於硬件交互的工做。

UIView 與 CALayer 的關係

在前面的 Core Animation 簡介中提到 CALayer 事實上是用戶所能在屏幕上看見的一切的基礎。爲何 UIKit 中的視圖可以呈現可視化內容？就是由於 UIKit 中的每個 UI 視圖控件其實內部都有一個關聯的 CALayer，即 backing layer。

因爲這種一一對應的關係，視圖層級擁有 視圖樹 的樹形結構，對應 CALayer 層級也擁有 圖層樹 的樹形結構。

其中，視圖的職責是 建立並管理 圖層，以確保當子視圖在層級關係中 添加或被移除 時，其關聯的圖層在圖層樹中也有相同的操做，即保證視圖樹和圖層樹在結構上的一致性。

那麼爲何 iOS 要基於 UIView 和 CALayer 提供兩個平行的層級關係呢？

其緣由在於要作 職責分離，這樣也能避免不少重複代碼。在 iOS 和 Mac OS X 兩個平臺上，事件和用戶交互有不少地方的不一樣，基於多點觸控的用戶界面和基於鼠標鍵盤的交互有着本質的區別，這就是爲何 iOS 有 UIKit 和 UIView，對應 Mac OS X 有 AppKit 和 NSView 的緣由。它們在功能上很類似，可是在實現上有着顯著的區別。

實際上，這裏並非兩個層級關係，而是四個。每個都扮演着不一樣的角色。除了 視圖樹 和 圖層樹，還有 呈現樹 和 渲染樹。

CALayer

那麼爲何 CALayer 能夠呈現可視化內容呢？由於 CALayer 基本等同於一個 紋理。紋理是 GPU 進行圖像渲染的重要依據。

在 圖形渲染原理 中提到紋理本質上就是一張圖片，所以 CALayer 也包含一個 contents 屬性指向一塊緩存區，稱爲 backing store，能夠存放位圖（Bitmap）。iOS 中將該緩存區保存的圖片稱爲 寄宿圖。

圖形渲染流水線支持從頂點開始進行繪製（在流水線中，頂點會被處理生成紋理），也支持直接使用紋理（圖片）進行渲染。相應地，在實際開發中，繪製界面也有兩種方式：一種是 手動繪製；另外一種是 使用圖片。

對此，iOS 中也有兩種相應的實現方式：

• 使用圖片：contents image
• 手動繪製：custom drawing

Contents Image

Contents Image 是指經過 CALayer 的 contents 屬性來配置圖片。然而，contents 屬性的類型爲 id。在這種狀況下，能夠給 contents 屬性賦予任何值，app 仍能夠編譯經過。可是在實踐中，若是 content 的值不是 CGImage ，獲得的圖層將是空白的。

既然如此，爲何要將 contents 的屬性類型定義爲 id 而非 CGImage。這是由於在 Mac OS 系統中，該屬性對 CGImage 和 NSImage 類型的值都起做用，而在 iOS 系統中，該屬性只對 CGImage 起做用。

本質上，contents 屬性指向的一塊緩存區域，稱爲 backing store，能夠存放 bitmap 數據。

Custom Drawing

Custom Drawing 是指使用 Core Graphics 直接繪製寄宿圖。實際開發中，通常經過繼承 UIView 並實現 -drawRect: 方法來自定義繪製。

雖然 -drawRect: 是一個 UIView 方法，但事實上都是底層的 CALayer 完成了重繪工做並保存了產生的圖片。下圖所示爲 -drawRect: 繪製定義寄宿圖的基本原理。

• UIView 有一個關聯圖層，即 CALayer。
• CALayer 有一個可選的 delegate 屬性，實現了 CALayerDelegate 協議。UIView 做爲 CALayer 的代理實現了 CALayerDelegae 協議。
• 當須要重繪時，即調用 -drawRect:，CALayer 請求其代理給予一個寄宿圖來顯示。

• CALayer 首先會嘗試調用 -displayLayer: 方法，此時代理能夠直接設置 contents 屬性。

  - (void)displayLayer:(CALayer *)layer;
  複製代碼

• 若是代理沒有實現 -displayLayer: 方法，CALayer 則會嘗試調用 -drawLayer:inContext: 方法。在調用該方法前，CALayer 會建立一個空的寄宿圖（尺寸由 bounds 和 contentScale 決定）和一個 Core Graphics 的繪製上下文，爲繪製寄宿圖作準備，做爲 ctx 參數傳入。

  - (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx;
  複製代碼

• 最後，由 Core Graphics 繪製生成的寄宿圖會存入 backing store。

Core Animation 流水線

經過前面的介紹，咱們知道了 CALayer 的本質，那麼它是如何調用 GPU 並顯示可視化內容的呢？下面咱們就須要介紹一下 Core Animation 流水線的工做原理。

事實上，app 自己並不負責渲染，渲染則是由一個獨立的進程負責，即 Render Server 進程。

App 經過 IPC 將渲染任務及相關數據提交給 Render Server。Render Server 處理完數據後，再傳遞至 GPU。最後由 GPU 調用 iOS 的圖像設備進行顯示。

Core Animation 流水線的詳細過程以下：

• 首先，由 app 處理事件（Handle Events），如：用戶的點擊操做，在此過程當中 app 可能須要更新 視圖樹，相應地，圖層樹 也會被更新。
• 其次，app 經過 CPU 完成對顯示內容的計算，如：視圖的建立、佈局計算、圖片解碼、文本繪製等。在完成對顯示內容的計算以後，app 對圖層進行打包，並在下一次 RunLoop 時將其發送至 Render Server，即完成了一次 Commit Transaction 操做。
• Render Server 主要執行 Open GL、Core Graphics 相關程序，並調用 GPU
• GPU 則在物理層上完成了對圖像的渲染。
• 最終，GPU 經過 Frame Buffer、視頻控制器等相關部件，將圖像顯示在屏幕上。

對上述步驟進行串聯，它們執行所消耗的時間遠遠超過 16.67 ms，所以爲了知足對屏幕的 60 FPS 刷新率的支持，須要將這些步驟進行分解，經過流水線的方式進行並行執行，以下圖所示。

Commit Transaction

在 Core Animation 流水線中，app 調用 Render Server 前的最後一步 Commit Transaction 其實能夠細分爲 4 個步驟：

• Layout
• Display
• Prepare
• Commit

Layout

Layout 階段主要進行視圖構建，包括：LayoutSubviews 方法的重載，addSubview: 方法填充子視圖等。

Display

Display 階段主要進行視圖繪製，這裏僅僅是設置最要成像的圖元數據。重載視圖的 drawRect: 方法能夠自定義 UIView 的顯示，其原理是在 drawRect: 方法內部繪製寄宿圖，該過程使用 CPU 和內存。

Prepare

Prepare 階段屬於附加步驟，通常處理圖像的解碼和轉換等操做。

Commit

Commit 階段主要將圖層進行打包，並將它們發送至 Render Server。該過程會遞歸執行，由於圖層和視圖都是以樹形結構存在。

動畫渲染原理

iOS 動畫的渲染也是基於上述 Core Animation 流水線完成的。這裏咱們重點關注 app 與 Render Server 的執行流程。

平常開發中，若是不是特別複雜的動畫，通常使用 UIView Animation 實現，iOS 將其處理過程分爲以下三部階段：

• Step 1：調用 animationWithDuration:animations: 方法
• Step 2：在 Animation Block 中進行 Layout，Display，Prepare，Commit 等步驟。
• Step 3：Render Server 根據 Animation 逐幀進行渲染。

參考

1. Getting Pixels onto the Screen，中文版（iOS 開發：繪製像素到屏幕）
2. 深刻理解 iOS Rendering Process
3. iOS Core Animation: Advanced Techniques中文譯本
4. 關於drawRect
5. iOS 繪圖與動畫原理剖析
6. WWDC 2014 Session 419: Advanced Graphics and Animations for iOS Apps

擴展閱讀

1. 離屏渲染優化詳解：實例示範+性能測試
2. Mastering Offscreen Render
3. Optimizing 2D Graphics and Animation Performance
4. Polishing Your Interface Rotation Animations
5. Core Animation Essentials
6. Understanding UIKit Rendering
7. iOS: Rendering the UI
8. iOS 事件處理機制與圖像渲染過程
9. iOS 動畫篇：核心動畫
10. GPU Framebuffer Memory: Understanding Tiling
11. iOS 保持界面流暢的技巧
12. OpenGL ES 框架詳細解析（八） —— OpenGL ES 設計指南
13. iOS 開發-視圖渲染與性能優化
14. iOS 視圖、動畫渲染機制探究
15. iOS 事件處理機制與圖像渲染過程
16. iOS界面渲染流程
17. 界面渲染的總體流程
18. iOS圖像處理之Core Graphics和OpenGL ES初見
19. WWDC 2012 Session 506: Optimizing 2D Graphics and Animations Performances
20. WWDC 2011 Session 421: Core Animation Essentials
21. WWDC 2011 Session 129: Practical Drawing for iOS Developers