RunLoop

一 概述：

• 一句話解釋RunLoop：運行任務的循環。

• 為什麽要有RunLoop：解決交互式UI設計中的一個問題，如何快速響應用戶輸入，如何快速將程序運行結果輸出到屏幕？

  計算機是個笨蛋，同一個時間裏只能做同一件事情。要麽處理計算任務， 要麽輪詢各種I/O 接口。 那麽，在沒有線程的情況下，如何在計算的同時， 又能夠輪詢各種I/O接口，以迅捷的 和用戶交互呢? CS的科學家給出的答案是:看起來夠迅捷就行。人的反應速度是有上限的， 因此只要把 計算機的運行時間劃分成很多小片段，小到小於人的反應時間， 那麽就可以從這些時間片段 中“偷”出一些時間來處理計算任務了。 這麽說似乎比較抽象。用個例子可以說明runloop的原理: 要求實現一個程序，當程序運行 後，用戶每敲擊一個字符， 就直接在屏幕上打印用戶輸入的字符，當程序運行十秒之後， 在 屏幕上輸出“Timeout”並退出程序。

  那麽，問題來了:不用多線程，如何實現這個程序?按照直覺，可以這麽寫:

  error implementation?≡ 
  
  time_t startTime = time();
  
  char buf[255]; 
  
  scanf("%s\n", buf);
  
  printf("%s\n", buf);
  
  sleep(5);
  
  Printf("Timeout\n");
  
  return 0;
  

可是！scanf等掃描用戶輸入的程序是阻塞的。 也就是說, 在scanf這個地方，只要用戶一直沒有輸入，那麽程序就全部阻塞了， 接下sleep(5);在用戶完成輸入之前是永遠不會運行 的。那麽， 把sleep(5);放到scanf前面呢?也不行，因為sleep同樣也是阻塞的。 也就是說， 如果sleep在前面，那麽有整整5秒時間，用戶都是無法輸入的。

這裏我們有兩個任務:

1) 檢測用戶輸入;

2) 檢測時間流逝。 這兩個任務是必須並行 的，可是如果直接調用系統的方法，那麽我們無法並行， 因為scanf和sleep都是阻塞的，我們 沒法控制阻塞的時間和條件。 既然阻塞的方法不行，那麽為什麽不試試非阻塞的呢? 這就是runloop這種框架的動機。 這裏我們假設有一個非阻塞的bool readCh(char* ch)函數。 它的作用是獲取用戶鍵入的一 個ascii字符，如果用戶沒有輸入任何東西， 那麽它將返回false，否則為true。在true的情況 下， 用戶的輸入通過ch參數帶出。

