UI視圖的事件傳遞、顯示原理、繪制原理、離屏渲染

一、UIView和CALayer

1、關(guān)系

UIView屬性：MyView、layer、backgroundColor。其中l(wèi)ayer其實(shí)就是CALayer的類(lèi)型，backgroundColor是對(duì)CALayer同名屬性方法的包裝，UIView顯示是由CALayer的contents決定的。關(guān)系圖如下：


UIView和CALayer之間的關(guān)系

2、區(qū)別

UIView 為其提供內(nèi)容，以及負(fù)責(zé)處理觸摸等事件，參與響應(yīng)鏈。
CALayer 負(fù)責(zé)顯示內(nèi)容contents。
注：這里體現(xiàn)的是單一職責(zé)。

二、視圖事件傳遞和響應(yīng)機(jī)制

1、事件傳遞

  • 事件傳遞系統(tǒng)方法如下:
/**
 哪個(gè)視圖響應(yīng)事件就把哪個(gè)視圖返回
 @param point 接收器局部坐標(biāo)系中指定的點(diǎn)（邊界）
 @param event 保證調(diào)用此方法的事件，如果從事件處理代碼外部調(diào)用此方法，則可以指定nil
 @return 響應(yīng)的UIView。如果該點(diǎn)完全位于接收者的視圖層次結(jié)構(gòu)之外，則返回nil。
 */
- (UIView*)hitTest:(CGPoint)point withEvent:(UIEvent*)event;

/**
 判斷某一個(gè)點(diǎn)擊的位置是否在當(dāng)前視圖的范圍內(nèi)
 @param point 點(diǎn)擊點(diǎn)的位置
 @param event 保證調(diào)用此方法的事件，如果從事件處理代碼外部調(diào)用此方法，則可以指定nil
 @return 如果點(diǎn)位于接收者的界限內(nèi)，則為YES; 否則，不。
 */
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent*)event;
  • 事件傳遞流程：

點(diǎn)擊屏幕某一位置,這個(gè)事件就會(huì)傳遞到UIApplication，再由UIApplication傳遞到當(dāng)前的UIWindow ，然后UIWindow里就會(huì)判斷hitTest: withEvent:來(lái)返回最終的響應(yīng)視圖，這個(gè)是通過(guò)調(diào)用pointInside: withEvent:來(lái)判斷當(dāng)前點(diǎn)擊位置是否在UIWindow范圍內(nèi)，如果在范圍內(nèi)就會(huì)\color{red}{倒序遍歷}(最后添加到UIWindow上的視圖最優(yōu)先被遍歷到)子視圖來(lái)查找最終響應(yīng)這個(gè)事件的視圖，即在每一個(gè)視圖都會(huì)調(diào)用hitTest: withEvent:方法，并返回一個(gè)響應(yīng)視圖，如果視圖有值，這個(gè)視圖就做為最終的事件響應(yīng)視圖。如果事件一直傳遞到UIAppliction還是沒(méi)處理，那就會(huì)忽略掉。如圖所示：

事件傳遞流程圖
  • hitTest: withEvent:系統(tǒng)實(shí)現(xiàn)

在這個(gè)系統(tǒng)方法內(nèi)部會(huì)優(yōu)先判斷當(dāng)前視圖的hidden、userInteractionEnabled和alpha屬性，如果當(dāng)前視圖不隱藏，可交互且alpha>0.01 則會(huì)調(diào)用pointInside: withEvent:，否則返回nil結(jié)束事件。通過(guò)調(diào)用pointInside: withEvent:判斷當(dāng)前點(diǎn)是否在視圖內(nèi)，如果其返回YES則會(huì)遍歷當(dāng)前視圖的子視圖的hitTest: withEvent:直到找到sv!=nil返回sv ，結(jié)束事件；如果沒(méi)有子視圖就返回當(dāng)前視圖，結(jié)束事件。如圖所示：

hitTest: withEvent:系統(tǒng)實(shí)現(xiàn)圖

2、響應(yīng)機(jī)制

視圖響應(yīng)傳遞鏈的流程圖。注意：箭頭表示\color{red}{下一個(gè)響應(yīng)者}

蘋(píng)果官網(wǎng)的響應(yīng)流程圖
  • 視圖事件響應(yīng)系統(tǒng)方法

