http://chuquan.me/2018/09/25/ios-graphics-render-principle/
通過 圖形渲染原理 一文，大緻能夠了解圖形渲染過程中硬體相關的原理。本文将進一步介紹 iOS 開發過程中圖形渲染原理。
圖形渲染技術棧
下圖所示為 iOS App 的圖形渲染技術棧，App 使用
Core Graphics
、
Core Animation
、
Core Image
等架構來繪制可視化内容，這些軟體架構互相之間也有着依賴關系。這些架構都需要通過 OpenGL 來調用 GPU 進行繪制，最終将内容顯示到螢幕之上。
iOS 渲染架構
UIKit
UIKit
UIKit
是 iOS 開發者最常用的架構，可以通過設定
UIKit
元件的布局以及相關屬性來繪制界面。
事實上，
UIKit
自身并不具備在螢幕成像的能力，其主要負責對使用者操作事件的響應（
UIView
繼承自
UIResponder
），事件響應的傳遞大體是經過逐層的 視圖樹 周遊實作的。
Core Animation
Core Animation
Core Animation
源自于
Layer Kit
，動畫隻是
Core Animation
特性的冰山一角。
Core Animation
是一個複合引擎，其職責是 盡可能快地組合螢幕上不同的可視内容，這些可視内容可被分解成獨立的圖層（即 CALayer），這些圖層會被存儲在一個叫做圖層樹的體系之中。從本質上而言，
CALayer
是使用者所能在螢幕上看見的一切的基礎。
Core Graphics
Core Graphics
Core Graphics
基于 Quartz 進階繪圖引擎，主要用于運作時繪制圖像。開發者可以使用此架構來處理基于路徑的繪圖，轉換，顔色管理，離屏渲染，圖案，漸變和陰影，圖像資料管理，圖像建立和圖像遮罩以及 PDF 文檔建立，顯示和分析。
當開發者需要在 運作時建立圖像 時，可以使用
Core Graphics
去繪制。與之相對的是 運作前建立圖像，例如用 Photoshop 提前做好圖檔素材直接導入應用。相比之下，我們更需要
Core Graphics
去在運作時實時計算、繪制一系列圖像幀來實作動畫。
Core Image
Core Image
Core Image
與
Core Graphics
恰恰相反，
Core Graphics
用于在 運作時建立圖像，而
Core Image
是用來處理 運作前建立的圖像 的。
Core Image
架構擁有一系列現成的圖像過濾器，能對已存在的圖像進行高效的處理。
大部分情況下，
Core Image
會在 GPU 中完成工作，但如果 GPU 忙，會使用 CPU 進行處理。
OpenGL ES
OpenGL ES
OpenGL ES
（OpenGL for Embedded Systems，簡稱 GLES），是 OpenGL 的子集。在前面的 圖形渲染原理綜述 一文中提到過 OpenGL 是一套第三方标準，函數的内部實作由對應的 GPU 廠商開發實作。
Metal
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
可以呈現可視化内容呢？因為
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
- 如果代理沒有實作
-displayLayer:
CALayer
-drawLayer:inContext:
CALayer
bounds
contentScale
Core Graphics
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
- 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
參考
- 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
轉載于:https://www.cnblogs.com/feng9exe/p/10896042.html