?unblocked implementation?≡
time_t startTime = time(NULL);
while (1) {
char ch;
if (true == readCh(&ch)) {
    printf("%c", ch);
}
if (time(NULL) - startTime > 5) {
    printf("Timeout\n");
    return; 
}
 

二 Runloop 實現:

接下來的章節中我們將實際實現一個基本的runloop， 同樣很陽春，具備這麽些個功能:

1. runloop 的啟動、退出機制
2. 任務註冊
3. runloop重入，loop一段指定的時間
4. autorelease 同時還會實現一個Timer，演示一下runloop下的異步執行和回調機制。

2.1 問題描述

我們要實現的程序還是和第一節裏面的需求是一樣的， 在一定時間內允許用戶輸入任意字 符並將用戶的輸入打印在屏幕上， 5秒後程序打印Timeout並退出。

2.2 Outline

首先我們來看看，有了runloop之後，程序的main函數應該是怎樣的:

?main function?≡
 int main() {
    //register runloop jobs
    runloop_registerJob(&checkAndPrintUserInput);
    timer_setTimer(5, &printTimeoutAndExit);
    //kick up runloop
    runloop_run();
    return 0;
}

瞧，這就是main函數的全部了，分兩部分:註冊任務和啟動runloop。

2.3 Register Jobs in runloop

我們先來看看第一部分:

 runloop_registerJob(&checkAndPrintUserInput);
 timer_setTimer(5, &printTimeoutAndExit);

第一句幾乎是自註釋的，你應該猜到了，這句的作用是往runloop中註冊一個任務， 而任 務的形式是一個函數。所以在這裏， checkAndPrintUserInput這個函數的地址被當做參數傳入 了。 在具體談談註冊機制的實現之前，我們先規定一下這裏runloop中的“任務”。 從開發的角 度看，任務本質上就是一段代碼，而用何種形式組織這段代碼， 則是根據應用場景的不同而不 同的，比如這個例子中， 我們規定一個函數就是一個任務，而因為是函數，所以得有一定的調 用約定:

?define job function type?≡
typedef void (*runloopJob)(void);

而在Apple平臺下，一般是用OO的方式——一個對象+它的方法來代表一個任務。 下面就是 在日常的編程中，Apple程序員最經常接觸到的註冊任務的方式:

?most familia way to register a job on runloop?≡
[someInstance performSelectorOnMainThread: SEL(someSelector)];

有些驚訝麽?別奇怪，NSRunloop和NSObject是緊密結合的。 performSelectorOnMainThread: 這個函數背後幹的就是把它的調用者—— self和參數 ——一個selector包裝成一個可以在runloop中運行的任務， 並將這個任務註冊到runloop裏面

好，接下來要實現我們自己的任務註冊機制了。 因為比較陽春，我們用一個全局的數組來 做任務隊列， runloop在運行時會遍歷這個數組，取出其中的函數地址並執行。 這個數組的最 末尾一個元素為NULL，作為數組結束的標誌。

?define a job queue?≡
runloopJob jobs[10] = {NULL, NULL, NULL, NULL, NULL,
                     NULL, NULL, NULL, NULL, NULL};

出於簡單起見，jobs數組的長度為10，在這個例子裏也夠用了。 實際上一般是用動態的數 組來實現的任務隊列，在Apple平臺上，一般是NSArray。

有了任務隊列，註冊任務這個函數就很簡單了:(將新任務添加到隊列末尾)

?definition of runloop_registerJob?≡
bool runloop_registerJob(runloopJob newJob) {
 runloopJob* jobPos = jobs;
 runloopJob* endPos = jobs + sizeof(jobs) / sizeof(runloopJobs) - 1;
 while (*jobPos && jobPos < endPos) {
        jobPos++;
 }
 if (jobPos < endPos) 
      *jobPos = newJob;
      return true;
 }
 return false;
}

2.4 Define a Timer

接著是第二句話， 也是自註釋的， 註冊一個Timer， 時間五秒，五秒後調用printTime- outAndExit。 這裏實現的Timer很簡單，全局只有一個Timer，只能設置一個回調函數。 實現 Timer實際上要實現兩部分內容:

1) Timer是如何利用runloop啟動、運行和退出的;

2) Timer 的回調函數是如何註冊的。

我們首先來看Timer需要用到的typedef和變量:

?definition of Timer?≡
typedef void (*timerCallback)(void);
time_t timer_startTime = 0;
time_t timeout_seconds = 0;
timerCallback timer_timerCallback = NULL;
bool timer_is_set = false;

上面這段代碼首先是Timer的回調函數的定義， 接著是Timer開始運行的時間、Timer超時的 時間和回調函數。 最後一個變量用於防止重復設置Timer。

因為沒有線程，所以我們的Timer必須在runloop中反復運行，以達到檢測時間流逝的效果。 所以我們需要定義Timer在runloop中運行的內容:

?definition of Timer?+≡
void timerJob() {
    if (time(NULL) - timer_startTime > timeout_seconds)  {
        timer_startTime = 0;
        timer_is_set = false;
        timeout_seconds = 0;
        runloop_unregisterJob(&timerJob);
        timer_timerCallback();
        timer_timerCallback = NULL; 
    }
}

