序言：關(guān)于RunLoop簡書有很多技術(shù)牛人已經(jīng)講述的很詳細了，而且不管是項目中或是工作中都會使用到，這段時間看了MJ的視頻，所以整理出來相關(guān)技術(shù)方面的文檔，希望對于大家有幫助。
關(guān)于 RunLoop 面試題
1.runloop內(nèi)部實現(xiàn)邏輯？
2.runloop和線程的關(guān)系？
3.timer 與 runloop 的關(guān)系？
4.程序中添加每3秒響應(yīng)一次的NSTimer，當拖動tableview時timer可能無法響應(yīng)要怎么解決？
5.runloop 是怎么響應(yīng)用戶操作的， 具體流程是什么樣的？
6.說說runLoop的幾種狀態(tài)
7.runloop的mode作用是什么？
一.什么是 RunLoop
Run loops是線程相關(guān)的的基礎(chǔ)框架的一部分。一個run loop就是一個事件處理的循環(huán)，用來不停的調(diào)度工作以及處理輸入事件。其實內(nèi)部就是do－while循環(huán)，這個循環(huán)內(nèi)部不斷地處理各種任務(wù)（比 如Source，Timer，Observer）。使用run loop的目的是讓你的線程在有工作的時候忙于工作，而沒工作的時候處于休眠狀態(tài)。
3.runloop和線程的關(guān)系？
Run loop，正如其名，loop表示某種循環(huán)，和run放在一起就表示一直在運行著的循環(huán)。實際上，run loop和線程是緊密相連的，可以這樣說run loop是為了線程而生，沒有線程，它就沒有存在的必要。Run loops是線程的基礎(chǔ)架構(gòu)部分，Cocoa和CoreFundation都提供了run loop對象方便配置和管理線程的run loop（以下都已Cocoa為例）。每個線程，包括程序的主線程（main thread）都有與之相應(yīng)的run loop對象。
6.runloop應(yīng)用場景？
6.1AutoreleasePool
App啟動后，蘋果在主線程 RunLoop 里注冊了兩個 Observer，其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()。
第一個 Observer 監(jiān)視的事件是 Entry(即將進入Loop)，其回調(diào)內(nèi)會調(diào)用 _objc_autoreleasePoolPush() 創(chuàng)建自動釋放池。其 order 是-2147483647，優(yōu)先級最高，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前。
第二個 Observer 監(jiān)視了兩個事件： BeforeWaiting(準備進入休眠) 時調(diào)用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池；Exit(即將退出Loop) 時調(diào)用 _objc_autoreleasePoolPop() 來釋放自動釋放池。這個 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 了。
6.2定時器
NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 注冊到 RunLoop 后，RunLoop 會為其重復(fù)的時間點注冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節(jié)省資源，并不會在非常準確的時間點回調(diào)這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后，容許有多少最大誤差。
如果某個時間點被錯過了，例如執(zhí)行了一個很長的任務(wù)，則那個時間點的回調(diào)也會跳過去，不會延后執(zhí)行。就比如等公交，如果 10:10 時我忙著玩手機錯過了那個點的公交，那我只能等 10:20 這一趟了。
CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復(fù)雜，和 NSTimer 并不一樣，其內(nèi)部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執(zhí)行了一個長任務(wù)，那其中就會有一幀被跳過去（和 NSTimer 相似），造成界面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題，其內(nèi)部也用到了 RunLoop，這個稍后我會再單獨寫一頁博客來分析。
6.3PerformSelecter
當調(diào)用 NSObject 的 performSelecter:afterDelay: 后，實際上其內(nèi)部會創(chuàng)建一個 Timer 并添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，則這個方法會失效。
當調(diào)用 performSelector:onThread: 時，實際上其會創(chuàng)建一個 Timer 加到對應(yīng)的線程去，同樣的，如果對應(yīng)線程沒有 RunLoop 該方法也會失效。
6.4事件響應(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)中完成的。
6.5手勢識別
當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調(diào)用 Cancel 將當前的 touchesBegin/Move/End 系列回調(diào)打斷。隨后系統(tǒng)將對應(yīng)的 UIGestureRecognizer 標記為待處理。
蘋果注冊了一個 Observer 監(jiān)測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()，其內(nèi)部會獲取所有剛被標記為待處理的 GestureRecognizer，并執(zhí)行GestureRecognizer的回調(diào)。
當有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時，這個回調(diào)都會進行相應(yīng)處理。
6.6界面更新
當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個 UIView/CALayer 就被標記為待處理，并被提交到一個全局的容器去。
蘋果注冊了一個 Observer 監(jiān)聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調(diào)去執(zhí)行一個很長的函數(shù)：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數(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];
6.7關(guān)于GCD
實際上 RunLoop 底層也會用到 GCD 的東西。但同時 GCD 提供的某些接口也用到了 RunLoop， 例如 dispatch_async()。
當調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主線程的 RunLoop 發(fā)送消息，RunLoop會被喚醒，并從消息中取得這個 block，并在回調(diào) CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里執(zhí)行這個 block。但這個邏輯僅限于 dispatch 到主線程，dispatch 到其他線程仍然是由 libDispatch 處理的。
6.8關(guān)于網(wǎng)絡(luò)請求
iOS 中，關(guān)于網(wǎng)絡(luò)請求的接口自下至上有如下幾層:
CFSocket
CFNetwork ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession ->AFNetworking2, Alamofire
? CFSocket 是最底層的接口，只負責 socket 通信。
? CFNetwork 是基于 CFSocket 等接口的上層封裝，ASIHttpRequest 工作于這一層。
? NSURLConnection 是基于 CFNetwork 的更高層的封裝，提供面向?qū)ο蟮慕涌冢珹FNetworking 工作于這一層。
? NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 并列的，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)，AFNetworking2 和 Alamofire 工作于這一層。
下面主要介紹下 NSURLConnection 的工作過程。
通常使用 NSURLConnection 時，你會傳入一個 Delegate，當調(diào)用了 [connection start] 后，這個 Delegate 就會不停收到事件回調(diào)。實際上，start 這個函數(shù)的內(nèi)部會會獲取 CurrentRunLoop，然后在其中的 DefaultMode 添加了4個 Source0 (即需要手動觸發(fā)的Source)。CFMultiplexerSource 是負責各種 Delegate 回調(diào)的，CFHTTPCookieStorage 是處理各種 Cookie 的。
當開始網(wǎng)絡(luò)傳輸時，我們可以看到 NSURLConnection 創(chuàng)建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的。NSURLConnectionLoader 這個線程內(nèi)部會使用 RunLoop 來接收底層 socket 的事件，并通過之前添加的 Source0 通知到上層的 Delegate。
NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知。當收到通知后，其會在合適的時機向 CFMultiplexerSource 等 Source0 發(fā)送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執(zhí)行實際的回調(diào)。
可以想象一下如果沒有RunLoop我們的程序會是什么樣子
執(zhí)行完立刻退出，而我們的iOS程序需要從隨時保活，這樣就可以響應(yīng)我們的事件
int main(int argc, char * argv[]) {
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
//這里是偽代碼
int main(int argc, char * argv[]) {
@autoreleasepool {
int retVal = 0;
do {
//睡眠中等待消息
int message = sleep_and_wait();
//處理消息
retVal = process_message(message);
} while (0 == retVal);
}
}
程序并不會馬上退出，而是保持運行狀態(tài)
所以我們總結(jié)RunLoop的作用
1.保持程序的持續(xù)運行
2.處理App中的各種事件（比如觸摸事件、定時器事件等）
3.節(jié)省CPU資源，提高程序性能：該做事時做事，該休息時休息
我們先通過API內(nèi)一張圖片來簡單看一下RunLoop內(nèi)部運行原理
通過圖片可以看出，RunLoop在跑圈過程中，當接收到Input sources 或者 Timer sources時就會交給對應(yīng)的處理方去處理。當沒有事件消息傳入的時候，RunLoop就休息了。這里只是簡單的理解一下這張圖，接下來我們來了解RunLoop對象和其一些相關(guān)類，來更深入的理解RunLoop運行流程。
二. RunLoop對象
iOS中有2套API來訪問和使用RunLoop
Foundation：NSRunLoop
Foundation
[NSRunLoop currentRunLoop]; // 獲得當前線程的RunLoop對象
[NSRunLoop mainRunLoop]; // 獲得主線程的RunLoop對象
Core Foundation：CFRunLoopRef
Core Foundation
CFRunLoopGetCurrent(); // 獲得當前線程的RunLoop對象
CFRunLoopGetMain(); // 獲得主線程的RunLoop對象
NSRunLoop和CFRunLoopRef都代表著RunLoop對象
NSRunLoop是基于CFRunLoopRef的一層OC包裝
CFRunLoopRef是開源的
我們可以通過runloop的源碼看看runloop的定義
struct __CFRunLoop {
CFRuntimeBase _base;
pthread_mutex_t _lock; /* locked for accessing mode list */
__CFPort _wakeUpPort; // used for CFRunLoopWakeUp
Boolean _unused;
volatile _per_run_data *_perRunData; // reset for runs of the run loop
pthread_t _pthread;
uint32_t _winthread;
CFMutableSetRef _commonModes;
CFMutableSetRef _commonModeItems;
CFRunLoopModeRef _currentMode;//當前的mode
CFMutableSetRef _modes;//runloop中mode的集合
struct _block_item *_blocks_head;
struct _block_item *_blocks_tail;
CFAbsoluteTime _runTime;
CFAbsoluteTime _sleepTime;
CFTypeRef _counterpart;
};
從中我們不難發(fā)現(xiàn)RunLoop就是一個結(jié)構(gòu)體，從這個源碼里我們找出兩個主要的成員來講述一下
CFRunLoopModeRef _currentMode;
CFMutableSetRef _modes;
目前已知的Mode有5種
1.default:App的默認Mode，通常主線程是在這個Mode下運行
2.tracking:界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他 Mode 影響
3.init:在剛啟動 App 時第進入的第一個 Mode，啟動完成后就不再使用
4.eventreceive:接受系統(tǒng)事件的內(nèi)部 Mode，通常用不到
5.runcommon :這是一個占位用的Mode，不是一種真正的Mode
CFRunLoopModeRef 其實是指向__CFRunLoopMode結(jié)構(gòu)體的指針，__CFRunLoopMode結(jié)構(gòu)體源碼如下
struct __CFRunLoopMode {
CFRuntimeBase _base;
pthread_mutex_t _lock; /* must have the run loop locked before locking this */
CFStringRef _name;
Boolean _stopped;
char _padding[3];
CFMutableSetRef _sources0;
CFMutableSetRef _sources1;
CFMutableArrayRef _observers;
CFMutableArrayRef _timers;
CFMutableDictionaryRef _portToV1SourceMap;
__CFPortSet _portSet;
CFIndex _observerMask;
#if USE_DISPATCH_SOURCE_FOR_TIMERS
dispatch_source_t _timerSource;
dispatch_queue_t _queue;
Boolean _timerFired; // set to true by the source when a timer has fired
Boolean _dispatchTimerArmed;
#endif
#if USE_MK_TIMER_TOO
mach_port_t _timerPort;
Boolean _mkTimerArmed;
#endif
#if DEPLOYMENT_TARGET_WINDOWS
DWORD _msgQMask;
void (*_msgPump)(void);
#endif
uint64_t _timerSoftDeadline; /* TSR */
uint64_t _timerHardDeadline; /* TSR */
};
我們可以發(fā)現(xiàn)在runloopmde中有幾個重要的屬性
CFMutableSetRef _sources0;
CFMutableSetRef _sources1;
CFMutableArrayRef _observers;
CFMutableArrayRef _timers;
現(xiàn)在我們說一下sources0和sources1分別是什么意思，代表什么事件。我們通過代碼來解釋一下
從中我們可以看出觸摸事件其實就是sources0調(diào)用了touchbegin方法，其實Perform Selector事件也是通過sources0去調(diào)用的，這里就不演示了.而source1是基于port的線程間的通信
可以說我們的mode中主要就是包含了這幾個屬性
CFRunLoopModeRef代表RunLoop的運行模式
1.一個RunLoop包含若干個Mode，每個Mode又包含若干個Source0/Source1/Timer/Observer
2.RunLoop啟動時只能選擇其中一個Mode，作為currentMode
3.如果需要切換Mode，只能退出當前Loop，再重新選擇一個Mode進入
4.不同組的Source0/Source1/Timer/Observer能分隔開來，互不影響
5.如果Mode里沒有任何Source0/Source1/Timer/Observer，RunLoop會立馬退出
如圖所示：
RunLoop相關(guān)的類
Core Foundation中關(guān)于RunLoop的5個類
CFRunLoopRef - 獲得當前RunLoop和主RunLoop
CFRunLoopModeRef - RunLoop 運行模式，只能選擇一種，在不同模式中做不同的操作|
CFRunLoopSourceRef - 事件源，輸入源
CFRunLoopTimerRef - 定時器時間
CFRunLoopObserverRef - 觀察者
三.RunLoop與線程
蘋果不允許直接創(chuàng)建 RunLoop，它只提供了兩個自動獲取的函數(shù)：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 這兩個函數(shù)內(nèi)部的邏輯大概是下面這樣:
/// 全局的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 訪問 loopsDic 時的鎖
static CFSpinLock_t loopsLock;
/// 獲取一個 pthread 對應(yīng)的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
OSSpinLockLock(&loopsLock);
if (!loopsDic) {
// 第一次進入時，初始化全局Dic，并先為主線程創(chuàng)建一個 RunLoop。
loopsDic = CFDictionaryCreateMutable();
CFRunLoopRef mainLoop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
}
/// 直接從 Dictionary 里獲取。
CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
if (!loop) {
/// 取不到時，創(chuàng)建一個
loop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic, thread, loop);
/// 注冊一個回調(diào)，當線程銷毀時，順便也銷毀其對應(yīng)的 RunLoop。
_CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
return loop;
}
CFRunLoopRef CFRunLoopGetMain() {
return _CFRunLoopGet(pthread_main_thread_np());
}
CFRunLoopRef CFRunLoopGetCurrent() {
return _CFRunLoopGet(pthread_self());
}
從上面的代碼可以看出，線程和 RunLoop 之間是一一對應(yīng)的，其關(guān)系是保存在一個全局的 Dictionary 里。線程剛創(chuàng)建時并沒有 RunLoop，如果你不主動獲取，那它一直都不會有。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時，RunLoop 的銷毀是發(fā)生在線程結(jié)束時。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外）
1.每條線程都有唯一的一個與之對應(yīng)的RunLoop對象
2.RunLoop保存在一個全局的Dictionary里，線程作為key，RunLoop作為value
3.線程剛創(chuàng)建時并沒有RunLoop對象，RunLoop會在第一次獲取它時創(chuàng)建
4.RunLoop會在線程結(jié)束時銷毀
5.主線程的RunLoop已經(jīng)自動獲取（創(chuàng)建），子線程默認沒有開啟RunLoop
四. RunLoop處理邏輯
1.通知observes：進入loop
2.通知observes：即將處理timers
3.通知observes：即將處理sources
4.處理blocks
5.處理source0（可能再次處理blocks）
6.如果存在source1，跳轉(zhuǎn)到第8步
7.通知observes：開始休眠（等待消息喚醒）
8.通知observes：結(jié)束休眠（被某個消息喚醒）
1. 處理timer
2. 處理GCD Async To Main Queue
3. 處理source1
9.處理blocks
10.根據(jù)前面的執(zhí)行結(jié)果，決定如何操作
1. 回到第2步
2. 退出RunLoop
11.通知observes:退出loop |
主流程代碼演示：
// 共外部調(diào)用的公開的CFRunLoopRun方法，其內(nèi)部會調(diào)用CFRunLoopRunSpecific
void CFRunLoopRun(void) { /* DOES CALLOUT */
int32_t result;
do {
result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
CHECK_FOR_FORK();
} while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
}
// 經(jīng)過精簡的 CFRunLoopRunSpecific 函數(shù)代碼，其內(nèi)部會調(diào)用__CFRunLoopRun函數(shù)
SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) { /* DOES CALLOUT */
// 通知Observers : 進入Loop
// __CFRunLoopDoObservers內(nèi)部會調(diào)用 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
函數(shù)
if (currentMode->_observerMask & kCFRunLoopEntry ) __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
// 核心的Loop邏輯
result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
// 通知Observers : 退出Loop
if (currentMode->_observerMask & kCFRunLoopExit ) __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
return result;
}
// 精簡后的 __CFRunLoopRun函數(shù)，保留了主要代碼
static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode) {
int32_t retVal = 0;
do {
// 通知Observers：即將處理Timers
__CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);
// 通知Observers：即將處理Sources
__CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);
// 處理Blocks
__CFRunLoopDoBlocks(rl, rlm);
// 處理Sources0
if (__CFRunLoopDoSources0(rl, rlm, stopAfterHandle)) {
// 處理Blocks
__CFRunLoopDoBlocks(rl, rlm);
}
// 如果有Sources1，就跳轉(zhuǎn)到handle_msg標記處
if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) {
goto handle_msg;
}
// 通知Observers：即將休眠
__CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);
// 進入休眠，等待其他消息喚醒
__CFRunLoopSetSleeping(rl);
__CFPortSetInsert(dispatchPort, waitSet);
do {
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy);
} while (1);
// 醒來
__CFPortSetRemove(dispatchPort, waitSet);
__CFRunLoopUnsetSleeping(rl);
// 通知Observers：已經(jīng)喚醒
__CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);
handle_msg: // 看看是誰喚醒了RunLoop，進行相應(yīng)的處理
if (被Timer喚醒的) {
// 處理Timer
__CFRunLoopDoTimers(rl, rlm, mach_absolute_time());
}
else if (被GCD喚醒的) {
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
} else { // 被Sources1喚醒的
__CFRunLoopDoSource1(rl, rlm, rls, msg, msg->msgh_size, &reply);
}
// 執(zhí)行Blocks
__CFRunLoopDoBlocks(rl, rlm);
// 根據(jù)之前的執(zhí)行結(jié)果，來決定怎么做，為retVal賦相應(yīng)的值
if (sourceHandledThisLoop && stopAfterHandle) {
retVal = kCFRunLoopRunHandledSource;
} else if (timeout_context->termTSR < mach_absolute_time()) {
retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(rl)) {
__CFRunLoopUnsetStopped(rl);
retVal = kCFRunLoopRunStopped;
} else if (rlm->_stopped) {
rlm->_stopped = false;
retVal = kCFRunLoopRunStopped;
} else if (__CFRunLoopModeIsEmpty(rl, rlm, previousMode)) {
retVal = kCFRunLoopRunFinished;
}
} while (0 == retVal);
return retVal;
}
CFRunLoopObserverRef是觀察者，能夠監(jiān)聽RunLoop的狀態(tài)改變
/* Run Loop Observer Activities */
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 即將進入RunLoop
kCFRunLoopBeforeTimers = (1UL << 1),// 即將處理Timer
kCFRunLoopBeforeSources = (1UL << 2),// 即將處理Source
kCFRunLoopBeforeWaiting = (1UL << 5),//即將進入休眠
kCFRunLoopAfterWaiting = (1UL << 6),// 剛從休眠中喚醒
kCFRunLoopExit = (1UL << 7),// 即將退出RunLoop
kCFRunLoopAllActivities = 0x0FFFFFFFU
};
-(void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
{
//創(chuàng)建監(jiān)聽者
/*
第一個參數(shù) CFAllocatorRef allocator：分配存儲空間 CFAllocatorGetDefault()默認分配
第二個參數(shù) CFOptionFlags activities：要監(jiān)聽的狀態(tài) kCFRunLoopAllActivities 監(jiān)聽所有狀態(tài)
第三個參數(shù) Boolean repeats：YES:持續(xù)監(jiān)聽 NO:不持續(xù)
第四個參數(shù) CFIndex order：優(yōu)先級，一般填0即可
第五個參數(shù) ：回調(diào) 兩個參數(shù)observer:監(jiān)聽者 activity:監(jiān)聽的事件
*/
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
switch (activity) {
case kCFRunLoopEntry:
NSLog(@"RunLoop進入");
break;
case kCFRunLoopBeforeTimers:
NSLog(@"RunLoop要處理Timers了");
break;
case kCFRunLoopBeforeSources:
NSLog(@"RunLoop要處理Sources了");
break;
case kCFRunLoopBeforeWaiting:
NSLog(@"RunLoop要休息了");
break;
case kCFRunLoopAfterWaiting:
NSLog(@"RunLoop醒來了");
break;
case kCFRunLoopExit:
NSLog(@"RunLoop退出了");
break;
default:
break;
}
});
// 給RunLoop添加監(jiān)聽者
/*
第一個參數(shù) CFRunLoopRef rl：要監(jiān)聽哪個RunLoop,這里監(jiān)聽的是主線程的RunLoop
第二個參數(shù) CFRunLoopObserverRef observer 監(jiān)聽者
第三個參數(shù) CFStringRef mode 要監(jiān)聽RunLoop在哪種運行模式下的狀態(tài)
*/
CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);
/*
CF的內(nèi)存管理（Core Foundation）
凡是帶有Create、Copy、Retain等字眼的函數(shù)，創(chuàng)建出來的對象，都需要在最后做一次release
GCD本來在iOS6.0之前也是需要我們釋放的，6.0之后GCD已經(jīng)納入到了ARC中，所以我們不需要管了
*/
CFRelease(observer);
}
上述代碼相應(yīng)處理事件函數(shù)內(nèi)部還會調(diào)用更底層的函數(shù)，內(nèi)部調(diào)用才是真正處理事件的函數(shù)。
給大家留一個問題，怎么通過runloop進行線程保活？？？
