通過 圖形渲染原理 一文，大致能夠了解圖形渲染過程中硬件相關的原理。本文將進一步介紹 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 個步驟：
LayoutDisplayPrepareCommit
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 逐幀進行渲染。
參考
- Getting Pixels onto the Screen，中文版（iOS 開發：繪制像素到屏幕）
- 深入理解 iOS Rendering Process
- iOS Core Animation: Advanced Techniques中文譯本
- 關于drawRect
- iOS 繪圖與動畫原理剖析
- WWDC 2014 Session 419: Advanced Graphics and Animations for iOS Apps
擴展閱讀
- 離屏渲染優化詳解：實例示范+性能測試
- Mastering Offscreen Render
- Optimizing 2D Graphics and Animation Performance
- Polishing Your Interface Rotation Animations
- Core Animation Essentials
- Understanding UIKit Rendering
- iOS: Rendering the UI
- iOS 事件處理機制與圖像渲染過程
- iOS 動畫篇：核心動畫
- GPU Framebuffer Memory: Understanding Tiling
- iOS 保持界面流暢的技巧
- OpenGL ES 框架詳細解析（八） —— OpenGL ES 設計指南
- iOS 開發-視圖渲染與性能優化
- iOS 視圖、動畫渲染機制探究
- iOS 事件處理機制與圖像渲染過程
- iOS界面渲染流程
- 界面渲染的整體流程
- iOS圖像處理之Core Graphics和OpenGL ES初見
- WWDC 2012 Session 506: Optimizing 2D Graphics and Animations Performances
- WWDC 2011 Session 421: Core Animation Essentials
- WWDC 2011 Session 129: Practical Drawing for iOS Developers