上面這段代碼很簡單，每次運行都檢測是否超時，如果超時則重置Timer相關的變量， 並將 timerJob從runloop的任務隊列中移除，最後調用回調函數並重置回調函數 。 到這裏，我們已經解決了Timer是如何在runloop中運行和退出這兩個問題， 最後我們來實現Timer的註冊機制:

?definition of Timer?+≡
bool timer_setTimer(time_t timeout, timerCallback callback) {
    if (timer_is_set) {
        return false;
    }
    timer_startTime = time(NULL);
    timer_timerCallback = callback;
    timeout_seconds = timeout;
    timer_is_set = true;
    runloop_registerJob(timerJob);
    return true;
}

2.5 Run a runloop

OK, 接著我們可以看看，runloop是怎麽run的了:

?definition of runloop run and quit?≡
bool shouldContinue;
void runloop_run() {
      bool shouldContinue = true;
      int jobIndex = 0;
      while(1) {
        if (jobs[0] == NULL) {
                return;
            }
            if (jobs[jobIndex] != NULL) {
                jobs[jobIndex]();
                jobIndex++;
            } else {
                jobIndex = 0;
            }
            if (false == shouldContinue) {
                break; 
            }
        } 
}

不復雜吧?接著就是退出機制了。

?definition of runloop run and quit?+≡ 
void runloop_stop() {
    shouldContinue = false;
}

這個退出機制一般是在某個runloop中的任務調用的。 別忘了，runlooprun實際上是阻塞式的函數，任何形如 runlooprun(); runloop_stop(); 的代碼都是不能終止runloop的。

好了，到這裏，一個基本的runloop就完備了，最後我們來實現 checkAndPrintUserInput 和 printTimeoutAndExit兩個函數:

?definition of checkAndPrintUserInput?≡ 
void checkAndPrintUserInput() {
      char ch;
      if (canRead(&ch))  {
        printf("%c", ch);
      }
}

?definition of printTimeoutAndExit?≡
 void printTimeoutAndExit() {
        printf("Timeout\n");
        exit(0);
}

三 Runloop的一些特點和註意事項

最後，總結一下runloop的一些特點:

1. 單線程!

   runloop絕不是一個多線程的玩意， 所以不存在一個變量同時被改寫這回事， 所以在NSRunloop中，如果你不希望一個變量被改寫， 而使用了一個NSLock來鎖住這個變 量， 那麽，你要麽得到一個死鎖(如果你的鎖是非遞歸的情況)， 要麽你想保護的變量 還是被改寫了(因為是單線程的)。

2. 所有起點是UI的代碼， 除非明確指明運行在其他線程上 (通過類似performOnBackground, performSelector:onThread: 等方式)，否則都是運行在主線程的runloop上的

3. 不要在runloop中運行些“大任務”，比如循環個十萬二十萬次或者其他什麽東西， 因為 你實際上是在使用和UI相同的線程。不然，你就會經常見到風火輪了。

4. 異步!

   runloop的確是一個異步模型， 只不過這個異步模型是通過對任務的調度來實現 的。比如你向runloop中註冊任務時， 不是添加到任務的隊尾 ，而是插隊,那麽實際上 執行順序就被打亂了。 插隊這種現象其實很常見，每次當你在一個函數裏面調用 - [NSRunloop runMode:beforeDate:] 這個方法時， 實質上就是在打斷當前的runloop任 務的執行，轉而執行runloop中的其他任務。 記住，這是以單線程的方式打亂了任務的時 序，所以NSLock是不起作用的。

5. 一個runloop，一個線程。

   當啟動一個新的線程的時候， 這個線程並不會自動擁有一個 runloop，你必須自己完成創建等工作。

6. 沒有runloop，沒有autorelease。 runloop的每次loop開始時，會建立一個autorelease pool， 於是這次loop中執行的所有任務裏，任意某個對象調用了autorelease， 它都 會被註冊到這個autorelease pool中。 然後在本次loop結束時，autorelease pool會被 drain。 所以，當沒有runloop的時候，也就沒有相關聯的autorelease pool， 這個時候 調用autorelease是沒有意義的

