一般來講则涯，一個(gè)線程一次只能執(zhí)行一個(gè)任務(wù)复局，執(zhí)行完成后線程就會退出。如果我們需要一個(gè)機(jī)制粟判，讓線程能隨時(shí)處理事件但并不退出亿昏，通常的代碼邏輯 是這樣的：
function loop() {
initialize();
do {
var message = get_next_message();
process_message(message);
} while (message != quit);
}
或使用偽代碼來展示下:
//
// http://weibo.com/luohanchenyilong/ (微博@iOS程序犭袁)
// https://github.com/ChenYilong
int main(int argc, char * argv[]) {
//程序一直運(yùn)行狀態(tài)
while (AppIsRunning) {
//睡眠狀態(tài)，等待喚醒事件
id whoWakesMe = SleepForWakingUp();
//得到喚醒事件
id event = GetEvent(whoWakesMe);
//開始處理事件
HandleEvent(event);
}
return 0;
}
其內(nèi)容運(yùn)行的邏輯大致如圖所示：
可以看到档礁，實(shí)際上 RunLoop 就是這樣一個(gè)函數(shù)角钩，其內(nèi)部是一個(gè) do-while 循環(huán)。當(dāng)你調(diào)用 CFRunLoopRun() 時(shí)呻澜，線程就會一直停留在這個(gè)循環(huán)里递礼；直到超時(shí)或被手動停止，該函數(shù)才會返回羹幸。
首先我們可以看一下 App 啟動后 RunLoop 的狀態(tài)：
CFRunLoop {
current mode = kCFRunLoopDefaultMode
common modes = {
UITrackingRunLoopMode
kCFRunLoopDefaultMode
}
common mode items = {
// source0 (manual)
CFRunLoopSource {order =-1, {
callout = _UIApplicationHandleEventQueue}}
CFRunLoopSource {order =-1, {
callout = PurpleEventSignalCallback }}
CFRunLoopSource {order = 0, {
callout = FBSSerialQueueRunLoopSourceHandler}}
// source1 (mach port)
CFRunLoopSource {order = 0, {port = 17923}}
CFRunLoopSource {order = 0, {port = 12039}}
CFRunLoopSource {order = 0, {port = 16647}}
CFRunLoopSource {order =-1, {
callout = PurpleEventCallback}}
CFRunLoopSource {order = 0, {port = 2407,
callout = _ZL20notify_port_callbackP12__CFMachPortPvlS1_}}
CFRunLoopSource {order = 0, {port = 1c03,
callout = __IOHIDEventSystemClientAvailabilityCallback}}
CFRunLoopSource {order = 0, {port = 1b03,
callout = __IOHIDEventSystemClientQueueCallback}}
CFRunLoopSource {order = 1, {port = 1903,
callout = __IOMIGMachPortPortCallback}}
// Ovserver
CFRunLoopObserver {order = -2147483647, activities = 0x1, // Entry
callout = _wrapRunLoopWithAutoreleasePoolHandler}
CFRunLoopObserver {order = 0, activities = 0x20, // BeforeWaiting
callout = _UIGestureRecognizerUpdateObserver}
CFRunLoopObserver {order = 1999000, activities = 0xa0, // BeforeWaiting | Exit
callout = _afterCACommitHandler}
CFRunLoopObserver {order = 2000000, activities = 0xa0, // BeforeWaiting | Exit
callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}
CFRunLoopObserver {order = 2147483647, activities = 0xa0, // BeforeWaiting | Exit
callout = _wrapRunLoopWithAutoreleasePoolHandler}
// Timer
CFRunLoopTimer {firing = No, interval = 3.1536e+09, tolerance = 0,
next fire date = 453098071 (-4421.76019 @ 96223387169499),
callout = _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv (QuartzCore.framework)}
},
modes ＝ {
CFRunLoopMode {
sources0 = { /* same as 'common mode items' */ },
sources1 = { /* same as 'common mode items' */ },
observers = { /* same as 'common mode items' */ },
timers = { /* same as 'common mode items' */ },
},
CFRunLoopMode {
sources0 = { /* same as 'common mode items' */ },
sources1 = { /* same as 'common mode items' */ },
observers = { /* same as 'common mode items' */ },
timers = { /* same as 'common mode items' */ },
},
CFRunLoopMode {
sources0 = {
CFRunLoopSource {order = 0, {
callout = FBSSerialQueueRunLoopSourceHandler}}
},
sources1 = (null),
observers = {
CFRunLoopObserver >{activities = 0xa0, order = 2000000,
callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}
)},
timers = (null),
},
CFRunLoopMode {
sources0 = {
CFRunLoopSource {order = -1, {
callout = PurpleEventSignalCallback}}
},
sources1 = {
CFRunLoopSource {order = -1, {
callout = PurpleEventCallback}}
},
observers = (null),
timers = (null),
},
CFRunLoopMode {
sources0 = (null),
sources1 = (null),
observers = (null),
timers = (null),
}
}
}
可以看到脊髓，系統(tǒng)默認(rèn)注冊了 5 個(gè) Mode：
- 1、kCFRunLoopDefaultMode: App的默認(rèn) Mode栅受，通常主線程是在這個(gè) Mode 下運(yùn)行的将硝。
- 2、UITrackingRunLoopMode: 界面跟蹤 Mode屏镊，用于 ScrollView 追蹤觸摸滑動依疼，保證界面滑動時(shí)不受其他 Mode 影響。
- 3闸衫、UIInitializationRunLoopMode: 在剛啟動 App 時(shí)第進(jìn)入的第一個(gè) Mode涛贯，啟動完成后就不再使用。
- 4蔚出、GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部 Mode弟翘，通常用不到。
- 5骄酗、kCFRunLoopCommonModes: 這是一個(gè)占位的 Mode稀余，沒有實(shí)際作用。
當(dāng) RunLoop 進(jìn)行回調(diào)時(shí)趋翻，一般都是通過一個(gè)很長的函數(shù)調(diào)用出去 (call out), 當(dāng)你在你的代碼中下斷點(diǎn)調(diào)試時(shí)睛琳，通常能在調(diào)用棧上看到這些函數(shù)。下面是這幾個(gè)函數(shù)的整理版本踏烙，如果你在調(diào)用棧中看到這些長函數(shù)名师骗，在這里查找一下就能定位到具體的調(diào)用地點(diǎn)了：
{
/// 1\. 通知Observers，即將進(jìn)入RunLoop
/// 此處有Observer會創(chuàng)建AutoreleasePool: _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
do {
/// 2\. 通知 Observers: 即將觸發(fā) Timer 回調(diào)讨惩。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
/// 3\. 通知 Observers: 即將觸發(fā) Source (非基于port的,Source0) 回調(diào)辟癌。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 4\. 觸發(fā) Source0 (非基于port的) 回調(diào)。
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 6\. 通知Observers荐捻，即將進(jìn)入休眠
/// 此處有Observer釋放并新建AutoreleasePool: _objc_autoreleasePoolPop(); _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeWaiting);
/// 7\. sleep to wait msg.
mach_msg() -> mach_msg_trap();
/// 8\. 通知Observers黍少，線程被喚醒
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopAfterWaiting);
/// 9\. 如果是被Timer喚醒的，回調(diào)Timer
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
/// 9\. 如果是被dispatch喚醒的处面，執(zhí)行所有調(diào)用 dispatch_async 等方法放入main queue 的 block
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block);
/// 9\. 如果如果Runloop是被 Source1 (基于port的) 的事件喚醒了厂置，處理這個(gè)事件
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__(source1);
} while (...);
/// 10\. 通知Observers，即將退出RunLoop
/// 此處有Observer釋放AutoreleasePool: _objc_autoreleasePoolPop();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopExit);
}
幾個(gè)相關(guān)特性的實(shí)現(xiàn)：
幾個(gè)相關(guān)特性的實(shí)現(xiàn)：
AutoreleasePool
App啟動后魂角，蘋果在主線程 RunLoop 里注冊了兩個(gè) Observer昵济，其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()。
第一個(gè) Observer 監(jiān)視的事件是 Entry(即將進(jìn)入 Loop)野揪，其回調(diào)內(nèi)會調(diào)用 _objc_autoreleasePoolPush()創(chuàng)建自動釋放池访忿。其 order 是-2147483647，優(yōu)先級最高囱挑，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前醉顽。
第二個(gè) Observer 監(jiān)視了兩個(gè)事件： BeforeWaiting(準(zhǔn)備進(jìn)入休眠) 時(shí)調(diào)用_objc_autoreleasePoolPop()和 _objc_autoreleasePoolPush()釋放舊的池并創(chuàng)建新池；Exit(即將退出 Loop) 時(shí)調(diào)用 _objc_autoreleasePoolPop()來釋放自動釋放池平挑。這個(gè) Observer 的 order 是 2147483647游添，優(yōu)先級最低，保證其釋放池子發(fā)生在其他所有回調(diào)之后通熄。
在主線程執(zhí)行的代碼唆涝，通常是寫在諸如事件回調(diào)、Timer 回調(diào)內(nèi)的唇辨。這些回調(diào)會被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著廊酣，所以不會出現(xiàn)內(nèi)存泄漏，開發(fā)者也不必顯示創(chuàng)建 Pool 了赏枚。
事件響應(yīng)
蘋果注冊了一個(gè) Source1 (基于 mach port 的) 用來接收系統(tǒng)事件亡驰，其回調(diào)函數(shù)為 __IOHIDEventSystemClientQueueCallback()晓猛。
當(dāng)一個(gè)硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后，首先由 IOKit.framework 生成一個(gè) IOHIDEvent 事件并由 SpringBoard 接收凡辱。這個(gè)過程的詳細(xì)情況可以參考這里戒职。SpringBoard 只接收按鍵(鎖屏/靜音等)，觸摸透乾，加速洪燥，接近傳感器等幾種 Event，隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進(jìn)程乳乌。隨后蘋果注冊的那個(gè) Source1 就會觸發(fā)回調(diào)捧韵，并調(diào)用 _UIApplicationHandleEventQueue() 進(jìn)行應(yīng)用內(nèi)部的分發(fā)。
_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理并包裝成 UIEvent 進(jìn)行處理或分發(fā)汉操，其中包括識別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等再来。通常事件比如 UIButton 點(diǎn)擊、touchesBegin/Move/End/Cancel 事件都是在這個(gè)回調(diào)中完成的客情。
手勢識別
當(dāng)上面的 _UIApplicationHandleEventQueue() 識別了一個(gè)手勢時(shí)其弊，其首先會調(diào)用 Cancel 將當(dāng)前的 touchesBegin/Move/End 系列回調(diào)打斷。隨后系統(tǒng)將對應(yīng)的 UIGestureRecognizer 標(biāo)記為待處理膀斋。
蘋果注冊了一個(gè) Observer 監(jiān)測 BeforeWaiting (Loop 即將進(jìn)入休眠) 事件梭伐，這個(gè) Observer 的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()，其內(nèi)部會獲取所有剛被標(biāo)記為待處理的 GestureRecognizer仰担，并執(zhí)行 GestureRecognizer 的回調(diào)糊识。
當(dāng)有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時(shí)，這個(gè)回調(diào)都會進(jìn)行相應(yīng)處理摔蓝。
界面更新
當(dāng)在操作 UI 時(shí)赂苗，比如改變了 Frame、更新了 UIView/CALayer 的層次時(shí)贮尉，或者手動調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后拌滋，這個(gè) UIView/CALayer 就被標(biāo)記為待處理，并被提交到一個(gè)全局的容器去猜谚。
蘋果注冊了一個(gè) Observer 監(jiān)聽 BeforeWaiting(即將進(jìn)入休眠) 和 Exit (即將退出 Loop) 事件败砂，回調(diào)去執(zhí)行一個(gè)很長的函數(shù)： _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個(gè)函數(shù)里會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實(shí)際的繪制和調(diào)整魏铅，并更新 UI 界面昌犹。
這個(gè)函數(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];
定時(shí)器
NSTimer 其實(shí)就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的览芳。NSTimer 是用了 XNU 內(nèi)核的 mk_timer 驅(qū)動斜姥，而非 GCD 驅(qū)動的。
一個(gè) NSTimer 注冊到 RunLoop 后，RunLoop 會為其重復(fù)的時(shí)間點(diǎn)注冊好事件铸敏。例如 10:00, 10:10, 10:20 這幾個(gè)時(shí)間點(diǎn)缚忧。RunLoop 為了節(jié)省資源，并不會在非常準(zhǔn)確的時(shí)間點(diǎn)回調(diào)這個(gè) Timer搞坝。Timer 有個(gè)屬性叫做 Tolerance (寬容度)搔谴，標(biāo)示了當(dāng)時(shí)間點(diǎn)到后魁袜，容許有多少最大誤差桩撮。
如果某個(gè)時(shí)間點(diǎn)被錯(cuò)過了，例如執(zhí)行了一個(gè)很長的任務(wù)峰弹，則那個(gè)時(shí)間點(diǎn)的回調(diào)也會跳過去店量，不會延后執(zhí)行。就比如等公交鞠呈，如果 10:10 時(shí)我忙著玩手機(jī)錯(cuò)過了那個(gè)點(diǎn)的公交融师，那我只能等 10:20 這一趟了矢赁。
CADisplayLink 是一個(gè)和屏幕刷新率一致的定時(shí)器（但實(shí)際實(shí)現(xiàn)原理更復(fù)雜舌缤，和 NSTimer 并不一樣，其內(nèi)部實(shí)際是操作了一個(gè) Source）冲泥。如果在兩次屏幕刷新之間執(zhí)行了一個(gè)長任務(wù)窘茁，那其中就會有一幀被跳過去（和 NSTimer 相似）怀伦，造成界面卡頓的感覺。在快速滑動 TableView時(shí)山林，即使一幀的卡頓也會讓用戶有所察覺房待。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題，其內(nèi)部也用到了 RunLoop驼抹。
PerformSelector
當(dāng)調(diào)用 NSObject 的 performSelector:afterDelay: 后桑孩，實(shí)際上其內(nèi)部會創(chuàng)建一個(gè) Timer 并添加到當(dāng)前線程的 RunLoop 中。所以如果當(dāng)前線程沒有 RunLoop框冀，則這個(gè)方法會失效流椒。
當(dāng)調(diào)用 performSelector:onThread: 時(shí)，實(shí)際上其會創(chuàng)建一個(gè) Timer 加到對應(yīng)的線程去明也，同樣的宣虾，如果對應(yīng)線程沒有 RunLoop 該方法也會失效。
關(guān)于 GCD
實(shí)際上 RunLoop 底層也會用到 GCD 的東西诡右。但同時(shí) GCD 提供的某些接口也用到了 RunLoop安岂，例如 dispatch_async()。
當(dāng)調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時(shí)帆吻，libDispatch 會向主線程的 RunLoop 發(fā)送消息域那，RunLoop 會被喚醒，并從消息中取得這個(gè) block，并在回調(diào) __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里執(zhí)行這個(gè) block次员。但這個(gè)邏輯僅限于 dispatch 到主線程败许，dispatch 到其他線程仍然是由 libDispatch 處理的。
關(guān)于網(wǎng)絡(luò)請求
iOS 中淑蔚，關(guān)于網(wǎng)絡(luò)請求的接口自下至上有如下幾層:
- CFSocket市殷，是最底層的接口，只負(fù)責(zé) socket 通信刹衫。
- CFNetwork醋寝，是基于 CFSocket 等接口的上層封裝，ASIHttpRequest 工作于這一層带迟。
- NSURLConnection音羞，是基于 CFNetwork 的更高層的封裝，提供面向?qū)ο蟮慕涌诓秩珹FNetworking 工作于這一層嗅绰。
- NSURLSession，是 iOS7 中新增的接口搀继，表面上是和 NSURLConnection 并列的窘面，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)，AFNetworking2 和 Alamofire 工作于這一層叽躯。
NSURLConnection 的工作過程：
通常使用 NSURLConnection 時(shí)财边，你會傳入一個(gè) Delegate，當(dāng)調(diào)用了 [connection start] 后险毁，這個(gè) Delegate 就會不停收到事件回調(diào)制圈。實(shí)際上，start 這個(gè)函數(shù)的內(nèi)部會會獲取 CurrentRunLoop畔况，然后在其中的 DefaultMode 添加了 4 個(gè) Source0 (即需要手動觸發(fā)的Source)鲸鹦。CFMultiplexerSource 是負(fù)責(zé)各種 Delegate 回調(diào)的，CFHTTPCookieStorage 是處理各種 Cookie 的跷跪。
當(dāng)開始網(wǎng)絡(luò)傳輸時(shí)馋嗜，我們可以看到 NSURLConnection 創(chuàng)建了兩個(gè)新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的吵瞻。NSURLConnectionLoader 這個(gè)線程內(nèi)部會使用 RunLoop 來接收底層 socket 的事件葛菇，并通過之前添加的 Source0 通知到上層的 Delegate。
NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知橡羞。當(dāng)收到通知后眯停，其會在合適的時(shí)機(jī)向 CFMultiplexerSource 等 Source0 發(fā)送通知，同時(shí)喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知卿泽。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執(zhí)行實(shí)際的回調(diào)莺债。
RunLoop 的實(shí)際應(yīng)用舉例
AFNetworking 中的 AFURLConnectionOperation這個(gè)類是基于 NSURLConnection 構(gòu)建的，其希望能在后臺線程接收 Delegate 回調(diào)。為此 AFNetworking 單獨(dú)創(chuàng)建了一個(gè)線程齐邦，并在這個(gè)線程中啟動了一個(gè) RunLoop：
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
@autoreleasepool {
[[NSThread currentThread] setName:@"AFNetworking"];
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runLoop run];
}
}
+ (NSThread *)networkRequestThread {
static NSThread *_networkRequestThread = nil;
static dispatch_once_t oncePredicate;
dispatch_once(&oncePredicate, ^{
_networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
[_networkRequestThread start];
});
return _networkRequestThread;
}
RunLoop 啟動前內(nèi)部必須要有至少一個(gè) Timer/Observer/Source椎侠，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個(gè)新的 NSMachPort 添加進(jìn)去了。通常情況下措拇，調(diào)用者需要持有這個(gè) NSMachPort (mach_port) 并在外部線程通過這個(gè) port 發(fā)送消息到 loop 內(nèi)我纪；但此處添加 port 只是為了讓 RunLoop 不至于退出，并沒有用于實(shí)際的發(fā)送消息丐吓。
當(dāng)需要這個(gè)后臺線程執(zhí)行任務(wù)時(shí)浅悉，AFNetworking 通過調(diào)用 [NSObject performSelector:onThread:..] 將這個(gè)任務(wù)扔到了后臺線程的 RunLoop 中。
AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架汰蜘，其原理大致如下：
UI 線程中一旦出現(xiàn)繁重的任務(wù)就會導(dǎo)致界面卡頓仇冯，這類任務(wù)通常分為3類：排版，繪制族操，UI對象操作。
排版通常包括計(jì)算視圖大小比被、計(jì)算文本高度色难、重新計(jì)算子式圖的排版等操作。 繪制一般有文本繪制 (例如 CoreText)等缀、圖片繪制 (例如預(yù)先解壓)枷莉、元素繪制 (Quartz)等操作。 UI對象操作通常包括 UIView/CALayer 等 UI 對象的創(chuàng)建尺迂、設(shè)置屬性和銷毀笤妙。
其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行，而最后一類操作只能在主線程完成噪裕，并且有時(shí)后面的操作需要依賴前面操作的結(jié)果 （例如TextView創(chuàng)建時(shí)可能需要提前計(jì)算出文本的大卸着獭）。ASDK 所做的膳音，就是盡量將能放入后臺的任務(wù)放入后臺召衔，不能的則盡量推遲 (例如視圖的創(chuàng)建、屬性的調(diào)整)祭陷。
為此苍凛，ASDK 創(chuàng)建了一個(gè)名為 ASDisplayNode 的對象，并在內(nèi)部封裝了 UIView/CALayer兵志，它具有和 UIView/CALayer 相似的屬性醇蝴，例如 frame、backgroundColor等想罕。所有這些屬性都可以在后臺線程更改悠栓，開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer，這樣就可以將排版和繪制放入了后臺線程。但是無論怎么操作闸迷，這些屬性總需要在某個(gè)時(shí)刻同步到主線程的 UIView/CALayer 去嵌纲。
ASDK 仿照 QuartzCore/UIKit 框架的模式，實(shí)現(xiàn)了一套類似的界面更新的機(jī)制：即在主線程的 RunLoop 中添加一個(gè) Observer腥沽，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件逮走，在收到回調(diào)時(shí)，遍歷所有之前放入隊(duì)列的待處理的任務(wù)今阳，然后一一執(zhí)行师溅。
