iOS開發 自動釋放池(Autorelease Pool)和RunLoop

自動釋放池(Autorelease Pool)

先看一個例子：

#import "SecViewController.h"
__weak NSString *stringA = nil;
__weak NSString *stringB = nil;
__weak NSString *stringC = nil;

@implementation SecViewController

- (void)viewDidLoad
{
    [super viewDidLoad];
    self.view.backgroundColor = [UIColor redColor];
    
    NSString *strA = [NSString stringWithFormat:@"biubiu李2017_A"];
    stringA = strA;
    
    @autoreleasepool
    {
        NSString *strB = [NSString stringWithFormat:@"biubiu李2017_B"];
        stringB = strB;
    }
    
    NSString *strC= nil;
    
    @autoreleasepool
    {
        strC = [NSString stringWithFormat:@"biubiu李2017_C"];
        stringC = strC;
    }
    
    NSLog(@"viewDidLoad");
    [self showStrings];
}

-(void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
     NSLog(@"viewWillAppear");
     [self showStrings];
}

-(void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];
    NSLog(@"viewDidAppear");
    [self showStrings];
}

-(void)showStrings
{
    NSLog(@"stringA: %@", stringA);
    NSLog(@"stringB: %@", stringB);
    NSLog(@"stringC: %@", stringC);
    NSLog(@"\n");
}

複製代碼

這段程序會輸出什麼呢？

分析： 咱們經過 [NSString stringWithFormat:@"biubiu李2017_C"] 建立了一個 autoreleased 對象。爲了可以在 viewWillAppear 和 viewDidAppear 中繼續訪問這個對象，使用了一個全局的 __weak 變量來指向它。由於 __weak 變量有一個特性就是它不會影響所指向對象的生命週期，正是利用了這個特性。

對於stringA

對於stringB 當經過 [NSString stringWithFormat:@"biubiu李2017_C"] 建立一個對象時，這個對象的引用計數爲 1 。而當使用局部變量 strB 指向這個對象時，這個對象的引用計數 +1 ，變成了 2 。而出了當前做用域時，局部變量 strB 變成了 nil ，因此其所指向對象的引用計數變成 1 。當出了 @autoreleasepool {} 的做用域時，當前 autoreleasepool 被 drain ，其中的 autoreleased 對象被 release 。因此這個對象的引用計數變成了 0 ，對象最終被釋放。

能夠經過使用 lldb 的 watchpoint 命令來設置觀察點，觀察全局變量 stringB 的值的變化，stringB 變量保存的就是咱們建立的 autoreleased 對象的地址。

//在 console 中看到相似的輸出，說明咱們已經成功地設置了一個觀察點stringB
(lldb) watchpoint set variable stringB
Watchpoint created: Watchpoint 1: addr = 0x10255d228 size = 8 state = enabled type = w
    declare @ '/Users/biubiu03/test/biubiuTest/SecViewController.m:12'
    watchpoint spec = 'stringB'
    new value: 0x0000000000000000
(lldb) 
複製代碼

設置好觀察點後，點擊 Continue program execution 按鈕，繼續運行程序

(lldb) watchpoint set variable stringB
Watchpoint created: Watchpoint 1: addr = 0x10255d228 size = 8 state = enabled type = w
    declare @ '/Users/biubiu/1_Code/test/biubiuTest/SecViewController.m:12'
    watchpoint spec = 'stringB'
    new value: 0x0000000000000000

Watchpoint 1 hit:
old value: 0x0000000000000000
new value: 0x00000001c04654c0
2017-10-30 16:45:19.766498+0800 biubiuTest[2606:622193] XPC connection interrupted

Watchpoint 1 hit:
old value: 0x00000001c04654c0
new value: 0x0000000000000000
複製代碼

看左側的線程堆棧。AutoreleasePoolPage::pop(void *) 函數來負責對 autoreleasepool 中的 autoreleased 對象執行 release 操做。

對於stringC 當出了 @autoreleasepool {} 的做用域時，其中的 autoreleased 對象被 release ，對象的引用計數變成 1 。當出了局部變量 strC 的做用域，即 viewDidLoad 方法返回時，strC 指向了 nil ，其所指向對象的引用計數變成 0 ，對象最終被釋放。

AutoreleasePoolPage

Autoreleasepool 是沒有單獨的內存結構的，它是經過以 AutoreleasePoolPage 爲結點的雙向鏈表來實現的。打開 runtime 的源碼工程，在 NSObject.mm 文件能夠找到 autoreleasepool 的實現源碼。