四 iOS中的Runloop

RunLoop 實際上就是一個對象，這個對象管理了其需要處理的事件和消息，並提供了一個入口函數來執行上面 Event Loop 的邏輯。線程執行了這個函數後，就會一直處於這個函數內部 “接受消息->等待->處理” 的循環中，直到這個循環結束（比如傳入 quit 的消息），函數返回。

OSX/iOS 系統中，提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef。 CFRunLoopRef 是在 CoreFoundation 框架內的，它提供了純 C 函數的 API，所有這些 API 都是線程安全的。 NSRunLoop 是基於 CFRunLoopRef 的封裝，提供了面向對象的 API，但是這些 API 不是線程安全的。

RunLoop 對外的接口

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

CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef

其中 CFRunLoopModeRef 類並沒有對外暴露，只是通過 CFRunLoopRef 的接口進行了封裝。他們的關系如下:

一個 RunLoop 包含若幹個 Mode，每個 Mode 又包含若幹個 Source/Timer/Observer。每次調用 RunLoop 的主函數時，只能指定其中一個 Mode，這個Mode被稱作 CurrentMode。如果需要切換 Mode，只能退出 Loop，再重新指定一個 Mode 進入。這樣做主要是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響。

CFRunLoopSourceRef 是事件產生的地方。Source有兩個版本：Source0 和 Source1。

• Source0 只包含了一個回調（函數指針），它並不能主動觸發事件。使用時，你需要先調用 CFRunLoopSourceSignal(source)，將這個 Source 標記為待處理，然後手動調用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop，讓其處理這個事件。
• Source1 包含了一個 mach_port 和一個回調（函數指針），被用於通過內核和其他線程相互發送消息。這種 Source 能主動喚醒 RunLoop 的線程，其原理在下面會講到。

CFRunLoopTimerRef 是基於時間的觸發器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一個時間長度和一個回調（函數指針）。當其加入到 RunLoop 時，RunLoop會註冊對應的時間點，當時間點到時，RunLoop會被喚醒以執行那個回調。

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 __CFRunLoopMode {
CFStringRef _name;            // Mode Name, 例如 @"kCFRunLoopDefaultMode"
CFMutableSetRef _sources0;    // Set
CFMutableSetRef _sources1;    // Set
CFMutableArrayRef _observers; // Array
CFMutableArrayRef _timers;    // Array
...
};
struct __CFRunLoop {
CFMutableSetRef _commonModes;     // Set
CFMutableSetRef _commonModeItems; // Set<Source/Observer/Timer>
CFRunLoopModeRef _currentMode;    // Current Runloop Mode
CFMutableSetRef _modes;           // Set
...
};

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

應用場景舉例：主線程的 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 裏去。

[[NSRunLoop mainRunLoop] addTimer:self.completionDelayTimer forMode:NSRunLoopCommonModes];

RunLoop 的內部邏輯

根據蘋果在文檔裏的說明，RunLoop 內部的邏輯大致如下:

內部代碼整理如下：

/// 用DefaultMode啟動
void CFRunLoopRun(void) {
    CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}

/// 用指定的Mode啟動，允許設置RunLoop超時時間
int CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean stopAfterHandle) {
    return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}