///告訴此對(duì)象在視圖或窗口中發(fā)生了一個(gè)或多個(gè)新觸摸
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
///當(dāng)與事件關(guān)聯(lián)的一個(gè)或多個(gè)觸摸發(fā)生更改時(shí)，告知響應(yīng)者
- (void)touchesMoved:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
///當(dāng)從視圖或窗口抬起一個(gè)或多個(gè)手指時(shí)告訴響應(yīng)者
- (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;

三、圖像顯示原理

原理：CPU和GPU都是通過(guò)總線連接起來(lái)，在CPU中輸出的位圖經(jīng)由總線在合適的時(shí)機(jī)上傳給GPU，GPU拿到位圖做相應(yīng)位圖的圖層渲染、紋理合成，之后將渲染好的結(jié)果放到幀緩沖區(qū)，由視頻控制器根據(jù)Vsync（垂直同步信號(hào)）在指定時(shí)間之前去提取對(duì)應(yīng)幀緩沖區(qū)當(dāng)中的屏幕顯示內(nèi)容，最終顯示到顯示器即手機(jī)屏幕上。如圖所示：

圖像顯示原理圖1
圖像顯示原理圖2

  • CPU工作
    1.Layout: UI布局，文本計(jì)算
    2.Display: 繪制
    3.Prepare: 圖片解碼
    4.Commit：提交位圖

  • GPU渲染管線
    頂點(diǎn)著色，圖元裝配，光柵化，片段著色，片段處理

  • UI卡頓、掉幀原因
    由圖像的顯示原理，我們知道一幀的顯示是由CPU和GPU共同決定的。一般來(lái)說(shuō)，頁(yè)面滑動(dòng)流暢是60fps，也就是1s有60幀更新，即每隔16.7ms就要產(chǎn)生一幀畫(huà)面，而如果CPU和GPU加起來(lái)的處理時(shí)間超過(guò)了16.7ms，就會(huì)造成掉幀甚至卡頓。

UI卡頓、掉幀原因圖解

四、滑動(dòng)優(yōu)化方案

因?yàn)閳D像原理可知CPU和GPU共同決定了UI是否卡頓、掉幀，所以優(yōu)化需從\color{red}{CPU和GPU}解決。優(yōu)化方案是從iOS 保持界面流暢的技巧中copy??的，大家可以看看這篇文章。

  • CPU 資源消耗原因和解決方案

\color{red}{對(duì)象創(chuàng)建}

對(duì)象的創(chuàng)建會(huì)分配內(nèi)存、調(diào)整屬性、甚至還有讀取文件等操作，比較消耗 CPU 資源。盡量用輕量的對(duì)象代替重量的對(duì)象，可以對(duì)性能有所優(yōu)化。比如 CALayer 比 UIView 要輕量許多，那么不需要響應(yīng)觸摸事件的控件，用 CALayer 顯示會(huì)更加合適。如果對(duì)象不涉及 UI 操作，則盡量放到后臺(tái)線程去創(chuàng)建，但可惜的是包含有 CALayer 的控件，都只能在主線程創(chuàng)建和操作。通過(guò) Storyboard 創(chuàng)建視圖對(duì)象時(shí)，其資源消耗會(huì)比直接通過(guò)代碼創(chuàng)建對(duì)象要大非常多，在性能敏感的界面里，Storyboard 并不是一個(gè)好的技術(shù)選擇。

盡量推遲對(duì)象創(chuàng)建的時(shí)間，并把對(duì)象的創(chuàng)建分散到多個(gè)任務(wù)中去。盡管這實(shí)現(xiàn)起來(lái)比較麻煩，并且?guī)?lái)的優(yōu)勢(shì)并不多，但如果有能力做，還是要盡量嘗試一下。如果對(duì)象可以復(fù)用，并且復(fù)用的代價(jià)比釋放、創(chuàng)建新對(duì)象要小，那么這類(lèi)對(duì)象應(yīng)當(dāng)盡量放到一個(gè)緩存池里復(fù)用。

\color{red}{對(duì)象調(diào)整}

對(duì)象的調(diào)整也經(jīng)常是消耗 CPU 資源的地方。這里特別說(shuō)一下 CALayer：CALayer 內(nèi)部并沒(méi)有屬性，當(dāng)調(diào)用屬性方法時(shí)，它內(nèi)部是通過(guò)運(yùn)行時(shí) resolveInstanceMethod 為對(duì)象臨時(shí)添加一個(gè)方法，并把對(duì)應(yīng)屬性值保存到內(nèi)部的一個(gè) Dictionary 里，同時(shí)還會(huì)通知 delegate、創(chuàng)建動(dòng)畫(huà)等等，非常消耗資源。UIView 的關(guān)于顯示相關(guān)的屬性（比如 frame/bounds/transform）等實(shí)際上都是 CALayer 屬性映射來(lái)的，所以對(duì) UIView 的這些屬性進(jìn)行調(diào)整時(shí)，消耗的資源要遠(yuǎn)大于一般的屬性。對(duì)此你在應(yīng)用中，應(yīng)該盡量減少不必要的屬性修改。

