你好RunLooooooop

JoyZhang發表於2018-01-11
OOP

本文是對ibireme寫的深入理解RunLoop文章的cv（慚愧），內容大致一樣，有少部分自己補充的知識。

對於RunLoop的學習我是按照以下文章的順序進行閱讀的：

  1. 《RunLoop入門 看我就夠了》
  2. 《RunLoop已入門？不來應用一下？》
  3. 《iOS-RunLoop充滿靈性的死迴圈》
  4. 《深入理解RunLoop》
  5. 《iOS常見知識點二：RunLoop》
  6. 《iOS刨根問底-深入理解runloop》

以下為正文：

什麼是RunLoop？

一般來講，一個執行緒一次只能執行一個任務，執行完成後執行緒就會退出。如果我們需要一個機制，讓執行緒能隨時處理事件但並不退出，通常的程式碼邏輯是這樣的：

function loop() {
    initialize();
    do {
        var message = get_next_message();
        process_message(message);
    } while (message != quit);
}
複製程式碼

這種模型通常被稱作Event Loop。Event Loop在很多系統和框架裡都有實現，實現這種模型的關鍵點在於：如何管理事件/訊息，如何讓執行緒在沒有處理訊息時休眠以避免資源佔用、在有訊息到來時立刻被喚醒。

所以，RunLoop 實際上就是一個物件，這個物件管理了其需要處理的事件和訊息，並提供了一個入口函式來執行上面Event Loop的邏輯。執行緒執行了這個函式後，就會一直處於這個函式內部 “接受訊息->等待->處理” 的迴圈中，直到這個迴圈結束（比如傳入 quit 的訊息），函式返回。

RunLoop與執行緒的關係

除了主執行緒有胎帶的RunLoop物件，子執行緒時並不會主動生成RunLoop物件的,蘋果不允許直接建立RunLoop，它只提供了兩個自動獲取的函式：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 這兩個函式內部的邏輯大概是下面這樣:

// 全域性的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;

// 訪問 loopsDic 時的鎖
static CFSpinLock_t loopsLock;
 
// 獲取一個 pthread 對應的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {

	OSSpinLockLock(&loopsLock);
    
	if (!loopsDic) {
		// 第一次進入時，初始化全域性Dic，並先為主執行緒建立一個 RunLoop。
       loopsDic = CFDictionaryCreateMutable();
       CFRunLoopRef mainLoop = _CFRunLoopCreate();
       CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
   }
    
   // 直接從 Dictionary 裡獲取。
   CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
    
   if (!loop) {
       // 取不到時，建立一個
       loop = _CFRunLoopCreate();
       CFDictionarySetValue(loopsDic, thread, loop);
       // 註冊一個回撥，當執行緒銷燬時，順便也銷燬其對應的 RunLoop。
       _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
	}
    
   OSSpinLockUnLock(&loopsLock);
   return loop;
}
 
CFRunLoopRef CFRunLoopGetMain() {
	return _CFRunLoopGet(pthread_main_thread_np());
}
 
CFRunLoopRef CFRunLoopGetCurrent() {
   return _CFRunLoopGet(pthread_self());
}
複製程式碼

從上面的程式碼可以看出，執行緒和 RunLoop 之間是一一對應的，其關係是儲存在一個全域性的 Dictionary 裡。執行緒剛建立時並沒有 RunLoop，如果你不主動獲取，那它一直都不會有。RunLoop 的建立是發生在第一次獲取時，RunLoop 的銷燬是發生線上程結束時。你只能在一個執行緒的內部獲取其 RunLoop（主執行緒除外）。

即使你獲取(建立)了新的RunLoop物件，那你以為他會一直存在麼？答案肯定是不會的，此時的RunLoop沒有事件源，馬上就會被系統回收掉，如果你希望這個RunLoop物件一直存在，你可以通過下面的方法（方法有很多種）讓它活著：

NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runLoop run];
複製程式碼

RunLoop的構成

在 CoreFoundation 裡面關於 RunLoop 有5個類:

CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef

他們的關係如下:

你好RunLooooooop
一個 RunLoop 包含若干個 Mode，每個 Mode 又包含若干個 Source/Timer/Observer。每次呼叫 RunLoop 的主函式時，只能指定其中一個 Mode，這個 Mode 被稱作 CurrentMode。如果需要切換 Mode，只能退出 Loop，再重新指定一個 Mode 進入。這樣做主要是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響。（程式碼演示）

  1. CFRunLoopSourceRef 是事件產生的地方。Source有兩個版本：Source0 和 Source1。
  • Source0 處理App內部事件，App自己負責管理和觸發，如UIEvent、CFSocket；
  • Source1 包含了一個 mach_port 和一個回撥（函式指標），被用於通過核心和其他執行緒相互傳送訊息。
  1. CFRunLoopTimerRef 是基於時間的觸發器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一個時間長度和一個回撥（函式指標）。當其加入到 RunLoop 時，RunLoop會註冊對應的時間點，當時間點到時，RunLoop會被喚醒以執行那個回撥。
  2. CFRunLoopObserverRef是觀察者，每個 Observer 都包含了一個回撥（函式指標），當 RunLoop 的狀態發生變化時，觀察者就能通過回撥接收到這個變化。可以觀測的時間點有以下幾個：
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry         = (1UL << 0), // 即將進入Loop
    kCFRunLoopBeforeTimers  = (1UL << 1), // 即將處理 Timer
    kCFRunLoopBeforeSources = (1UL << 2), // 即將處理 Source
    kCFRunLoopBeforeWaiting = (1UL << 5), // 即將進入休眠
    kCFRunLoopAfterWaiting  = (1UL << 6), // 剛從休眠中喚醒
    kCFRunLoopExit          = (1UL << 7), // 即將退出Loop
};
複製程式碼