/// RunLoop的實現
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {

    /// 首先根據modeName找到對應mode
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
    /// 如果mode裏沒有source/timer/observer, 直接返回。
    if (__CFRunLoopModeIsEmpty(currentMode)) return;

    /// 1. 通知 Observers: RunLoop 即將進入 loop。
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);

    /// 內部函數，進入loop
    __CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {

        Boolean sourceHandledThisLoop = NO;
        int retVal = 0;
        do {

            /// 2. 通知 Observers: RunLoop 即將觸發 Timer 回調。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
            /// 3. 通知 Observers: RunLoop 即將觸發 Source0 (非port) 回調。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
            /// 執行被加入的block
            __CFRunLoopDoBlocks(runloop, currentMode);

            /// 4. RunLoop 觸發 Source0 (非port) 回調。
            sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
            /// 執行被加入的block
            __CFRunLoopDoBlocks(runloop, currentMode);

            /// 5. 如果有 Source1 (基於port) 處於 ready 狀態，直接處理這個 Source1 然後跳轉去處理消息。
            if (__Source0DidDispatchPortLastTime) {
                Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
                if (hasMsg) goto handle_msg;
            }

            /// 通知 Observers: RunLoop 的線程即將進入休眠(sleep)。
            if (!sourceHandledThisLoop) {
                __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
            }

            /// 7. 調用 mach_msg 等待接受 mach_port 的消息。線程將進入休眠, 直到被下面某一個事件喚醒。
            /// ? 一個基於 port 的Source 的事件。
            /// ? 一個 Timer 到時間了
            /// ? RunLoop 自身的超時時間到了
            /// ? 被其他什麽調用者手動喚醒
            __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort) {
                mach_msg(msg, MACH_RCV_MSG, port); // thread wait for receive msg
            }

            /// 8. 通知 Observers: RunLoop 的線程剛剛被喚醒了。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);

            /// 收到消息，處理消息。
            handle_msg:

            /// 9.1 如果一個 Timer 到時間了，觸發這個Timer的回調。
            if (msg_is_timer) {
                __CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
            } 

            /// 9.2 如果有dispatch到main_queue的block，執行block。
            else if (msg_is_dispatch) {
                __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
            } 

            /// 9.3 如果一個 Source1 (基於port) 發出事件了，處理這個事件
            else {
                CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
                sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
                if (sourceHandledThisLoop) {
                    mach_msg(reply, MACH_SEND_MSG, reply);
                }
            }

            /// 執行加入到Loop的block
            __CFRunLoopDoBlocks(runloop, currentMode);


            if (sourceHandledThisLoop && stopAfterHandle) {
                /// 進入loop時參數說處理完事件就返回。
                retVal = kCFRunLoopRunHandledSource;
            } else if (timeout) {
                /// 超出傳入參數標記的超時時間了
                retVal = kCFRunLoopRunTimedOut;
            } else if (__CFRunLoopIsStopped(runloop)) {
                /// 被外部調用者強制停止了
                retVal = kCFRunLoopRunStopped;
            } else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
                /// source/timer/observer一個都沒有了
                retVal = kCFRunLoopRunFinished;
            }

            /// 如果沒超時，mode裏沒空，loop也沒被停止，那繼續loop。
        } while (retVal == 0);
    }

    /// 10. 通知 Observers: RunLoop 即將退出。
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}

可以看到，實際上 RunLoop 就是這樣一個函數，其內部是一個 do-while 循環。當你調用 CFRunLoopRun() 時，線程就會一直停留在這個循環裏；直到超時或被手動停止，該函數才會返回。

RunLoop 的底層實現

從上面代碼可以看到，RunLoop 的核心是基於 mach port 的，其進入休眠時調用的函數是 mach_msg()。為了解釋這個邏輯，下面稍微介紹一下 OSX/iOS 的系統架構。

Darwin 即操作系統的核心，包括系統內核、驅動、Shell 等內容。

我們在深入看一下 Darwin 這個核心的架構：

其中，在硬件層上面的三個組成部分：Mach、BSD、IOKit (還包括一些上面沒標註的內容)，共同組成了 XNU 內核。 XNU 內核的內環被稱作 Mach，其作為一個微內核，僅提供了諸如處理器調度、IPC (進程間通信)等非常少量的基礎服務。 BSD 層可以看作圍繞 Mach 層的一個外環，其提供了諸如進程管理、文件系統和網絡等功能。 IOKit 層是為設備驅動提供了一個面向對象(C++)的一個框架。

