?iOS 中RunLoop 是一個事件循環對象
runloop?跑一圈，只能執行一個事件。
一般一個線程執行任務完成后線程就會退出。如果需要在這個線程里多次執行任務，可能就會不停的創建，銷毀線程，這樣CPU消耗很大。如果可以讓線程不退出并且能隨時處理事件：
do { ? ? ? ? ?
?????//接受消息->等待->處理 ??
? ?} ????while(message != quit)
線程執行了這個函數后，就會一直處于這個函數內部 "接受消息->等待->處理" 的循環中，直到這個循環結束（比如傳入 quit 的消息），函數返回。
當啟動一個iOS APP時主線程對應的RunLoop被主動開啟。如果不殺掉APP則APP一直運行，就是因為RunLoop保證主線程不會被銷毀。保證線程不退出。
RunLoop在循環過程中監聽事件，當前線程有任務時，喚醒線程執行任務，任務執行完成以后，使當前線程進入休眠狀態。當然這里的休眠不同于自己寫的死循環(while(1);)，它在休眠時幾乎不會占用系統資源，是由操作系統內核負責實現的。
CFRunLoopRef ?& ?NSRunLoop
?CoreFoundation 框架為 CFRunLoopRef 對象，它提供了純 C 函數的 API，是線程安全的；
?Foundation 框架中用 NSRunLoop 對象，是基于 CFRunLoopRef 的封裝，提供面向對象的 API，不是線程安全的。要避免在其他線程上調用當前線程的RunLoop
RunLoop 的創建是發生在第一次獲取時，RunLoop 的銷毀是發生在線程結束時。只能在一個線程的內部獲取其 RunLoop（主線程除外）。
CFRunLoopModeRef
1. 一個Runloop對應一條線程，一一對應，以線程作為key, runloop 作為value 存在在一個全局字典中。
2. 一個runloop里面可以有多個CFRunLoopMode (模式），每一個mode又可以包含多個 source/timer/observer。
3. 每次調用 RunLoop 時，只能指定其中一個 Mode，這個Mode被稱作 CurrentMode。
注意：如果需要切換 Mode，只能退出 RunLoop，再重新指定一個 Mode 進入。是為了分隔開不同mode下的 Source/Timer/Observer，讓其互不影響
4. 一個 RunLoop 在某個 mode 下運行時，不會接收和處理其他 mode 的事件?
5. 一個modeitem(Source/Timer/Observer) 可以被同時加入多個 mode。但一個 item 被重復加入同一個 mode 時是不會有效果的。
6. 如果runloop 指定運行的 mode 中一個 item 都沒有，RunLoop 會直接退出，不進入循環。
kCFRunLoopCommonModes?
1. CFRunLoop里面有一個?偽mode?叫做 kCFRunLoopCommonModes，它不是一個真正的 mode，而是若干個 mode 的集合（NSSet）。
注意：Run Loop不能在運行在 NSRunLoopCommonModes 模式，它不是一個具體的模式。
2. 一個modeitem(Source/Timer/Observer)?只要加入CommonModes 里面，就相當于添加到了CommonModes 里面所有的 mode 中。
注意：在iOS系統中主線程CommonMode默認包含了 NSDefaultRunLoopMode ?和 UITrackingRunLoopMode。子線程CommonMode中只包含NSDefaultRunLoopMode。
3. 一個 Mode 可以將自己標記為”Common”屬性（通過將其 ModeName 添加到 RunLoop 的 “commonModes” 中)。?
// 添加mode 將自定義Model添加到CFRunLoopCommonModes
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
注意：當 RunLoop 的model 發生變化時，RunLoop 都會自動將 commonModeItems 里的 Source/Observer/Timer 同步到具有 “Common” 標記的所有Mode里，（把CommonModes中所有的modelItem 分別加進 CommonModes 集合中的所有model下）。即使RunLoop切換model，modelitem 可以實現在多種model 下執行，不受model 變化的影響。?
4. 添加事件源的時候添加到 NSRunLoopCommonModes，只要Run Loop運行在NSRunLoopCommonModes 中任何一個模式，這個事件源都可以被觸發
5. 只能通過 mode name 來操作runLoop內部的 mode，當傳入一個新的 mode name 但 RunLoop 內部沒有對應 mode 時，RunLoop會自動創建對應的 CFRunLoopModeRef。
6. 對于 RunLoop 其內部的 mode 只能增加不能刪除。
日常使用場景：
程序應用大部分情況下是處于NSDefaultRunLoopMode狀態，只有當scrollView滑動時，主線程RunLoop 會自動切換為UITrackingRunLoopMode狀態。
不同的mode 影響到設置的監聽者（比如Timer或CADisplayLink）是否會被回調。比如在主線程中，設置Timer為NSDefaultRunLoopMode屬性，當應用在滑動時，Timer的方法是不會被回調的，因為滑動過程中，RunLoop會切換為UITrackingRunLoopMode狀態，而它只是監聽了NSDefaultRunLoopMode狀態。只有mainRunLoop才會在滑動時，切換為UITrackingRunLoopMode，子線程中的RunLoop是不會的。
在主線程中設置Timer或CADisplayLink，我們通常都會設置為NSRunLoopCommonModes屬性，表示在NSDefaultRunLoopMode和UITrackingRunLoopMode狀態下都會進行監聽，避免滑動時，無法回調。
mode的切換，目前無法得知系統是如何進行切換的。從源碼中發現的事實，切換的時候，會加鎖保證多線程安全，并且有三處切換：
sleep 之前，runloop 可能一覺醒來，發現 mode 已經物是人非。
doMainQueue 之前，執行完 GCD main queue 中的任務后，mode 也能會發生變化。
在 CFRunLoopRunSpecific 函數，也就是 runloop exit 之后。
RunLoop退出的條件
1. app退出，線程關閉，被外部調用強制停止CFRunLoopStop()
2. 設置最大時間到期；kCFRunLoopRunTimedOut
3. modeItem為空；kCFRunLoopRunFinished
4. 參數說處理完事件就返回 ?kCFRunLoopRunHandledSource，啟動Runloop時設置參數為一次性執行
CFRunLoopSourceRef ??
source 是事件產生的地方（輸入源），分為三類，輸入源向線程發送異步消息
1. ?Port-Based Sources: ? ?source1 ，基于Port，通過內核和其他線程通信，則是用來接收、分發系統事件，然后再分發到Sources0中處理的
2. ?Custom Input Sources: ? 自定義source0 相關 ，可處理UIKit 的 UIEvent 事件
3. Cocoa Perform Selector Sources: ? 與PerformSEL方法相關?
源碼中 source分為：source0和source1，區別在于它們是怎么被標記 (signal) 的。
source0?是 app 內部的消息機制，只包含了一個回調（函數指針），它并不能主動觸發事件。使用時，你需要先調用 CFRunLoopSourceSignal(source)，將這個 Source標記為待處理，然后手動調用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop，讓其處理這個事件。
source1?是基于端口 的，包含了一個 mach_port 和一個回調（函數指針），用于通過內核和其他線程相互發送消息。監聽程序相應的端口，能主動喚醒 RunLoop 的線程.
Run loop處理的輸入事件有兩種不同的來源：輸入源（input source）和定時源（timer source）。輸入源傳遞異步消息，通常來自于其他線程或者程序。定時源則傳遞同步消息，在特定時間或者一定的時間間隔發生。
PerformSelecter：執行完后會自動清除出run loop。
當調用 NSObject 的 performSelecter:afterDelay: 后，實際上其內部會創建一個 Timer 并添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，方法會失效。
使用場景：事件響應
蘋果注冊了一個 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 變化(創建/銷毀/狀態改變)時，回調都會進行處理。
定時器：CFRunLoopTimerRef--系統內“定時鬧鐘”
定時源在預設的時間點同步方式傳遞消息。定時器是線程通知自己做某事的一種方法。定時器是基于時間的通知，并不實時機制。
例如，搜索控件可以使用定時器，當用戶連續輸入的時間超過一定時間時，就開始一次搜索。這樣，用戶就可以有足夠的時間來輸入想要搜索的關鍵字。
NSTimer ?和 ?performSEL ?方法實際上是對CFRunloopTimerRef的封裝；
GCD的timer：dispatch_source_t?類型，不用runloop和mode，性能消耗更小。
dispatch_source_set_timer(dispatch_source_t source, // 定時器對象
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dispatch_time_t start, // 定時器開始執行的時間
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? uint64_t interval, // 定時器的間隔時間
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? uint64_t leeway // 定時器的精度
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? );
1. 如果定時器所在的模式 不是 runloop的currentmodel，那么定時器將不會執行，直到 runloop運行在定時器所在的mode 模式下。
2. 如果定時器在runloop處理某一事件期間開始，定時器會一直等待直到下次runloop開始相應的處理程序，如果runloop不運行了，那么定時器也永遠不啟動。
3. 如果timer 添加的線程未開啟runloop , timer 就不會被執行。
在子線程中將NSTimer以默認方式加到該線程的runloop中，啟動子線程
4. 注意內存泄漏，循環引用的問題。
一個 NSTimer 注冊到 RunLoop 后，RunLoop 會為其重復的時間點注冊好事件。如果某個時間點被錯過了，例如執行了一個很長的任務，對應時間點的回調會被跳過去，不會延后執行。就比如等公交，如果 10:10 時玩手機錯過了，那只能等 10:20 的了。
注意：RunLoop為了節省資源，并不會在非常準確的時間點回調這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后，容許有多少最大誤差。
CADisplayLink：和屏幕刷新率一致的定時器，一秒刷新60次。
和 NSTimer 不一樣，其內部實際是操作了一個 Source。
CADisplayLink以特定模式注冊到runloop后，每當屏幕顯示內容刷新結束的時候，runloop就會向CADisplayLink指定的target發送一次指定的selector消息， CADisplayLink類對應的selector就會被調用一次。所以通常情況下，按照iOS設備屏幕的刷新率60次/秒
CADisplayLink 在正常情況下會在屏幕每次刷新結束后調用，精確度相當高。如果CPU過于繁忙，無法保證屏幕60次/秒的刷新率，就會導致跳過若干次調用回調方法的機會，跳過次數取決CPU的忙碌程度。
CADisplayLink 使用場合相對專一， 適合做界面的不停重繪，比如視頻播放的時候需要不停地獲取下一幀用于界面渲染。
定時器定時工作注意：定時器會基于安排好的時間而非實際時間，自動的開始。
注意：比如安排好了： 5，10，15，20 ...分別執行一次任務，如果定時器延遲到 10分的時候才開始任務，定時器在5-10這個時間段中也只會啟動一次，之后按照預設的時間點正常運行15，20....。
NSTimer 和?CADisplayLink的區別?：
1.?CADisplayLink - 簡介 - 簡書? ? 2. ? ??三個定時器之間的區別?
Runloop本質：mach port 和 ?mach_msg()
IOKit 層是為設備驅動提供了一個面向對象(C++)的一個框架。
在 Mach 中，進程、線程和虛擬內存都被稱為”對象”。 Mach 的對象間不能直接調用，只能通過消息傳遞的方式實現對象間的通信。”消息”是 Mach 中最基礎的概念，消息在兩個端口 (port) 之間傳遞，這就是 Mach 的 IPC (進程間通信) 的核心。
1條 Mach 消息實際上就是一個二進制數據包 (BLOB)，其頭部定義了當前端口 local_port 和目標端口 remote_port。（Source1是基礎端口，它就是依靠系統發送消息到指定的Port來觸發的）。
1. 通過 msg 函數 決定Runloop是否休眠等待：調用mach_msg( )?函數接收消息，如果沒有 port 消息過來，內核會將線程置于等待狀態。
2.?一個是通過判斷退出條件來決定Runloop是否循環。
在空閑前指定用于喚醒的 mach port 端口，空閑時被 mach_msg() 函數阻塞著并監聽喚醒端口， mach_msg() 又會調用 mach_msg_trap() 函數從用戶態切換到內核態，系統內核就將這個線程掛起，一直停留在 mac_msg_trap 狀態。直到另一個線程向內核發送這個端口的 msg ，trap 狀態被喚醒。 RunLoop 繼續工作。（當有消息返回時，當前線程被阻塞，系統內核開辟一條新的線程去返回這個消息）
程序休眠時，RunLoop停留在 _CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy) ? 這個函數內部就是調用了mach_msg 讓程序處于休眠狀態。
runloop & NSThread?
1. runloop 和 pthread_t （也就是線程）是一一對應的, 對應關系是保存在一個全局的 dictionary 中，key是pthread_t ， value是相對應的RunLoop 。
2. 在子線程中調用 ?：NSRunLoop*runloop= [NSRunLoop currentRunLoop];?
原理： 獲取RunLoop對象的時候，會先看一下全局字典里有沒有存子線程相對應的RunLoop，如果有直接返回，沒有會創建一個，并將與之對應的子線程存入字典中。
3. ?RunLoop是一個懶加載機制，子線程的runloop默認不創建。?如果不主動獲取，那子線程內的RunLoop一直不會存在。
4. 當線程結束銷毀的時候，也銷毀相應的 runloop。
5.?啟動一個APP時主線程對應的RunLoop 會被主動開啟
關于GCD 和?RunLoop 交互
RunLoop 底層會用到 GCD 的東西，GCD 的某些 API 也用到了 RunLoop。runloop啟動時設置的最大超時時間實際上是GCD的dispatch_source_t類型。
當調用 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主線程的 RunLoop 發送消息，RunLoop會被喚醒，并從消息中取得這個 block，并在回調 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里執行這個 block。但這個邏輯僅限于 dispatch 到主線程，dispatch 到其他線程仍然是由 libDispatch 處理的。
?Runloop即將進入休眠，會重繪一次界面
<CFRunLoopObserver> {?
? ? ?activities=0xa0,
?????callout=_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv?
}
準備進入睡眠和即將退出 loop?兩個時間點，會調用函數更新 UI 界面。?UI的繪制是拿到所有之后，在統一繪制的。
當在操作 UI 時，某個需要變化的 UIView/CALayer 就被標記為待處理，然后被提交到一個全局的容器去，再在上面的回調執行時才會被取出來進行繪制和調整。
UI 線程中一旦出現繁重的任務就會導致界面卡頓，這類任務通常分為3類：排版，繪制，UI對象操作。
排版通常包括計算視圖大小、計算文本高度、重新計算子式圖的排版等操作。
繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預先解壓)、元素繪制 (Quartz)等操作。
UI對象操作通常包括 UIView/CALayer 等 UI 對象的創建、設置屬性和銷毀。
其中前兩類操作可以通過各種方法扔到后臺線程執行，而最后一類操作只能在主線程完成，并且有時后面的操作需要依賴前面操作的結果 （例如TextView創建時可能需要提前計算出文本的大小）。盡量將能放入后臺的任務放入后臺，不能的則盡量推遲 (例如視圖的創建、屬性的調整)。
CFRunLoopObserverRef
CFRunLoopObserverRef：消息循環中的一個監聽器，監聽runloop狀態。隨時通知外部當前RunLoop的運行狀態（它包含一個函數指針callout將當前狀態及時告訴觀察者）
數據結構:
// Observer：order(優先級)，ativity(監聽狀態)，callout(回調函數)
CFRunLoopObserver {order = ..., activities = ..., callout = ...}
Observer監聽 6 種狀態：?
?1. kCFRunLoopEntry = (1UL << 0), ? ? ? ? ? ? ? ?// 進入RunLoop
?2. ?kCFRunLoopBeforeTimers = (1UL << 1), ? ? ? ?// 即將開始Timer處理
3. ?kCFRunLoopBeforeSources = (1UL << 2), ? ? ? // 即將開始Source處理
4. ?kCFRunLoopBeforeWaiting = (1UL << 5), ? ? ? ?// 即將進入休眠
5. ?kCFRunLoopAfterWaiting = (1UL << 6), ? ? ? ? //從休眠狀態喚醒
6. ? kCFRunLoopExit = (1UL << 7), ? ? ? ? ? ? ? ? ? ? ?//退出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，優先級最低，保證其釋放池子發生在其他所有回調之后。
在主線程執行的代碼，通常是寫在事件回調、Timer回調內的。這些回調會被 RunLoop 創建好的 AutoreleasePool 環繞著，不會出現內存泄漏，開發者也不必顯示創建 Pool 了。
runloop 使用解決問題：
RunLoop總結：RunLoop的應用場景（三）_weixin_30437481的博客-CSDN博客?tableview刷新圖片加載卡頓問題優化。
iOS - 聊聊 autorelease 和 @autoreleasepool_移動開發_weixin_42350379的博客-CSDN博客
淺析RunLoop原理及其應用 – ITPUB??tableview滑動時 刷新cell 圖片加載卡頓問題優化。
計時器相關:
?iOS的三種常見計時器（NStimer、CADisplayLink、dispatch_source_t）的使用_馬拉薩的春天的博客-CSDN博客_ios 計時器
參考：
線程出錯引起什么問題，面試問到：
OS / 進程中某個線程崩潰，是否會對其他線程造成影響？_布袋和尚-CSDN博客
（最全）RunLoop 原理+使用場景+面試總結 - 簡書? ??????????
iOS runloop的深入淺出，runloop的理解看這里就夠了_移動開發_horisea的博客-CSDN博客
深入淺出 RunLoop（一）：初識_移動開發_weixin_42350379的博客-CSDN博客
RunLoop_RunLoop_xiaoxiaobukuang的專欄-CSDN博客
