首先回答一個問題：CPU和GPU都能進行圖形渲染，只是GPU 圖形渲染的并行計算能力速度更快
屏幕圖像顯示原理
下圖所示為常見的 CPU锨用、GPU丰刊、顯示器工作方式。
CPU 計算好顯示內(nèi)容提交至 GPU增拥，GPU 渲染完成后將渲染結果存入幀緩沖區(qū)啄巧，視頻控制器會按照 VSync 信號逐幀讀取幀緩沖區(qū)的數(shù)據(jù)，經(jīng)過數(shù)據(jù)轉換后最終由顯示器進行顯示跪者。
最簡單的情況下棵帽，幀緩沖區(qū)只有一個熄求。此時渣玲，幀緩沖區(qū)的讀取和刷新都都會有比較大的效率問題。為了解決效率問題弟晚，GPU 通常會引入兩個緩沖區(qū)忘衍，即 雙緩沖機制。在這種情況下卿城，GPU 會預先渲染一幀放入一個緩沖區(qū)中枚钓，用于視頻控制器的讀取。當下一幀渲染完畢后瑟押，GPU 會直接把視頻控制器的指針指向第二個緩沖器搀捷。
雙緩沖雖然能解決效率問題，但會引入一個新的問題多望。當視頻控制器還未讀取完成時嫩舟，即屏幕內(nèi)容剛顯示一半時，GPU 將新的一幀內(nèi)容提交到幀緩沖區(qū)并把兩個緩沖區(qū)進行交換后怀偷，視頻控制器就會把新的一幀數(shù)據(jù)的下半段顯示到屏幕上家厌，造成畫面撕裂現(xiàn)象，如下圖：
視頻顯示器從幀緩沖區(qū)掃描繪制完成一幀畫面后椎工，會發(fā)出垂直同步信號饭于，簡稱VSync，當開啟垂直同步后维蒙，GPU 會等待顯示器的 VSync 信號發(fā)出后掰吕，才進行新的一幀渲染和緩沖區(qū)更新。
iOS 渲染框架
UIKit
UIKit 是 iOS 開發(fā)者最常用的框架颅痊，可以通過設置 UIKit 組件的布局以及相關屬性來繪制界面畴栖。
事實上， UIKit 自身并不具備在屏幕成像的能力八千，其主要負責對用戶操作事件的響應（UIView 繼承自 UIResponder）吗讶，事件響應的傳遞大體是經(jīng)過逐層的 視圖樹 遍歷實現(xiàn)的燎猛。
Core Animation
Core Animation 源自于 Layer Kit，動畫只是 Core Animation 特性的冰山一角照皆。
Core Animation 是一個復合引擎重绷，其職責是 盡可能快地組合屏幕上不同的可視內(nèi)容，這些可視內(nèi)容可被分解成獨立的圖層（即 CALayer）膜毁，這些圖層會被存儲在一個叫做圖層樹的體系之中昭卓。從本質上而言，CALayer 是用戶所能在屏幕上看見的一切的基礎瘟滨。
Core Graphics
Core Graphics 基于 Quartz 高級繪圖引擎候醒，主要用于運行時繪制圖像。工作步驟先傳輸命令到CPU杂瘸，計算完成后再提交到GPU倒淫。開發(fā)者可以使用此框架來處理基于路徑的繪圖，轉換败玉，顏色管理敌土，離屏渲染，圖案运翼，漸變和陰影返干，圖像數(shù)據(jù)管理，圖像創(chuàng)建和圖像遮罩以及 PDF 文檔創(chuàng)建血淌，顯示和分析矩欠。
Core Image
Core Image 與 Core Graphics 恰恰相反，Core Graphics 用于在 運行時創(chuàng)建圖像悠夯，而 Core Image 是用來處理 運行前創(chuàng)建的圖像 的癌淮。Core Image 框架擁有一系列現(xiàn)成的圖像過濾器，能對已存在的圖像進行高效的處理疗疟。
大部分情況下该默，Core Image 會在 GPU 中完成工作，但如果 GPU 忙策彤，會使用 CPU 進行處理栓袖。
OpenGL ES
OpenGL ES（OpenGL for Embedded Systems，簡稱 GLES）店诗，是 OpenGL 的子集裹刮。在前面的 圖形渲染原理綜述 一文中提到過 OpenGL 是一套第三方標準，函數(shù)的內(nèi)部實現(xiàn)由對應的 GPU 廠商開發(fā)實現(xiàn)庞瘸。
Metal
Metal 類似于 OpenGL ES捧弃，也是一套第三方標準，具體實現(xiàn)由蘋果實現(xiàn)。大多數(shù)開發(fā)者都沒有直接使用過 Metal违霞，但其實所有開發(fā)者都在間接地使用 Metal嘴办。Core Animation、Core Image买鸽、SceneKit涧郊、SpriteKit 等等渲染框架都是構建于 Metal 之上的。
當在真機上調試 OpenGL 程序時眼五，控制臺會打印出啟用 Metal 的日志妆艘。根據(jù)這一點可以猜測，Apple 已經(jīng)實現(xiàn)了一套機制將 OpenGL 命令無縫橋接到 Metal 上看幼，由 Metal 擔任真正于硬件交互的工作批旺。
OpenGL和Core Graphics
Core Graphics框架是先把命令輸入到CPU再調用GPU繪圖，OpenGL ES是直接操作GPU繪圖诵姜。很明顯OpenGL ES繪圖的效率更高汽煮。但是除了特別大的圖片運算需求外，我們很少使用OpenGL ES茅诱。因為繪制同一個圖形可能UIBezierPath需要5行代碼逗物，Core Graphics需要10行代碼搬卒，而使用OpenGL ES繪制一個圖形可能要300～400行代碼瑟俭。
CALayer
那么為什么 CALayer 可以呈現(xiàn)可視化內(nèi)容呢？因為 CALayer 基本等同于一個 紋理契邀。紋理是 GPU 進行圖像渲染的重要依據(jù)摆寄。
在 圖形渲染原理 中提到紋理本質上就是一張圖片，因此 CALayer 也包含一個 contents 屬性指向一塊緩存區(qū)坯门，稱為 backing store微饥，可以存放位圖（Bitmap）。iOS 中將該緩存區(qū)保存的圖片稱為 寄宿圖古戴。
圖形渲染流水線支持從頂點開始進行繪制（在流水線中欠橘，頂點會被處理生成紋理），也支持直接使用紋理（圖片）進行渲染现恼。相應地肃续，在實際開發(fā)中，繪制界面也有兩種方式：一種是 手動繪制叉袍；另一種是 使用圖片始锚。
對此，iOS 中也有兩種相應的實現(xiàn)方式：
- 使用圖片：contents image
- 手動繪制：custom drawing
Contents Image
Contents Image 是指通過 CALayer 的 contents 屬性來配置圖片喳逛。然而瞧捌，contents 屬性的類型為 id。在這種情況下，可以給 contents 屬性賦予任何值姐呐，app 仍可以編譯通過殿怜。但是在實踐中，如果 content 的值不是 CGImage 曙砂，得到的圖層將是空白的稳捆。
既然如此，為什么要將 contents 的屬性類型定義為 id 而非 CGImage麦轰。這是因為在 Mac OS 系統(tǒng)中乔夯，該屬性對 CGImage 和 NSImage 類型的值都起作用，而在 iOS 系統(tǒng)中款侵，該屬性只對 CGImage 起作用末荐。
本質上，contents 屬性指向的一塊緩存區(qū)域新锈，稱為 backing store甲脏，可以存放 bitmap 數(shù)據(jù)。
Custom Drawing
Custom Drawing 是指使用 Core Graphics 直接繪制寄宿圖妹笆。實際開發(fā)中块请，一般通過繼承 UIView 并實現(xiàn) -drawRect: 方法來自定義繪制。
雖然 -drawRect: 是一個 UIView 方法拳缠，但事實上都是底層的 CALayer 完成了重繪工作并保存了產(chǎn)生的圖片墩新。下圖所示為 -drawRect: 繪制定義寄宿圖的基本原理。
-
UIView有一個關聯(lián)圖層窟坐，即CALayer海渊。 -
CALayer有一個可選的delegate屬性，實現(xiàn)了CALayerDelegate協(xié)議哲鸳。UIView作為CALayer的代理實現(xiàn)了CALayerDelegae協(xié)議臣疑。 - 當需要重繪時，即調用
-drawRect:徙菠，CALayer請求其代理給予一個寄宿圖來顯示讯沈。 -
CALayer首先會嘗試調用-displayLayer:方法，此時代理可以直接設置contents屬性婿奔。
如果代理沒有實現(xiàn)
-displayLayer:方法缺狠，CALayer則會嘗試調用-drawLayer:inContext:方法。在調用該方法前脸秽，CALayer會創(chuàng)建一個空的寄宿圖（尺寸由bounds和contentScale決定）和一個Core Graphics的繪制上下文儒老，為繪制寄宿圖做準備，作為ctx參數(shù)傳入记餐。最后驮樊，由
Core Graphics繪制生成的寄宿圖會存入backing store。
Core Animation 流水線
通過前面的介紹，我們知道了 CALayer 的本質囚衔，那么它是如何調用 GPU 并顯示可視化內(nèi)容的呢挖腰？下面我們就需要介紹一下 Core Animation 流水線的工作原理。
事實上练湿，app 本身并不負責渲染猴仑，渲染則是由一個獨立的進程負責，即 Render Server 進程肥哎。
App 通過 IPC 將渲染任務及相關數(shù)據(jù)提交給 Render Server辽俗。Render Server 處理完數(shù)據(jù)后，再傳遞至 GPU篡诽。最后由 GPU 調用 iOS 的圖像設備進行顯示崖飘。
Core Animation 流水線的詳細過程如下：
- 首先，由 app 處理事件（Handle Events）杈女，如：用戶的點擊操作朱浴，在此過程中 app 可能需要更新 視圖樹，相應地达椰，圖層樹 也會被更新翰蠢。
- 其次，app 通過 CPU 完成對顯示內(nèi)容的計算啰劲，如：視圖的創(chuàng)建梁沧、布局計算、圖片解碼呈枉、文本繪制等趁尼。在完成對顯示內(nèi)容的計算之后埃碱，app 對圖層進行打包猖辫，并在下一次 RunLoop 時將其發(fā)送至
Render Server，即完成了一次Commit Transaction操作砚殿。 -
Render Server主要執(zhí)行 Open GL啃憎、Core Graphics 相關程序，并調用 GPU - GPU 則在物理層上完成了對圖像的渲染似炎。
- 最終辛萍，GPU 通過 Frame Buffer、視頻控制器等相關部件羡藐，將圖像顯示在屏幕上贩毕。
對上述步驟進行串聯(lián)，它們執(zhí)行所消耗的時間遠遠超過 16.67 ms仆嗦，因此為了滿足對屏幕的 60 FPS 刷新率的支持辉阶，需要將這些步驟進行分解，通過流水線的方式進行并行執(zhí)行，如下圖所示谆甜。
Commit Transaction
在 Core Animation 流水線中垃僚，app 調用 Render Server 前的最后一步 Commit Transaction 其實可以細分為 4 個步驟：
LayoutDisplayPrepareCommit
動畫渲染原理
iOS 動畫的渲染也是基于上述 Core Animation 流水線完成的。這里我們重點關注 app 與 Render Server 的執(zhí)行流程规辱。
日常開發(fā)中谆棺，如果不是特別復雜的動畫，一般使用 UIView Animation 實現(xiàn)罕袋，iOS 將其處理過程分為如下三部階段：
- Step 1：調用
animationWithDuration:animations:方法 - Step 2：在 Animation Block 中進行
Layout改淑，Display，Prepare浴讯，Commit等步驟溅固。 - Step 3：
Render Server根據(jù) Animation 逐幀進行渲染。