當(dāng)視圖層次調(diào)整時(shí)，UIView、CALayer 之間會(huì)出現(xiàn)很多方法調(diào)用與通知，所以在優(yōu)化性能時(shí)，應(yīng)該盡量避免調(diào)整視圖層次、添加和移除視圖。

\color{red}{對(duì)象銷(xiāo)毀}

對(duì)象的銷(xiāo)毀雖然消耗資源不多，但累積起來(lái)也是不容忽視的。通常當(dāng)容器類(lèi)持有大量對(duì)象時(shí)，其銷(xiāo)毀時(shí)的資源消耗就非常明顯。同樣的，如果對(duì)象可以放到后臺(tái)線程去釋放，那就挪到后臺(tái)線程去。這里有個(gè)小 Tip：把對(duì)象捕獲到 block 中，然后扔到后臺(tái)隊(duì)列去隨便發(fā)送個(gè)消息以避免編譯器警告，就可以讓對(duì)象在后臺(tái)線程銷(xiāo)毀了。

NSArray *tmp = self.array;
self.array = nil;
dispatch_async(queue, ^{
    [tmp class];
});

\color{red}{布局計(jì)算}

視圖布局的計(jì)算是 App 中最為常見(jiàn)的消耗 CPU 資源的地方。如果能在后臺(tái)線程提前計(jì)算好視圖布局、并且對(duì)視圖布局進(jìn)行緩存，那么這個(gè)地方基本就不會(huì)產(chǎn)生性能問(wèn)題了。

不論通過(guò)何種技術(shù)對(duì)視圖進(jìn)行布局，其最終都會(huì)落到對(duì) UIView.frame/bounds/center 等屬性的調(diào)整上。上面也說(shuō)過(guò)，對(duì)這些屬性的調(diào)整非常消耗資源，所以盡量提前計(jì)算好布局，在需要時(shí)一次性調(diào)整好對(duì)應(yīng)屬性，而不要多次、頻繁的計(jì)算和調(diào)整這些屬性。

\color{red}{Autolayout}

Autolayout 是蘋(píng)果本身提倡的技術(shù)，在大部分情況下也能很好的提升開(kāi)發(fā)效率，但是 Autolayout 對(duì)于復(fù)雜視圖來(lái)說(shuō)常常會(huì)產(chǎn)生嚴(yán)重的性能問(wèn)題。隨著視圖數(shù)量的增長(zhǎng)，Autolayout 帶來(lái)的 CPU 消耗會(huì)呈指數(shù)級(jí)上升。具體數(shù)據(jù)可以看這個(gè)文章：http://pilky.me/36/。 如果你不想手動(dòng)調(diào)整 frame 等屬性，你可以用一些工具方法替代（比如常見(jiàn)的 left/right/top/bottom/width/height 快捷屬性），或者使用 ComponentKit、AsyncDisplayKit 等框架。

\color{red}{文本計(jì)算}

如果一個(gè)界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計(jì)算會(huì)占用很大一部分資源，并且不可避免。如果你對(duì)文本顯示沒(méi)有特殊要求，可以參考下 UILabel 內(nèi)部的實(shí)現(xiàn)方式：用 [NSAttributedString boundingRectWithSize:options:context:] 來(lái)計(jì)算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來(lái)繪制文本。盡管這兩個(gè)方法性能不錯(cuò)，但仍舊需要放到后臺(tái)線程進(jìn)行以避免阻塞主線程。

如果你用 CoreText 繪制文本，那就可以先生成 CoreText 排版對(duì)象，然后自己計(jì)算了，并且 CoreText 對(duì)象還能保留以供稍后繪制使用。

\color{red}{文本渲染}

屏幕上能看到的所有文本內(nèi)容控件，包括 UIWebView，在底層都是通過(guò) CoreText 排版、繪制為 Bitmap 顯示的。常見(jiàn)的文本控件 （UILabel、UITextView 等），其排版和繪制都是在主線程進(jìn)行的，當(dāng)顯示大量文本時(shí)，CPU 的壓力會(huì)非常大。對(duì)此解決方案只有一個(gè)，那就是自定義文本控件，用 TextKit 或最底層的 CoreText 對(duì)文本異步繪制。盡管這實(shí)現(xiàn)起來(lái)非常麻煩，但其帶來(lái)的優(yōu)勢(shì)也非常大，CoreText 對(duì)象創(chuàng)建好后，能直接獲取文本的寬高等信息，避免了多次計(jì)算（調(diào)整 UILabel 大小時(shí)算一遍、UILabel 繪制時(shí)內(nèi)部再算一遍）；CoreText 對(duì)象占用內(nèi)存較少，可以緩存下來(lái)以備稍后多次渲染。