1.每個線程的 autoreleasepool 其實就是一個指針的堆棧； 2.每個指針表明一個須要 release 的對象或者 POOL_SENTINEL（哨兵對象，表明一個 autoreleasepool 的邊界）； 3.一個 pool token 就是這個 pool 所對應的 POOL_SENTINEL 的內存地址。當這個 pool 被 pop 的時候，全部內存地址在 pool token 以後的對象都會被 release ； 4.這個堆棧被劃分紅了一個以 page 爲結點的雙向鏈表。pages 會在必要的時候動態地增長或刪除； 5.Thread-local storage（線程局部存儲）指向 hot page ，即最新添加的 autoreleased 對象所在的那個 page 。 總結一下：

4K每頁的自動釋放池頁面，
頁面與頁面之間雙向鏈表連接，
以棧形式使用，
頁面惰性建立，
每一個線程都有本身的自動釋放池，
大部分時間使用池頂（hotPage)。
複製代碼

1.magic 用來校驗 AutoreleasePoolPage 的結構是否完整； 2.next 指向最新添加的 autoreleased 對象的下一個位置，初始化時指向 begin() ； 3.thread 指向當前線程； 4.parent 指向父結點，第一個結點的 parent 值爲 nil ； 5.child 指向子結點，最後一個結點的 child 值爲 nil ； 6.depth 表明深度，從 0 開始，日後遞增 1； 7.hiwat 表明 high water mark 。 8.另外，當 next == begin() 時，表示 AutoreleasePoolPage 爲空；當 next == end() 時，表示 AutoreleasePoolPage 已滿。

RunLoop

RunLoop概念

當APP啓動後，系統會自動建立一個線程來執行任務，該線程被稱爲主線程或者UI線程。在主線程建立的時候，系統還會爲主線程建立並啓動一種機制（其實就是一個對象，該對象和應用的生命週期有關），叫作RunLoop，被稱爲運行循環機制。 通常來說，一個線程一次只能執行一個任務，執行完成後線程就會退出。若是咱們須要一個機制，讓線程能__隨時處理事件__但並不退出，一般的代碼邏輯是這樣的：

function loop() 
{
    initialize();

    do {
        var message = get_next_message();
        process_message(message);

    } while (message != quit);
}
複製代碼

這種模型一般被稱做 Event Loop。 Event Loop 在不少系統和框架裏都有實現，好比 Node.js 的事件處理，好比 Windows 程序的消息循環，再好比 OSX/iOS 裏的 RunLoop。 實現這種模型的關鍵點在於： 如何管理事件/消息，如何讓線程在沒有處理消息時休眠以免資源佔用、在有消息到來時馬上被喚醒。

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

OSX/iOS 系統中，提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef。

CFRunLoopRef 是在 CoreFoundation 框架內的，它提供了純 C 函數的 API，全部這些 API 都是線程安全的。 NSRunLoop 是基於 CFRunLoopRef 的封裝，提供了面向對象的 API，可是這些 API 不是線程安全的。

CFRunLoopRef代碼  整個 CoreFoundation 的源碼下載地址  爲了方便跟蹤和查看，能夠新建一個 Xcode 工程，把這堆源碼拖進去看。

RunLoop 與線程的關係

iOS 開發中能遇到兩個線程對象: pthread_t 和 NSThread。過去蘋果有份文檔標明瞭 NSThread 只是 pthread_t 的封裝，但那份文檔已經失效了，如今它們也有可能都是直接包裝自最底層的 mach thread。蘋果並無提供這兩個對象相互轉換的接口，但無論怎麼樣，能夠確定的是 pthread_t 和 NSThread 是一一對應的。好比，你能夠經過 pthread_main_np() 或 [NSThread mainThread] 來獲取主線程；也能夠經過 pthread_self() 或 [NSThread currentThread] 來獲取當前線程。 CFRunLoop 是基於 pthread 來管理的。 蘋果不容許直接建立 RunLoop，它只提供了兩個自動獲取的函數：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 這兩個函數內部的邏輯大概是下面這樣:

//全局的字典，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);
    }
     
    /// 直接從 loopsDic 裏獲取。
    CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
     
    if (!loop) 
{
        // 取不到時，建立一個
        loop = _CFRunLoopCreate();
        CFDictionarySetValue(loopsDic, thread, loop);

        // 註冊一個回調，當線程銷燬時，順便也銷燬其對應的 RunLoop。
        _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
    }
     
    OSSpinLockUnLock(&loopsLock);//開鎖
    return loop;
}
複製代碼

//獲取MainRunLoop
CFRunLoopRef CFRunLoopGetMain() 
{
    return _CFRunLoopGet(pthread_main_thread_np());
}
複製代碼

