一般來講崔涂,一個(gè)線程一次只能執(zhí)行一個(gè)任務(wù)阳掐,執(zhí)行完成后線程就會(huì)退出。如果我們需要一個(gè)機(jī)制冷蚂,讓線程能隨時(shí)處理事件但并不退出缭保,通常的代碼邏輯 是這樣的:
function loop() {
initialize();
do {
var message = get_next_message();
process_message(message);
} while (message != quit);
}
其內(nèi)容運(yùn)行的邏輯大致如圖所示:
可以看到,實(shí)際上 RunLoop 就是這樣一個(gè)函數(shù)蝙茶,其內(nèi)部是一個(gè) do-while 循環(huán)艺骂。當(dāng)你調(diào)用 CFRunLoopRun() 時(shí),線程就會(huì)一直停留在這個(gè)循環(huán)里隆夯;直到超時(shí)或被手動(dòng)停止钳恕,該函數(shù)才會(huì)返回。
首先我們可以看一下 App 啟動(dòng)后 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)注冊(cè)了 5 個(gè) Mode:
- 1忧额、kCFRunLoopDefaultMode: App的默認(rèn) Mode,通常主線程是在這個(gè) Mode 下運(yùn)行的愧口。
- 2睦番、UITrackingRunLoopMode: 界面跟蹤 Mode,用于 ScrollView 追蹤觸摸滑動(dòng),保證界面滑動(dòng)時(shí)不受其他 Mode 影響托嚣。
- 3巩检、UIInitializationRunLoopMode: 在剛啟動(dòng) App 時(shí)第進(jìn)入的第一個(gè) Mode,啟動(dòng)完成后就不再使用示启。
- 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會(huì)創(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啟動(dòng)后士八,蘋果在主線程 RunLoop 里注冊(cè)了兩個(gè) Observer,其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()
梁呈。
第一個(gè) Observer 監(jiān)視的事件是 Entry(即將進(jìn)入 Loop)婚度,其回調(diào)內(nèi)會(huì)調(diào)用 _objc_autoreleasePoolPush()
創(chuàng)建自動(dòng)釋放池。其 order 是-2147483647
官卡,優(yōu)先級(jí)最高蝗茁,保證創(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()
來釋放自動(dòng)釋放池评甜。這個(gè) Observer 的 order 是 2147483647
,優(yōu)先級(jí)最低仔涩,保證其釋放池子發(fā)生在其他所有回調(diào)之后忍坷。
在主線程執(zhí)行的代碼,通常是寫在諸如事件回調(diào)、Timer 回調(diào)內(nèi)的佩研。這些回調(diào)會(huì)被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著柑肴,所以不會(huì)出現(xiàn)內(nèi)存泄漏,開發(fā)者也不必顯示創(chuàng)建 Pool 了旬薯。
事件響應(yīng)
蘋果注冊(cè)了一個(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)程凌节。隨后蘋果注冊(cè)的那個(gè) Source1 就會(huì)觸發(fā)回調(diào),并調(diào)用 _UIApplicationHandleEventQueue()
進(jìn)行應(yīng)用內(nèi)部的分發(fā)洒试。
_UIApplicationHandleEventQueue()
會(huì)把 IOHIDEvent 處理并包裝成 UIEvent 進(jìn)行處理或分發(fā)倍奢,其中包括識(shí)別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等。通常事件比如 UIButton 點(diǎn)擊垒棋、touchesBegin/Move/End/Cancel 事件都是在這個(gè)回調(diào)中完成的卒煞。
手勢(shì)識(shí)別
當(dāng)上面的 _UIApplicationHandleEventQueue()
識(shí)別了一個(gè)手勢(shì)時(shí),其首先會(huì)調(diào)用 Cancel 將當(dāng)前的 touchesBegin/Move/End 系列回調(diào)打斷叼架。隨后系統(tǒng)將對(duì)應(yīng)的 UIGestureRecognizer 標(biāo)記為待處理畔裕。
蘋果注冊(cè)了一個(gè) Observer 監(jiān)測(cè) BeforeWaiting (Loop 即將進(jìn)入休眠) 事件,這個(gè) Observer 的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()
碉碉,其內(nèi)部會(huì)獲取所有剛被標(biāo)記為待處理的 GestureRecognizer,并執(zhí)行 GestureRecognizer 的回調(diào)淮韭。
當(dāng)有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時(shí)垢粮,這個(gè)回調(diào)都會(huì)進(jìn)行相應(yīng)處理。
界面更新
當(dāng)在操作 UI 時(shí)靠粪,比如改變了 Frame蜡吧、更新了 UIView/CALayer 的層次時(shí),或者手動(dòng)調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后占键,這個(gè) UIView/CALayer 就被標(biāo)記為待處理昔善,并被提交到一個(gè)全局的容器去。
蘋果注冊(cè)了一個(gè) Observer 監(jiān)聽 BeforeWaiting(即將進(jìn)入休眠) 和 Exit (即將退出 Loop) 事件畔乙,回調(diào)去執(zhí)行一個(gè)很長的函數(shù): _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
君仆。這個(gè)函數(shù)里會(huì)遍歷所有待處理的 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ū)動(dòng),而非 GCD 驅(qū)動(dòng)的咖摹。
一個(gè) NSTimer 注冊(cè)到 RunLoop 后评姨,RunLoop 會(huì)為其重復(fù)的時(shí)間點(diǎn)注冊(cè)好事件。例如 10:00, 10:10, 10:20 這幾個(gè)時(shí)間點(diǎn)萤晴。RunLoop 為了節(jié)省資源吐句,并不會(huì)在非常準(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)也會(huì)跳過去,不會(huì)延后執(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ù)已添,那其中就會(huì)有一幀被跳過去(和 NSTimer 相似),造成界面卡頓的感覺滥酥。在快速滑動(dòng) TableView時(shí)更舞,即使一幀的卡頓也會(huì)讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題坎吻,其內(nèi)部也用到了 RunLoop缆蝉。
PerformSelector
當(dāng)調(diào)用 NSObject 的 performSelector:afterDelay:
后,實(shí)際上其內(nèi)部會(huì)創(chuàng)建一個(gè) Timer 并添加到當(dāng)前線程的 RunLoop 中瘦真。所以如果當(dāng)前線程沒有 RunLoop刊头,則這個(gè)方法會(huì)失效。
當(dāng)調(diào)用 performSelector:onThread:
時(shí)诸尽,實(shí)際上其會(huì)創(chuàng)建一個(gè) Timer 加到對(duì)應(yīng)的線程去原杂,同樣的,如果對(duì)應(yīng)線程沒有 RunLoop 該方法也會(huì)失效您机。
關(guān)于 GCD
實(shí)際上 RunLoop 底層也會(huì)用到 GCD 的東西穿肄。但同時(shí) GCD 提供的某些接口也用到了 RunLoop年局,例如 dispatch_async()
。
當(dāng)調(diào)用 dispatch_async(dispatch_get_main_queue(), block)
時(shí)被碗,libDispatch 會(huì)向主線程的 RunLoop 發(fā)送消息某宪,RunLoop 會(huì)被喚醒,并從消息中取得這個(gè) block锐朴,并在回調(diào) __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()
里執(zhí)行這個(gè) block兴喂。但這個(gè)邏輯僅限于 dispatch 到主線程,dispatch 到其他線程仍然是由 libDispatch 處理的焚志。
關(guān)于網(wǎng)絡(luò)請(qǐng)求
iOS 中衣迷,關(guān)于網(wǎng)絡(luò)請(qǐng)求的接口自下至上有如下幾層:
- CFSocket,是最底層的接口酱酬,只負(fù)責(zé) socket 通信壶谒。
- CFNetwork,是基于 CFSocket 等接口的上層封裝膳沽,ASIHttpRequest 工作于這一層汗菜。
- NSURLConnection,是基于 CFNetwork 的更高層的封裝挑社,提供面向?qū)ο蟮慕涌谠山纾珹FNetworking 工作于這一層。
- NSURLSession痛阻,是 iOS7 中新增的接口菌瘪,表面上是和 NSURLConnection 并列的,但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)阱当,AFNetworking2 和 Alamofire 工作于這一層俏扩。
NSURLConnection 的工作過程:
通常使用 NSURLConnection 時(shí),你會(huì)傳入一個(gè) Delegate弊添,當(dāng)調(diào)用了 [connection start] 后录淡,這個(gè) Delegate 就會(huì)不停收到事件回調(diào)。實(shí)際上油坝,start 這個(gè)函數(shù)的內(nèi)部會(huì)會(huì)獲取 CurrentRunLoop嫉戚,然后在其中的 DefaultMode 添加了 4 個(gè) Source0 (即需要手動(dòng)觸發(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)部會(huì)使用 RunLoop 來接收底層 socket 的事件拆魏,并通過之前添加的 Source0 通知到上層的 Delegate盯桦。
NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知。當(dāng)收到通知后渤刃,其會(huì)在合適的時(shí)機(jī)向 CFMultiplexerSource 等 Source0 發(fā)送通知拥峦,同時(shí)喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會(huì)在 Delegate 線程的 RunLoop 對(duì) Delegate 執(zhí)行實(shí)際的回調(diào)卖子。
RunLoop 的實(shí)際應(yīng)用舉例
AFNetworking 中的 AFURLConnectionOperation
這個(gè)類是基于 NSURLConnection 構(gòu)建的略号,其希望能在后臺(tái)線程接收 Delegate 回調(diào)。為此 AFNetworking 單獨(dú)創(chuàng)建了一個(gè)線程洋闽,并在這個(gè)線程中啟動(dòng)了一個(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 啟動(dòng)前內(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è)后臺(tái)線程執(zhí)行任務(wù)時(shí)这弧,AFNetworking 通過調(diào)用 [NSObject performSelector:onThread:..] 將這個(gè)任務(wù)扔到了后臺(tái)線程的 RunLoop 中。
AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架虚汛,其原理大致如下:
UI 線程中一旦出現(xiàn)繁重的任務(wù)就會(huì)導(dǎo)致界面卡頓匾浪,這類任務(wù)通常分為3類:排版,繪制泽疆,UI對(duì)象操作户矢。
排版通常包括計(jì)算視圖大小、計(jì)算文本高度殉疼、重新計(jì)算子式圖的排版等操作梯浪。 繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預(yù)先解壓)瓢娜、元素繪制 (Quartz)等操作挂洛。 UI對(duì)象操作通常包括 UIView/CALayer 等 UI 對(duì)象的創(chuàng)建、設(shè)置屬性和銷毀眠砾。
其中前兩類操作可以通過各種方法扔到后臺(tái)線程執(zhí)行虏劲,而最后一類操作只能在主線程完成,并且有時(shí)后面的操作需要依賴前面操作的結(jié)果 (例如TextView創(chuàng)建時(shí)可能需要提前計(jì)算出文本的大邪薄)柒巫。ASDK 所做的,就是盡量將能放入后臺(tái)的任務(wù)放入后臺(tái)谷丸,不能的則盡量推遲 (例如視圖的創(chuàng)建堡掏、屬性的調(diào)整)。
為此刨疼,ASDK 創(chuàng)建了一個(gè)名為 ASDisplayNode 的對(duì)象泉唁,并在內(nèi)部封裝了 UIView/CALayer鹅龄,它具有和 UIView/CALayer 相似的屬性,例如 frame亭畜、backgroundColor等扮休。所有這些屬性都可以在后臺(tái)線程更改,開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer拴鸵,這樣就可以將排版和繪制放入了后臺(tái)線程玷坠。但是無論怎么操作,這些屬性總需要在某個(gè)時(shí)刻同步到主線程的 UIView/CALayer 去劲藐。
ASDK 仿照 QuartzCore/UIKit 框架的模式侨糟,實(shí)現(xiàn)了一套類似的界面更新的機(jī)制:即在主線程的 RunLoop 中添加一個(gè) Observer,監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件瘩燥,在收到回調(diào)時(shí)秕重,遍歷所有之前放入隊(duì)列的待處理的任務(wù),然后一一執(zhí)行厉膀。
更多:iOS面試題合集