\color{red}{圖片的解碼}

當(dāng)你用 UIImage 或 CGImageSource 的那幾個(gè)方法創(chuàng)建圖片時(shí)，圖片數(shù)據(jù)并不會(huì)立刻解碼。圖片設(shè)置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的數(shù)據(jù)才會(huì)得到解碼。這一步是發(fā)生在主線程的，并且不可避免。如果想要繞開(kāi)這個(gè)機(jī)制，常見(jiàn)的做法是在后臺(tái)線程先把圖片繪制到 CGBitmapContext 中，然后從 Bitmap 直接創(chuàng)建圖片。目前常見(jiàn)的網(wǎng)絡(luò)圖片庫(kù)都自帶這個(gè)功能。

\color{red}{圖像的繪制}

圖像的繪制通常是指用那些以 CG 開(kāi)頭的方法把圖像繪制到畫(huà)布中，然后從畫(huà)布創(chuàng)建圖片并顯示這樣一個(gè)過(guò)程。這個(gè)最常見(jiàn)的地方就是 [UIView drawRect:] 里面了。由于 CoreGraphic 方法通常都是線程安全的，所以圖像的繪制可以很容易的放到后臺(tái)線程進(jìn)行。一個(gè)簡(jiǎn)單異步繪制的過(guò)程大致如下（實(shí)際情況會(huì)比這個(gè)復(fù)雜得多，但原理基本一致）：

- (void)display {
    dispatch_async(backgroundQueue, ^{
        CGContextRef ctx = CGBitmapContextCreate(...);
        // draw in context...
        CGImageRef img = CGBitmapContextCreateImage(ctx);
        CFRelease(ctx);
        dispatch_async(mainQueue, ^{
            layer.contents = img;
        });
    });
}
  • GPU 資源消耗原因和解決方案

相對(duì)于 CPU 來(lái)說(shuō)，GPU 能干的事情比較單一：接收提交的紋理（Texture）和頂點(diǎn)描述（三角形），應(yīng)用變換（transform）、混合并渲染，然后輸出到屏幕上。通常你所能看到的內(nèi)容，主要也就是紋理（圖片）和形狀（三角模擬的矢量圖形）兩類(lèi)。

\color{red}{紋理渲染}

所有的 Bitmap，包括圖片、文本、柵格化的內(nèi)容，最終都要由內(nèi)存提交到顯存，綁定為 GPU Texture。不論是提交到顯存的過(guò)程，還是 GPU 調(diào)整和渲染 Texture 的過(guò)程，都要消耗不少 GPU 資源。當(dāng)在較短時(shí)間顯示大量圖片時(shí)（比如 TableView 存在非常多的圖片并且快速滑動(dòng)時(shí)），CPU 占用率很低，GPU 占用非常高，界面仍然會(huì)掉幀。避免這種情況的方法只能是盡量減少在短時(shí)間內(nèi)大量圖片的顯示，盡可能將多張圖片合成為一張進(jìn)行顯示。

當(dāng)圖片過(guò)大，超過(guò) GPU 的最大紋理尺寸時(shí)，圖片需要先由 CPU 進(jìn)行預(yù)處理，這對(duì) CPU 和 GPU 都會(huì)帶來(lái)額外的資源消耗。目前來(lái)說(shuō)，iPhone 4S 以上機(jī)型，紋理尺寸上限都是 4096×4096，更詳細(xì)的資料可以看這里：iosres.com。所以，盡量不要讓圖片和視圖的大小超過(guò)這個(gè)值。

\color{red}{視圖混合 (Composing)}

當(dāng)多個(gè)視圖（或者說(shuō) CALayer）重疊在一起顯示時(shí)，GPU 會(huì)首先把他們混合到一起。如果視圖結(jié)構(gòu)過(guò)于復(fù)雜，混合的過(guò)程也會(huì)消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次，并在不透明的視圖里標(biāo)明 opaque 屬性以避免無(wú)用的 Alpha 通道合成。當(dāng)然，這也可以用上面的方法，把多個(gè)視圖預(yù)先渲染為一張圖片來(lái)顯示。

\color{red}{圖形的生成}