Mach 本身提供的 API 非常有限，而且蘋果也不鼓勵使用 Mach 的 API，但是這些API非常基礎，如果沒有這些API的話，其他任何工作都無法實施。在 Mach 中，所有的東西都是通過自己的對象實現的，進程、線程和虛擬內存都被稱為”對象”。和其他架構不同， Mach 的對象間不能直接調用，只能通過消息傳遞的方式實現對象間的通信。”消息”是 Mach 中最基礎的概念，消息在兩個端口 (port) 之間傳遞，這就是 Mach 的 IPC (進程間通信) 的核心。

Mach 的消息定義是在 頭文件的，很簡單：

typedef struct {
    mach_msg_header_t header;
    mach_msg_body_t body;
} mach_msg_base_t;
typedef struct {
    mach_msg_bits_t msgh_bits;
    mach_msg_size_t msgh_size;
    mach_port_t msgh_remote_port;
    mach_port_t msgh_local_port;
    mach_port_name_t msgh_voucher_port;
    mach_msg_id_t msgh_id;
} mach_msg_header_t;

一條 Mach 消息實際上就是一個二進制數據包 (BLOB)，其頭部定義了當前端口 localport 和目標端口 remoteport，一條 Mach 消息實際上就是一個二進制數據包 (BLOB)，其頭部定義了當前端口 localport 和目標端口 remoteport，

mach_msg_return_t mach_msg(
        mach_msg_header_t *msg,
        mach_msg_option_t option,
        mach_msg_size_t send_size,
        mach_msg_size_t rcv_size,
        mach_port_name_t rcv_name,
        mach_msg_timeout_t timeout,
        mach_port_name_t notify);

為了實現消息的發送和接收，machmsg() 函數實際上是調用了一個 Mach 陷阱 (trap)，即函數machmsgtrap()，陷阱這個概念在 Mach 中等同於系統調用。當你在用戶態調用 machmsgtrap() 時會觸發陷阱機制，切換到內核態；內核態中內核實現的 machmsg() 函數會完成實際的工作，如下圖：

RunLoop 的核心就是一個 machmsg() (見上面代碼的第7步)，RunLoop 調用這個函數去接收消息，如果沒有別人發送 port 消息過來，內核會將線程置於等待狀態。例如你在模擬器裏跑起一個 iOS 的 App，然後在 App 靜止時點擊暫停，你會看到主線程調用棧是停留在 machmsg_trap() 這個地方。

五 蘋果用 RunLoop 實現的功能

首先我們可以看一下 App 啟動後 RunLoop 的狀態：

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),
        }
    }
}

可以看到，系統默認註冊了5個Mode:

1. kCFRunLoopDefaultMode: App的默認 Mode，通常主線程是在這個 Mode 下運行的。
2. UITrackingRunLoopMode: 界面跟蹤 Mode，用於 ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他 Mode 影響。
3. UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode，啟動完成後就不再使用。
4. GSEventReceiveRunLoopMode: 接受系統事件的內部 Mode，通常用不到。
5. kCFRunLoopCommonModes: 這是一個占位的 Mode，沒有實際作用。

AutoreleasePool

App啟動後，蘋果在主線程 RunLoop 裏註冊了兩個 Observer，其回調都是 _wrapRunLoopWithAutoreleasePoolHandler()。

第一個 Observer 監視的事件是 Entry(即將進入Loop)，其回調內會調用 objcautoreleasePoolPush() 創建自動釋放池。其 order 是-2147483647，優先級最高，保證創建釋放池發生在其他所有回調之前。

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

在主線程執行的代碼，通常是寫在諸如事件回調、Timer回調內的。這些回調會被 RunLoop 創建好的 AutoreleasePool 環繞著，所以不會出現內存泄漏，開發者也不必顯示創建 Pool 了。

事件響應

蘋果註冊了一個 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 事件都是在這個回調中完成的。

註意：事件響應請關註後續的響應鏈分享！

手勢識別

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

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

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

question：為什麽要在Loop即將進入休眠的時候執行GestureRecognizer的回調

界面更新

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

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

這個函數內部的調用棧大概是這樣的：

_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];
                            

