本文內(nèi)容系全文轉(zhuǎn)載自微信開發(fā)團隊的《iOS 事件處理機制與圖像渲染過程》
目錄
iOS 事件處理機制與圖像渲染過程
1、iOS RunLoop都干了什么
2、iOS 為什么必須在主線程中操作UI
3、事件響應(yīng)
4、CALayer
5、CADisplayLink 和 NSTimer
6、iOS 渲染過程
7、渲染時機
8、CPU 和 GPU渲染
9、Core Animation
10、Facebook Pop介紹
11、AsyncDisplay介紹
12、參考文章
一、iOS RunLoop都干了什么
RunLoop是一個接收處理異步消息事件的循環(huán)，一個循環(huán)中：等待事件發(fā)生，然后將這個事件送到能處理它的地方。
1、如圖1-1所示，描述了一個觸摸事件從操作系統(tǒng)層傳送到應(yīng)用內(nèi)的main runloop中的簡單過程。
2、簡單的說，RunLoop是事件驅(qū)動的一個大循環(huán)，如下代碼所示
int main(int argc, char * argv[]) {
//程序一直運行狀態(tài)
while (AppIsRunning) {
//睡眠狀態(tài)，等待喚醒事件
id whoWakesMe = SleepForWakingU p();
//得到喚醒事件
id event = GetEvent(whoWakesMe);
//開始處理事件
HandleEvent(event);
}
return 0;
}
3、RunLoop主要處理以下6類事件：
static void __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__();
static void __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__();
1、Observer事件，runloop中狀態(tài)變化時進行通知。（微信卡頓監(jiān)控就是利用這個事件通知來記錄下最近一次main runloop活動時間，在另一個check線程中用定時器檢測當前時間距離最后一次活動時間過久來判斷在主線程中的處理邏輯耗時和卡主線程）。這里還需要特別注意，CAAnimation是由RunloopObserver觸發(fā)回調(diào)來重繪，接下來會講到。
2、Block事件，非延遲的NSObject PerformSelector立即調(diào)用，非延遲的dispatch_after立即調(diào)用，block回調(diào)。
3、Main_Dispatch_Queue事件：GCD中 dispatch 到main queue的block會被dispatch到main loop執(zhí)行。
4、Timer事件：延遲的NSObject PerformSelector，延遲的dispatch_after，timer事件。
5、Source0事件：處理如UIEvent，CFSocket這類事件。需要手動觸發(fā)。觸摸事件其實是Source1接收系統(tǒng)事件后在回調(diào) __IOHIDEventSystemClientQueueCallback() 內(nèi)觸發(fā)的 Source0，Source0 再觸發(fā)的 _UIApplicationHandleEventQueue()。source0一定是要喚醒runloop及時響應(yīng)并執(zhí)行的，如果runloop此時在休眠等待系統(tǒng)的 mach_msg 事件，那么就會通過source1來喚醒runloop執(zhí)行。
6、Source1事件：處理系統(tǒng)內(nèi)核的mach_msg事件。（推測CADisplayLink也是這里觸發(fā)）。
4、RunLoop執(zhí)行順序的偽代碼
SetupThisRunLoopRunTimeoutTimer(); // by GCD timer
//通知即將進入runloop__CFRUNLLOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(KCFRunLoopEntry);
do {
__CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
__CFRunLoopDoObservers(kCFRunLoopBeforeSources);
__CFRunLoopDoBlocks(); //一個循環(huán)中會調(diào)用兩次，確保非延遲的NSObject PerformSelector調(diào)用和非延遲的dispatch_after調(diào)用在當前runloop執(zhí)行。還有回調(diào)block
__CFRunLoopDoSource0(); //例如UIKit處理的UIEvent事件
CheckIfExistMessagesInMainDispatchQueue(); //GCD dispatch main queue
__CFRunLoopDoObservers(kCFRunLoopBeforeWaiting); //即將進入休眠，會重繪一次界面
var wakeUpPort = SleepAndWaitForWakingUpPorts();
// mach_msg_trap，陷入內(nèi)核等待匹配的內(nèi)核mach_msg事件
// Zzz...
// Received mach_msg, wake up
__CFRunLoopDoObservers(kCFRunLoopAfterWaiting);
// Handle msgs
if (wakeUpPort == timerPort) {
__CFRunLoopDoTimers();
} else if (wakeUpPort == mainDispatchQueuePort) {
//GCD當調(diào)用dispatch_async(dispatch_get_main_queue(),block)時，libDispatch會向主線程的runloop發(fā)送mach_msg消息喚醒runloop，并在這里執(zhí)行。這里僅限于執(zhí)行dispatch到主線程的任務(wù)，dispatch到其他線程的仍然是libDispatch來處理。
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()
} else {
__CFRunLoopDoSource1(); //CADisplayLink是source1的mach_msg觸發(fā)？
}
__CFRunLoopDoBlocks();
} while (!stop && !timeout);
//通知observers，即將退出runloop
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBERVER_CALLBACK_FUNCTION__(CFRunLoopExit);
結(jié)合上面的Runloop事件執(zhí)行順序，思考下面代碼邏輯中為什么可以標識tableview是否reload完成
dispatch_async(dispatch_get_main_queue(), ^{
_isReloadDone = NO;
[tableView reload]; //會自動設(shè)置tableView layoutIfNeeded為YES，意味著將會在runloop結(jié)束時重繪table
dispatch_async(dispatch_get_main_queue(),^{
_isReloadDone = YES;
});
});
提示：這里在GCD dispatch main queue中插入了兩個任務(wù)，一次RunLoop有兩個機會執(zhí)行GCD dispatch main queue中的任務(wù)，分別在休眠前和被喚醒后。
二、iOS 為什么必須在主線程中操作UI
因為UIKit不是線程安全的。試想下面這幾種情況：
1、兩個線程同時設(shè)置同一個背景圖片，那么很有可能因為當前圖片被釋放了兩次而導(dǎo)致應(yīng)用崩潰。
2、兩個線程同時設(shè)置同一個UIView的背景顏色，那么很有可能渲染顯示的是顏色A，而此時在UIView邏輯樹上的背景顏色屬性為B。
3、兩個線程同時操作view的樹形結(jié)構(gòu)：在線程A中for循環(huán)遍歷并操作當前View的所有subView，然后此時線程B中將某個subView直接刪除，這就導(dǎo)致了錯亂還可能導(dǎo)致應(yīng)用崩潰。
iOS4之后蘋果將大部分繪圖的方法和諸如 UIColor 和 UIFont 這樣的類改寫為了線程安全可用，但是仍然強烈建議講UI操作保證在主線程中執(zhí)行。
三、事件響應(yīng)
蘋果注冊了一個 Source1 (基于 mach port 的) 用來接收系統(tǒng)事件，其回調(diào)函數(shù)為 __IOHIDEventSystemClientQueueCallback()。
當一個硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后，首先由 IOKit.framework 生成一個 IOHIDEvent 事件并由 SpringBoard 接收。
SpringBoard 只接收按鍵(鎖屏/靜音等)，觸摸，加速，接近傳感器等幾種 Event，隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進程。隨后蘋果注冊的那個 Source1 就會觸發(fā)回調(diào)，并調(diào)用 _UIApplicationHandleEventQueue() 進行應(yīng)用內(nèi)部的分發(fā)。
_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理并包裝成 UIEvent 進行處理或分發(fā)，其中包括識別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等。通常事件比如 UIButton 點擊、touchesBegin/Move/End/Cancel 事件都是在這個回調(diào)中完成的。
四、CALayer
在iOS當中，所有的視圖都從一個叫做UIVIew的基類派生而來，UIView可以處理觸摸事件，可以支持基于Core Graphics繪圖，可以做仿射變換（例如旋轉(zhuǎn)或者縮放），或者簡單的類似于滑動或者漸變的動畫。
CALayer類在概念上和UIView類似，同樣也是一些被層級關(guān)系樹管理的矩形塊，同樣也可以包含一些內(nèi)容（像圖片，文本或者背景色），管理子圖層的位置。它們有一些方法和屬性用來做動畫和變換。和UIView最大的不同是CALayer不處理用戶的交互。CALayer并不清楚具體的響應(yīng)鏈。
UIView和CALayer是一個平行的層級關(guān)系，每一個UIView都有一個CALayer實例的圖層屬性，也就是所謂的backing layer，視圖的職責就是創(chuàng)建并管理這個圖層，以確保當子視圖在層級關(guān)系中添加或者被移除的時候，他們關(guān)聯(lián)的圖層也同樣對應(yīng)在層級關(guān)系樹當中有相同的操作。實際上這些背后關(guān)聯(lián)的Layer圖層才是真正用來在屏幕上顯示和做動畫，UIView僅僅是對它的一個封裝，提供了一些iOS類似于處理觸摸的具體功能，以及Core Animation底層方法的高級接口。
UIView 的 Layer 在系統(tǒng)內(nèi)部，被維護著三份同樣的樹形數(shù)據(jù)結(jié)構(gòu)，分別是：
1、圖層樹（這里是代碼可以操縱的，設(shè)置屬性的最終值會立刻在這里更新）；
2、呈現(xiàn)樹（是一個中間層，系統(tǒng)就在這一層上更改屬性，進行各種渲染操作。比如一個動畫是更改alpha值從0到1，那么在邏輯樹上此屬性會被立刻更新為最終屬性1，而在動畫樹上會根據(jù)設(shè)置的動畫時間從0逐步變化到1）；
3、渲染樹（其屬性值就是當前正被顯示在屏幕上的屬性值）；
五、CADisplayLink 和 NSTimer
NSTimer 其實就是 CFRunLoopTimerRef。一個 NSTimer 注冊到 RunLoop 后，RunLoop 會為其重復(fù)的時間點注冊好事件。
RunLoop為了節(jié)省資源，并不會在非常準確的時間點回調(diào)這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后，容許有多少最大誤差。如果某個時間點被錯過了，例如執(zhí)行了一個很長的任務(wù)，則那個時間點的回調(diào)也會跳過去，不會延后執(zhí)行。
RunLoop 是用GCD的 dispatch_source_t 實現(xiàn)的 Timer。 當調(diào)用 NSObject 的 performSelecter:afterDelay: 后，實際上其內(nèi)部會創(chuàng)建一個 Timer 并添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，則這個方法會失效。當調(diào)用 performSelector:onThread: 時，實際上其會創(chuàng)建一個 Timer 加到對應(yīng)的線程去，同樣的，如果對應(yīng)線程沒有 RunLoop 該方法也會失效。
CADisplayLink 是一個和屏幕刷新率（每秒刷新60次）一致的定時器（但實際實現(xiàn)原理更復(fù)雜，和 NSTimer 并不一樣，其內(nèi)部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執(zhí)行了一個長任務(wù)，那其中就會有一幀被跳過去，造成界面卡頓的感覺。
六、iOS 渲染過程
通常來說，計算機系統(tǒng)中 CPU、GPU、顯示器是以上面這種方式協(xié)同工作的。CPU 計算好顯示內(nèi)容提交到 GPU，GPU 渲染完成后將渲染結(jié)果放入幀緩沖區(qū)，隨后視頻控制器會按照 VSync 信號如下圖1-4所示，逐行讀取幀緩沖區(qū)的數(shù)據(jù)，經(jīng)過可能的數(shù)模轉(zhuǎn)換傳遞給顯示器顯示。
在 VSync 信號到來后，系統(tǒng)圖形服務(wù)會通過 CADisplayLink 等機制通知 App，App 主線程開始在 CPU 中計算顯示內(nèi)容，比如視圖的創(chuàng)建、布局計算、圖片解碼、文本繪制等。隨后 CPU 會將計算好的內(nèi)容提交到 GPU 去，由 GPU 進行變換、合成、渲染。隨后 GPU 會把渲染結(jié)果提交到幀緩沖區(qū)去，等待下一次 VSync 信號到來時顯示到屏幕上。由于垂直同步的機制，如果在一個 VSync 時間內(nèi)，CPU 或者 GPU 沒有完成內(nèi)容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏?xí)Ａ糁暗膬?nèi)容不變。這就是界面卡頓的原因。從上圖中可以看到，CPU 和 GPU 不論哪個阻礙了顯示流程，都會造成掉幀現(xiàn)象。所以開發(fā)時，也需要分別對 CPU 和 GPU 壓力進行評估和優(yōu)化。
iOS 的顯示系統(tǒng)是由 VSync 信號驅(qū)動的，VSync 信號由硬件時鐘生成，每秒鐘發(fā)出 60 次（這個值取決設(shè)備硬件，比如 iPhone 真機上通常是 59.97）。iOS 圖形服務(wù)接收到 VSync 信號后，會通過 IPC 通知到 App 內(nèi)。App 的 Runloop 在啟動后會注冊對應(yīng)的 CFRunLoopSource 通過 mach_port 接收傳過來的時鐘信號通知，隨后 Source 的回調(diào)會驅(qū)動整個 App 的動畫與顯示。
Core Animation 在 RunLoop 中注冊了一個 Observer，監(jiān)聽了 BeforeWaiting 和 Exit 事件。當一個觸摸事件到來時，RunLoop 被喚醒，App 中的代碼會執(zhí)行一些操作，比如創(chuàng)建和調(diào)整視圖層級、設(shè)置 UIView 的 frame、修改 CALayer 的透明度、為視圖添加一個動畫；這些操作最終都會被 CALayer 標記，并通過 CATransaction 提交到一個中間狀態(tài)去。當上面所有操作結(jié)束后，RunLoop 即將進入休眠（或者退出）時，關(guān)注該事件的 Observer 都會得到通知。這時 Core Animation 注冊的那個 Observer 就會在回調(diào)中，把所有的中間狀態(tài)合并提交到 GPU 去顯示；如果此處有動畫，通過 DisplayLink 穩(wěn)定的刷新機制會不斷的喚醒runloop，使得不斷的有機會觸發(fā)observer回調(diào)，從而根據(jù)時間來不斷更新這個動畫的屬性值并繪制出來。
為了不阻塞主線程，Core Animation 的核心是 OpenGL ES 的一個抽象物，所以大部分的渲染是直接提交給GPU來處理。 而Core Graphics/Quartz 2D的大部分繪制操作都是在主線程和CPU上同步完成的，比如自定義UIView的drawRect里用CGContext來畫圖。
七、渲染時機
上面已經(jīng)提到過：Core Animation 在 RunLoop 中注冊了一個 Observer 監(jiān)聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件 。當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個 UIView/CALayer 就被標記為待處理，并被提交到一個全局的容器去。當Oberver監(jiān)聽的事件到來時，回調(diào)執(zhí)行函數(shù)中會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實際的繪制和調(diào)整，并更新 UI 界面。
這個函數(shù)內(nèi)部的調(diào)用棧大概是這樣的：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
QuartzCore:CA::Transaction::observer_callback:
CA::Transaction::commit();
CA::Context::commit_transaction();
CA::Layer::layout_and_display_if_needed();
CA::Layer::layout_if_needed();
[CALayer layoutSublayers];
[UIView layoutSubviews];
CA::Layer::display_if_needed();
[CALayer display];
[UIView drawRect];
八、CPU 和 GPU渲染
OpenGL中，GPU屏幕渲染有以下兩種方式：
1、On-Screen Rendering
意為當前屏幕渲染，指的是GPU的渲染操作是在當前用于顯示的屏幕緩沖區(qū)中進行。
2、Off-Screen Rendering
意為離屏渲染，指的是GPU在當前屏幕緩沖區(qū)以外新開辟一個緩沖區(qū)進行渲染操作。
按照這樣的說法，如果將不在GPU的當前屏幕緩沖區(qū)中進行的渲染都稱為離屏渲染，那么就還有另一種特殊的“離屏渲染”方式：CPU渲染。如果我們重寫了drawRect方法，并且使用任何Core Graphics的技術(shù)進行了繪制操作，就涉及到了CPU渲染。整個渲染過程由CPU在App內(nèi)同步地完成，渲染得到的bitmap最后再交由GPU用于顯示。
相比于當前屏幕渲染，離屏渲染的代價是很高的，主要體現(xiàn)在兩個方面：
1、創(chuàng)建新緩沖區(qū)
要想進行離屏渲染，首先要創(chuàng)建一個新的緩沖區(qū)。
2、上下文切換
離屏渲染的整個過程，需要多次切換上下文環(huán)境：先是從當前屏幕（On-Screen）切換到離屏（Off-Screen）；等到離屏渲染結(jié)束以后，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上有需要將上下文環(huán)境從離屏切換到當前屏幕。而上下文環(huán)境的切換是要付出很大代價的。
設(shè)置了以下屬性時，都會觸發(fā)離屏繪制：
1、shouldRasterize（光柵化）
2、masks（遮罩）
3、shadows（陰影）
4、edge antialiasing（抗鋸齒）
5、group opacity（不透明）
需要注意的是，如果shouldRasterize被設(shè)置成YES，在觸發(fā)離屏繪制的同時，會將光柵化后的內(nèi)容緩存起來，如果對應(yīng)的layer及其sublayers沒有發(fā)生改變，在下一幀的時候可以直接復(fù)用。這將在很大程度上提升渲染性能。
而其它屬性如果是開啟的，就不會有緩存，離屏繪制會在每一幀都發(fā)生。
在開發(fā)時需要根據(jù)實際情況來選擇最優(yōu)的實現(xiàn)方式，盡量使用On-Screen Rendering。簡單的Off-Screen Rendering可以考慮使用Core Graphics讓CPU來渲染。
九、Core Animation
1. 隱式動畫
隱式動畫是系統(tǒng)框架自動完成的。Core Animation在每個runloop周期中自動開始一次新的事務(wù)，即使你不顯式的用[CATransaction begin]開始一次事務(wù)，任何在一次runloop循環(huán)中屬性的改變都會被集中起來，然后做一次0.25秒的動畫。
在iOS4中，蘋果對UIView添加了一種基于block的動畫方法：+animateWithDuration:animations:。
這樣寫對做一堆的屬性動畫在語法上會更加簡單，但實質(zhì)上它們都是在做同樣的事情。
CATransaction的+begin和+commit方法在+animateWithDuration:animations:內(nèi)部自動調(diào)用，這樣block中所有屬性的改變都會被事務(wù)所包含。
Core Animation通常對CALayer的所有屬性（可動畫的屬性）做動畫，但是UIView是怎么把它關(guān)聯(lián)的圖層的這個特性關(guān)閉了呢？
每個UIView對它關(guān)聯(lián)的圖層都扮演了一個委托，并且提供了-actionForLayer:forKey的實現(xiàn)方法。當不在一個動畫塊的實現(xiàn)中，UIView對所有圖層行為返回nil，但是在動畫block范圍之內(nèi)，它就返回了一個非空值。
@interface ViewController ()
@property (nonatomic, weak) IBOutlet UIView *layerView;
@end
@implementation ViewController
- (void)viewDidLoad
{
[super viewDidLoad];
//test layer action when outside of animation block
NSLog(@"Outside: %@", [self.layerView actionForLayer:self.layerView.layer forKey:@"backgroundColor"]);
//begin animation block
[UIView beginAnimations:nil context:nil];
//test layer action when inside of animation block
NSLog(@"Inside: %@", [self.layerView actionForLayer:self.layerView.layer forKey:@"backgroundColor"]);
//end animation block
[UIView commitAnimations];
}
@end
$ LayerTest[21215:c07] Outside: <null>
$ LayerTest[21215:c07] Inside: <CABasicAnimation: 0x757f090>
2. 顯式動畫
Core Animation提供的顯式動畫類型，既可以直接對圖層屬性做動畫，也可以覆蓋默認的圖層行為。
我們經(jīng)常使用的CABasicAnimation，CAKeyframeAnimation，CATransitionAnimation，CAAnimationGroup等都是顯式動畫類型，這些CAAnimation類型可以直接提交到CALayer上。
無論是隱式動畫還是顯式動畫，提交到layer后，經(jīng)過一系列處理，最后都經(jīng)過上文描述的繪制過程最終被渲染出來。
十、Facebook Pop介紹
在計算機的世界里面，其實并不存在絕對連續(xù)的動畫，你所看到的屏幕上的動畫本質(zhì)上都是離散的，只是在一秒的時間里面離散的幀多到一定的數(shù)量人眼就覺得是連續(xù)的了，
在iOS中，最大的幀率是60幀每秒。 iOS提供了Core Animation框架，只需要開發(fā)者提供關(guān)鍵幀信息，比如提供某個animatable屬性終點的關(guān)鍵幀信息，然后中間的值則通過一定的算法進行插值計算，從而實現(xiàn)補間動畫。 Core Aniamtion中進行插值計算所依賴的時間曲線由CAMediaTimingFunction提供。
Pop Animation在使用上和Core Animation很相似，都涉及Animation對象以及Animation的載體的概念，不同的是Core Animation的載體只能是CALayer，而Pop Animation可以是任意基于NSObject的對象。當然大多數(shù)情況Animation都是界面上顯示的可視的效果，所以動畫執(zhí)行的載體一般都直接或者間接是UIView或者CALayer。
但是如果你只是想研究Pop Animation的變化曲線，你也完全可以將其應(yīng)用于一個普通的數(shù)據(jù)對象。Pop Animation應(yīng)用于CALayer時，在動畫運行的任何時刻，layer和其presentationLayer的相關(guān)屬性值始終保持一致，而Core Animation做不到。 Pop Animation可以應(yīng)用任何NSObject的對象，而Core Aniamtion必須是CALayer。
下面這個例子就是自定義Pop readBlock和writeBlock處理自定義的動畫屬性：
prop = [POPAnimatableProperty propertyWithName:@"com.foo.radio.volume" initializer:^(POPMutableAnimatableProperty *prop) {
// read value
prop.readBlock = ^(id obj, CGFloat values[]) {
values[0] = [obj volume];
};
// write value
prop.writeBlock = ^(id obj, const CGFloat values[]) {
[obj setVolume:values[0]];
};
// dynamics threshold
prop.threshold = 0.01;
}];
POPSpringAnimation *anim = [POPSpringAnimation animation];
anim.property = prop;
Pop實現(xiàn)依賴的核心就是CADisplayLink。
十一、AsyncDisplay介紹
阻塞主線程的繪制任務(wù)主要是這三大類：Layout計算視圖布局文本寬高、Rendering文本渲染圖片解碼圖片繪制、UIKit對象創(chuàng)建更新釋放。除了UIKit和CoreAnimation相關(guān)操作必須在主線程中進行，其他的都可以挪到后臺線程異步執(zhí)行。
AsyncDisplay通過抽象UIView的關(guān)系創(chuàng)建了ASDisplayNode類，ASDisplayNode是線程安全的，它可以在后臺線程創(chuàng)建和修改。Node 剛創(chuàng)建時，并不會在內(nèi)部新建 UIView 和 CALayer，直到第一次在主線程訪問 view 或 layer 屬性時，它才會在內(nèi)部生成對應(yīng)的對象。當它的屬性（比如frame/transform）改變后，它并不會立刻同步到其持有的 view 或 layer 去，而是把被改變的屬性保存到內(nèi)部的一個中間變量，稍后在需要時，再通過某個機制一次性設(shè)置到內(nèi)部的 view 或 layer。從而可以實現(xiàn)異步并發(fā)操作。
AsyncDisplay實現(xiàn)依賴如同Core Animation在runloop中注冊observer事件來觸發(fā)。
同樣附上一篇介紹AsyncDisplay的好文 《iOS保持界面流暢的技巧和AsyncDisplay介紹》
十二、參考文章
runloop原理
深入理解runloop
線程安全類的設(shè)計
iOS保持界面流暢的技巧和AsyncDisplay介紹
離屏渲染
iOS核心動畫高級技巧