CALayer 的 border、圓角、陰影、遮罩（mask），CASharpLayer 的矢量圖形顯示，通常會(huì)觸發(fā)離屏渲染（offscreen rendering），而離屏渲染通常發(fā)生在 GPU 中。當(dāng)一個(gè)列表視圖中出現(xiàn)大量圓角的 CALayer，并且快速滑動(dòng)時(shí)，可以觀察到 GPU 資源已經(jīng)占滿，而 CPU 資源消耗很少。這時(shí)界面仍然能正常滑動(dòng)，但平均幀數(shù)會(huì)降到很低。為了避免這種情況，可以嘗試開(kāi)啟 CALayer.shouldRasterize 屬性，但這會(huì)把原本離屏渲染的操作轉(zhuǎn)嫁到 CPU 上去。對(duì)于只需要圓角的某些場(chǎng)合，也可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原本視圖上面來(lái)模擬相同的視覺(jué)效果。最徹底的解決辦法，就是把需要顯示的圖形在后臺(tái)線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。

五、UIView的繪制原理

繪制原理：首先調(diào)用[UIView setNeedsDisplay]，此時(shí)并沒(méi)有立刻發(fā)生UIView的繪制工作，接下來(lái)會(huì)調(diào)用[UIView.layer setNeedsDisplay]方法，之后會(huì)等到當(dāng)前RunLoop\color{red}{將要結(jié)束}時(shí)調(diào)用[CALayer display]，然后進(jìn)入當(dāng)前UIView真正的繪制流程。[CALayer display]內(nèi)部實(shí)現(xiàn)中有layer.delegate respondsTo@selector(displayLayer:)這個(gè)代理方法判斷是否響應(yīng)displayLayer:方法。若是代理不響應(yīng)displayLayer:方法就會(huì)進(jìn)入到系統(tǒng)繪制流程；若是代理響應(yīng)displayLayer:方法就會(huì)進(jìn)入異步繪制入口。如圖所示:

UIView的繪制原理圖
  • 系統(tǒng)繪制流程
系統(tǒng)繪制流程圖
  • 異步繪制

實(shí)現(xiàn)-[layer.delegate displayLayer]方法就會(huì)進(jìn)入異步繪制。在異步繪制流程的過(guò)程當(dāng)中就需要1.代理負(fù)責(zé)生成對(duì)應(yīng)的bitmap；2.設(shè)置該bitmap作為layer.contents屬性的設(shè)置。

異步繪制流程圖

六、離屏渲染

  • On-Screen Rendering

在屏渲染：指的是\color{red}{GPU}的渲染操作是在當(dāng)前用于顯示的屏幕緩沖區(qū)中進(jìn)行。

  • Off-Screen Rendering

離屏渲染：指的是\color{red}{GPU}在當(dāng)前屏幕緩沖區(qū)以外\color{red}{新開(kāi)辟}一個(gè)緩沖區(qū)進(jìn)行渲染操作。

1.為什么離屏渲染耗性能？
在進(jìn)行離屏渲染時(shí)，首選需要新開(kāi)辟一個(gè)緩沖區(qū)，屏幕渲染會(huì)有一個(gè)上下文環(huán)境的概念，離屏渲染的整個(gè)過(guò)程需要切換上下文環(huán)境，先從當(dāng)前屏幕切換到離屏，等結(jié)束后又要將上下文環(huán)境切換回來(lái)，這就是離屏渲染消耗性能的原因。

2.為什么有離屏渲染這套機(jī)制呢?
因?yàn)樵谠O(shè)置視圖的圖層屬性圓角，陰影，遮罩的時(shí)候，圖層屬性的混合體被指定為在未預(yù)合成之前(下一個(gè)VSync信號(hào)開(kāi)始前)不能直接在屏幕中繪制，所以就需要屏幕外渲染。

3.哪些操作會(huì)觸發(fā)離屏渲染?
官方公開(kāi)的的資料里關(guān)于離屏渲染的信息最早是在 2011年的 WWDC，在多個(gè) session 里都提到了盡量避免會(huì)觸發(fā)離屏渲染的效果，包括：
1.mask, shadow, group opacity, edge antialiasing。
2.shouldRasterize（光柵化）： 將圖轉(zhuǎn)化為一個(gè)個(gè)柵格組成的圖象。 光柵化特點(diǎn)：每個(gè)元素對(duì)應(yīng)幀緩沖區(qū)中的一像素。
3.masks（遮罩）是layer的一個(gè)屬性.
4.shadows（陰影）
5.edge antialiasing（抗鋸齒）
6.group opacity（不透明）
7.復(fù)雜形狀設(shè)置圓角等
8.漸變
9.Text（UILabel, CATextLayer, Core Text, etc）

寫(xiě)這篇文章目的主要是當(dāng)做開(kāi)發(fā)筆記，當(dāng)中有的內(nèi)容是在其他文章中看到的，打算分享一下，大家可以參考一下。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容