Tip：當想強制刷新的時候，可以將UIView的setNeedsLayout置為YES，然後布局【view layoutIfNeeded】； 註意：界面更新請關註後續的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 相似），造成界面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題，其內部也用到了 RunLoop。

註意兩點：

• UIScrollView上的NSTimer
• 子線程使用NSTimer要加入到RunLoop中

思考:如何寫一個相對準確的定時器

PerformSelecter

當調用 NSObject 的 performSelecter:afterDelay: 後，實際上其內部會創建一個 Timer 並添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，則這個方法會失效。

當調用 performSelector:onThread: 時，實際上其會創建一個 Timer 加到對應的線程去，同樣的，如果對應線程沒有 RunLoop 該方法也會失效。

demo出現問題 TODO-WT

關於GCD

實際上 RunLoop 底層也會用到 GCD 的東西。但同時 GCD 提供的某些接口也用到了 RunLoop， 例如 dispatch_async()。

當調用 dispatchasync(dispatchgetmainqueue(), block) 時，libDispatch 會向主線程的 RunLoop 發送消息，RunLoop會被喚醒，並從消息中取得這個 block，並在回調 CFRUNLOOPISSERVICINGTHEMAINDISPATCHQUEUE() 裏執行這個 block。但這個邏輯僅限於 dispatch 到主線程，dispatch 到其他線程仍然是由 libDispatch 處理的。

請看《RunLoop 的內部邏輯》的內部代碼整理

關於網絡請求

iOS 中，關於網絡請求的接口自下至上有如下幾層:

CFSocket
CFNetwork       ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession    ->AFNetworking2, Alamofire

• CFSocket 是最底層的接口，只負責 socket 通信。
• CFNetwork 是基於 CFSocket 等接口的上層封裝，ASIHttpRequest 工作於這一層。
• NSURLConnection 是基於 CFNetwork 的更高層的封裝，提供面向對象的接口，AFNetworking 工作於這一層。
• NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 並列的，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)，AFNetworking2 和 Alamofire 工作於這一層。

下面主要介紹下 NSURLConnection 的工作過程。

通常使用 NSURLConnection 時，你會傳入一個 Delegate，當調用了 [connection start] 後，這個 Delegate 就會不停收到事件回調。實際上，start 這個函數的內部會會獲取 CurrentRunLoop，然後在其中的 DefaultMode 添加了4個 Source0 (即需要手動觸發的Source)。CFMultiplexerSource 是負責各種 Delegate 回調的，CFHTTPCookieStorage 是處理各種 Cookie 的。

當開始網絡傳輸時，我們可以看到 NSURLConnection 創建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的。NSURLConnectionLoader 這個線程內部會使用 RunLoop 來接收底層 socket 的事件，並通過之前添加的 Source0 通知到上層的 Delegate。

NSURLConnectionLoader 中的 RunLoop 通過一些基於 mach port 的 Source 接收來自底層 CFSocket 的通知。當收到通知後，其會在合適的時機向 CFMultiplexerSource 等 Source0 發送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執行實際的回調。

六 本次分享要解決的問題，使用RunLoop實現常駐線程

舉個例子： AFURLConnectionOperation 這個類是基於 NSURLConnection 構建的，其希望能在後臺線程接收 Delegate 回調。為此 AFNetworking 單獨創建了一個線程，並在這個線程中啟動了一個 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 啟動前內部必須要有至少一個 Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先創建了一個新的 NSMachPort 添加進去了。通常情況下，調用者需要持有這個 NSMachPort (mach_port) 並在外部線程通過這個 port 發送消息到 loop 內；但此處添加 port 只是為了讓 RunLoop 不至於退出，並沒有用於實際的發送消息。

- (void)start {
    [self.lock lock];
    if ([self isCancelled]) {
        [self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    } else if ([self isReady]) {
        self.state = AFOperationExecutingState;
        [self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    }
    [self.lock unlock];
}

當需要這個後臺線程執行任務時，AFNetworking 通過調用 [NSObject performSelector:onThread:..] 將這個任務扔到了後臺線程的 RunLoop 中。

再談RunLoop