自動釋放池(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
複製程式碼對於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 的介面進行了封裝。關係如下:
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:
- kCFRunLoopDefaultMode: App的預設 Mode，通常主執行緒是在這個 Mode 下執行的。
- UITrackingRunLoopMode: 介面跟蹤 Mode，用於 ScrollView 追蹤觸控滑動，保證介面滑動時不受其他 Mode 影響。
- UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode，啟動完成後就不再使用。
- GSEventReceiveRunLoopMode: 接受系統事件的內部 Mode，通常用不到。
- 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 處理的。