上面的 Source/Timer/Observer 被統稱為 mode item，一個 item 可以被同時加入多個 mode。但一個 item 被重複加入同一個 mode 時是不會有效果的。如果一個 mode 中一個 item 都沒有，則 RunLoop 會直接退出，不進入迴圈。

+程式碼演示

RunLoop 的 Mode

CFRunLoopMode 和 CFRunLoop 的結構大致如下：

 
struct __CFRunLoop {
    CFMutableSetRef _commonModes;     // Set
    CFMutableSetRef _commonModeItems; // Set<Source/Observer/Timer>
    CFRunLoopModeRef _currentMode;    // Current Runloop Mode
    CFMutableSetRef _modes;           // Set
    ...
};

struct __CFRunLoopMode {
    CFStringRef _name;            // Mode Name, 例如 @"kCFRunLoopDefaultMode"
    CFMutableSetRef _sources0;    // Set
    CFMutableSetRef _sources1;    // Set
    CFMutableArrayRef _observers; // Array
    CFMutableArrayRef _timers;    // Array
    ...
};
複製程式碼

對於開發者而言經常用到的Mode還有一個kCFRunLoopCommonModes（NSRunLoopCommonModes）,其實這個並不是某種具體的Mode，而是一種模式組合，在iOS系統中預設包含了 NSDefaultRunLoopMode 和 UITrackingRunLoopMode （注意：並不是說Runloop會執行在kCFRunLoopCommonModes這種模式下，而是相當於分別註冊了 NSDefaultRunLoopMode和 UITrackingRunLoopMode。當然你也可以通過呼叫CFRunLoopAddCommonMode()方法將自定義Mode放到 kCFRunLoopCommonModes組合）。

應用場景舉例：主執行緒的 RunLoop 裡有兩個預置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。這兩個 Mode 都已經被標記為”Common”屬性。DefaultMode 是 App 平時所處的狀態，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態。當你建立一個 Timer 並加到 DefaultMode 時，Timer 會得到重複回撥，但此時滑動一個TableView時，RunLoop 會將 mode 切換為 TrackingRunLoopMode，這時 Timer 就不會被回撥，並且也不會影響到滑動操作。有時你需要一個 Timer，在兩個 Mode 中都能得到回撥，一種辦法就是將這個 Timer 分別加入這兩個 Mode。還有一種方式，就是將 Timer 加入到頂層的 RunLoop 的 “commonModeItems” 中。”commonModeItems” 被 RunLoop 自動更新到所有具有”Common”屬性的 Mode 裡去。

有個概念叫 “CommonModes”：一個 Mode 可以將自己標記為”Common”屬性（通過將其 ModeName 新增到 RunLoop 的 “commonModes” 中）。每當 RunLoop 的內容發生變化時，RunLoop 都會自動將 _commonModeItems 裡的 Source/Observer/Timer 同步到具有 “Common” 標記的所有Mode裡。

蘋果提供了一個操作 Common 標記的字串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你可以用這個字串來操作 Common Items。

RunLoop是如何Run的

你好RunLooooooop

//設定過期時間  
SetupThisRunLoopRunTimeOutTimer();  //by GCD timer  
do{  
    //通知Observer要跑timer跟source  
    __CFRunLoopDoObservers(kCFRunLoopBeforeTimers);  
    __CFRunLoopDoObservers(kCFRunLoopBeforeSources);  
       
    // 執行被加入的block
    __CFRunLoopDoBlocks();  
    //執行到此刻，去檢測當前加到訊息佇列source0的訊息，此方法遍歷source0去執行  
    __CFRunLoopDoSource0();  
       
    //詢問GCD有沒有分到主執行緒的東西需要呼叫  
    CheckIfExistMessageInMainDispatchQueue();   //GCD  
       
    //通知Observer要進入睡眠  
    __CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);  
    //  mach_msg_trap  
    //  Zzz... 
     
    //此刻獲取到是哪個埠把我叫醒
    //  Received mach_msg,  wake up!  
    var wakeUpPort = SleepAndWaitForWakingUpPorts(); 

    //通知Observer我要醒了~  
    __CFRunLoopDoObservers(kCFRunLoopAfterWaiting);  
    //Handler msgs  
    if(wakeUpPort == timerPort){  
        //如果是timer喚醒就去執行timer  
        __CFRunLoopDoTimer();  
    }else if(wakeUpPort == mainDispatchQueuePort){  
        //GCD需要我，就去調GCD的事件  
        __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE();  
    }else{  
        //比如說網路來資料了就會用這個埠喚醒，然後做資料處理  
        __CFRunloopDoSource1();  
    }  
    __CFRunLoopDoBlocks();  
}while (!stop && !timeOut);//如果沒被外部幹掉或者時間沒到，繼續迴圈
複製程式碼