//獲取當前RunLoop
CFRunLoopRef CFRunLoopGetCurrent()
 {
    return _CFRunLoopGet(pthread_self());
}
複製代碼

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
    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 裏去。

CFRunLoop對外暴露的管理 Mode 接口只有下面2個:

CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);
複製代碼

Mode 暴露的管理 mode item 的接口有下面幾個：

CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopAddObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopAddTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
CFRunLoopRemoveSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopRemoveObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopRemoveTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
複製代碼

你只能經過 mode name 來操做內部的 mode，當你傳入一個新的 mode name 但 RunLoop 內部沒有對應 mode 時，RunLoop會自動幫你建立對應的 CFRunLoopModeRef。對於一個 RunLoop 來講，其內部的 mode 只能增長不能刪除。

蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，你能夠用這兩個 Mode Name 來操做其對應的 Mode。

同時蘋果還提供了一個操做 Common 標記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你能夠用這個字符串來操做 Common Items，或標記一個 Mode 爲 "Common"。使用時注意區分這個字符串和其餘 mode name。

RunLoop 的內部邏輯 根據蘋果在文檔裏的說明，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 的系統架構。

蘋果官方將整個系統大體劃分爲上述4個層次：

1.應用層包括用戶能接觸到的圖形應用，例如 Spotlight、Aqua、SpringBoard 等。

2.應用框架層即開發人員接觸到的 Cocoa 等框架。

3.核心框架層包括各類核心框架、OpenGL 等內容。

4.Darwin 即操做系統的核心，包括系統內核、驅動、Shell 等內容， 這一層是開源的，其全部源碼均可以在 蘋果opensource 裏找到。

看一下 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)，其頭部定義了當前端口 local_port 和目標端口 remote_port，

發送和接受消息是經過同一個 API 進行的，其 option 標記了消息傳遞的方向：

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);
複製代碼

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

這些概念能夠參考維基百科: System_call、Trap_(computing)。 RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)，RunLoop 調用這個函數去接收消息，若是沒有別人發送 port 消息過來，內核會將線程置於等待狀態。 例如你在模擬器裏跑起一個 iOS 的 App，而後在 App 靜止時點擊暫停，你會看到主線程調用棧是停留在 mach_msg_trap() 這個地方。 關於具體的如何利用 mach port 發送信息，能夠看看  NSHipster 這一篇文章，或者這裏的中文翻譯 。 關於Mach的歷史能夠看看這篇頗有趣的文章：Mac OS X 背後的故事（ 三）Mach 之父 Avie Tevanian。

蘋果用 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，沒有實際做用。

你能夠在CFRunLoop看到更多的蘋果內部的 Mode，但那些 Mode 在開發中就很難遇到了。

當 RunLoop 進行回調時，通常都是經過一個很長的函數調用出去 (call out), 當你在你的代碼中下斷點調試時，一般能在調用棧上看到這些函數。下面是這幾個函數的整理版本，若是你在調用棧中看到這些長函數名，在這裏查找一下就能定位到具體的調用地點了：

{
    /// 1. 通知Observers，即將進入RunLoop
    /// 此處有Observer會建立AutoreleasePool: _objc_autoreleasePoolPush();
    __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
    do {
  
        /// 2. 通知 Observers: 即將觸發 Timer 回調。
        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
        /// 3. 通知 Observers: 即將觸發 Source (非基於port的,Source0) 回調。
        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
  
        /// 4. 觸發 Source0 (非基於port的) 回調。
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
  
        /// 6. 通知Observers，即將進入休眠
        /// 此處有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喚醒的，回調Timer
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
  
        /// 9. 若是是被dispatch喚醒的，執行全部調用 dispatch_async 等方法放入main queue 的 block
        __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block);
  
        /// 9. 若是若是Runloop是被 Source1 (基於port的) 的事件喚醒了，處理這個事件
        __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);
}
複製代碼

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，優先級最低，保證其釋放池子發生在其餘全部回調以後。

在主線程執行的代碼，一般是寫在諸如事件回調、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 的變化(建立/銷燬/狀態改變)時，這個回調都會進行相應處理。

界面更新

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

蘋果註冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調去執行一個很長的函數：

_ZN2CA11Transaction17observer_callbackEP19__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];
複製代碼

定時器

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。

PerformSelecter

當調用 NSObject 的 performSelecter:afterDelay: 後，實際上其內部會建立一個 Timer 並添加到當前線程的 RunLoop 中。因此若是當前線程沒有 RunLoop，則這個方法會失效。

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

關於GCD

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

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