蘋果用 RunLoop 實現的功能

AutoreleasePool

App啟動後，蘋果在主執行緒 RunLoop 裡註冊了兩個 Observer，其回撥都是 _wrapRunLoopWithAutoreleasePoolHandler()。

第一個 Observer 監視的事件是 Entry(即將進入Loop)，其回撥內會呼叫 _objc_autoreleasePoolPush() 建立自動釋放池。其 order 是-2147483647，優先順序最高，保證建立釋放池發生在其他所有回撥之前。

第二個 Observer 監視了兩個事件： BeforeWaiting(準備進入休眠) 時呼叫_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池並建立新池；Exit(即將退出Loop) 時呼叫 _objc_autoreleasePoolPop() 來釋放自動釋放池。這個 Observer 的 order 是 2147483647，優先順序最低，保證其釋放池子發生在其他所有回撥之後。

事件響應

蘋果註冊了一個 Source1 (基於 mach port 的) 用來接收系統事件，其回撥函式為 __IOHIDEventSystemClientQueueCallback()。

當一個硬體事件(觸控/鎖屏/搖晃等)發生後，首先由 IOKit.framework 生成一個 IOHIDEvent 事件並由 SpringBoard 接收。SpringBoard 只接收按鍵(鎖屏/靜音等)，觸控，加速，接近感測器等幾種 Event，隨後用 mach port 轉發給需要的App程式。隨後蘋果註冊的那個 Source1 就會觸發回撥，並呼叫 _UIApplicationHandleEventQueue() 進行應用內部的分發。

_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理幷包裝成 UIEvent 進行處理或分發，其中包括識別 UIGesture/處理螢幕旋轉/傳送給 UIWindow 等。通常事件比如 UIButton 點選、touchesBegin/Move/End/Cancel 事件都是在這個回撥中完成的，但這些事件和Source1無關。

手勢識別

當 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會呼叫 Cancel 將當前的 touchesBegin/Move/End 系列回撥打斷。隨後系統將對應的 UIGestureRecognizer 標記為待處理。

蘋果註冊了一個 Observer 監測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回撥函式是 _UIGestureRecognizerUpdateObserver()，其內部會獲取所有剛被標記為待處理的 GestureRecognizer，並執行GestureRecognizer的回撥。

當有 UIGestureRecognizer 的變化(建立/銷燬/狀態改變)時，這個回撥都會進行相應處理。

介面更新

當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動呼叫了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法後，這個 UIView/CALayer 就被標記為待處理，並被提交到一個全域性的容器去。

蘋果註冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回撥去執行一個很長的函式： _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函式裡會遍歷所有待處理的 UIView/CAlayer 以執行實際的繪製和調整，並更新 UI 介面。

定時器

NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 註冊到 RunLoop 後，RunLoop 會為其重複的時間點註冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節省資源，並不會在非常準確的時間點回撥這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到後，容許有多少最大誤差。

如果某個時間點被錯過了，例如執行了一個很長的任務，則那個時間點的回撥也會跳過去，不會延後執行。就比如等公交，如果 10:10 時我忙著玩手機錯過了那個點的公交，那我只能等 10:20 這一趟了。

CADisplayLink 是一個和螢幕重新整理率一致的定時器（但實際實現原理更復雜，和 NSTimer 並不一樣，其內部實際是操作了一個 Source）。如果在兩次螢幕重新整理之間執行了一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似），造成介面卡頓的感覺。

PerformSelecter

當呼叫 NSObject 的 performSelecter:afterDelay: 後，實際上其內部會建立一個 Timer 並新增到當前執行緒的 RunLoop 中。所以如果當前執行緒沒有 RunLoop，則這個方法會失效。

當呼叫 performSelector:onThread: 時，實際上其會建立一個 Timer 加到對應的執行緒去，同樣的，如果對應執行緒沒有 RunLoop 該方法也會失效。

關於GCD

當呼叫 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主執行緒的 RunLoop 傳送訊息，RunLoop會被喚醒，並從訊息中取得這個 block，並在回撥 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 裡執行這個 block。但這個邏輯僅限於 dispatch 到主執行緒，dispatch 到其他執行緒仍然是由 libDispatch 處理的。

關於網路請求

通常使用 NSURLConnection 時，你會傳入一個 Delegate，當呼叫了 [connection start] 後，這個 Delegate 就會不停收到事件回撥。實際上，start 這個函式的內部會會獲取 CurrentRunLoop，然後在其中的 DefaultMode 新增了4個 Source0 (即需要手動觸發的Source)。

相關文章