碼上快樂

相關內容    簡體    繁體

iOS---RunLoop深度剖析

本文轉載自   查看原文   2015-07-14 13:04   2842    iOSRunLoop/ RunLoop

RunLoop

前言

  • RunLoop是iOS/OS開發中比較基礎的一個概念，在蘋果開發中用在事件處理，延遲加載，屏幕刷新等功能的處理，其實拋開語言，RunLoop是一個的架構模式，也就是RunLoop不僅僅局限於iOS開發。

  • 網上有很多關於RunLoop的干貨，但大多不怎么全，這位哥們的寫的挺好的，挺詳細的，基本上把要說的都說了，底層也研究的很細，本文基本上是轉載他的，只是在它的基礎上，基於我的知識水平補充了一些，原文：http://www.cocoachina.com/ios/20150601/11970.html

  • 官方有已經有關於RunLoop的官方文檔，英語的，不過網上已經有人把它翻譯為中文了，大家可以去看看.

概念

  • 簡單來說RunLoop是線程的基本架構模式，架構模式，架構模式-重要的事情說三遍，然並卵，具體怎么做呢，就是有事做事，沒事睡覺，有事叫我，就這樣，想看詳細的自己看中文文檔去，畢竟文檔哪里已經寫的好詳細了，再板書就沒意義了。

  • 分類(獲取)：蘋果提供了兩個途徑來獲取分別是Cocoe里面定義的NSRunLoop以及CoreFoundation里面定義的CFRunLoopRef。

    • CFRunLoopRef提供了純C函數的API，所有這些API都是線程安全的。
    • NSRunLoop提供了面向對象的API，但這些API不是線程安全的。
  • 創建，蘋果官方對CFRunLoopRef進行了開源，在這里官方源碼下載就好，蘋果官方不提供向我們平時那樣子的新建對象的方法來獲取NSRunLoop實例，但是可以通過[NSRunLoop getCurrentLoop]來創建，接下來看看具體是怎么創建的把,Show code！
// 全局字典，用來存放線程對應的RunLoop // key是線程，value是RunLoop實例，換言之線程與RunLoopRunLoop一一對應
    static CFMutableDictionaryRef __CFRunLoops = NULL; static CFSpinLock_t loopsLock = CFSpinLockInit; // 當t == 0 的時候，代表主線程
 CF_EXPORT CFRunLoopRef _CFRunLoopGet0(pthread_t t) { // 如果存進來的線程等於 0
        if (pthread_equal(t, kNilPthreadT)) { // 那么當前線程等於主線程
            t = pthread_main_thread_np(); } // 給操作加鎖
        __CFSpinLock(&loopsLock); // 如果當前RunLoop沒有為空，創建。
        if (!__CFRunLoops) { __CFSpinUnlock(&loopsLock); CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks); CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np()); // 把線程與RunLoop一一對應的存進字典
 CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop); if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) { CFRelease(dict); } CFRelease(mainLoop); __CFSpinLock(&loopsLock); } // 獲取當前線程的RunLoop
        CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t)); __CFSpinUnlock(&loopsLock); // 如果不是主線程並且之前沒有創建，也即是為空
        if (!loop) { CFRunLoopRef newLoop = __CFRunLoopCreate(t); __CFSpinLock(&loopsLock); loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t)); if (!loop) { // 把當前子線程和創建的RunLoop一一對應的存進字典
 CFDictionarySetValue(__CFRunLoops, pthreadPointer(t), newLoop); loop = newLoop; } // don't release run loops inside the loopsLock, because CFRunLoopDeallocate may end up taking it
            __CFSpinUnlock(&loopsLock); CFRelease(newLoop); } if (pthread_equal(t, pthread_self())) { _CFSetTSD(__CFTSDKeyRunLoop, (void *)loop, NULL); if (0 == _CFGetTSD(__CFTSDKeyRunLoopCntr)) { _CFSetTSD(__CFTSDKeyRunLoopCntr, (void *)(PTHREAD_DESTRUCTOR_ITERATIONS-1), (void (*)(void *))__CFFinalizeRunLoop); } } return loop; }

 

  • 上面是蘋果開源的CFRunLoop中獲取RunLoop的代碼，簡而言之就是，在調用這個方法要存進一個PThread(PThread提供了跨平台的管理多線程的API)，利用這個PThread作為全局字典中的key，並創建與之對應的RunLoop作為Value.RunLoop在我們獲取的時候創建，不獲取不創建，主線程的RunLoop在一開始就自動創建。簡而言之，線程與RunLoop一一對應

對外接口

  • 在CoreFoundation里面關於RunLoop有5個類
    • CFRunLoopTimerRef
    • CFRunLoopObserverRef
    • CFRunLoopSourceRef
    • CFRunLoopRef
    • CFRunLoopModeRef

其中CFRunLoopModeRef類沒有對外暴露，只是通過CFRunLoopRef接口進行了封裝

  • 一個RunLoop包含若干個Mode,每個Mode又包含若干個source/Timer/Observer,如圖。

 

  • 每次調用RunLoop的主函數時，只能指定其中一個Mode作為CurrentMode(可以通過這個屬性獲取當前的Mode),只能退出Loop,在重新指定一個Mode進入。在這里需要清楚的是，系統默認注冊了5個Mode

    • NSDefaultRunLoopMode:App默認Mode,當沒有接收到ScrollView滾動是，主線程通常使用這個Mode

    • NSTrackingRunLoopMode:到接收到ScroolView或其子類的時候，主線程就會切換到這個模式下運行。

    • UIInitializationRunLoopMode：當App啟動時使用的第一個Mode,當啟動完成后不再使用。

    • NSRunLoopCommonModes，是一個tag,本質上不是一個Mode,默認NSDefaultRunLoopMode和NSTrackingRunLoopMode都綁定這個tag。(應用場景：有時候我們需要添加一個NSTimer在RunLoop,在這時需要制定一個Modes，現在的需求是:我們既要在默認模式下要監聽，在滾動模式下也要監聽，但只能制定一個模式，這是可以制定這個CommonMode)
    • GSEventReceiveRunLoopMode：接受系統內部的Mode,通常做不到。
    • 處理不同事件使用不同的Mode，可以最大限度的把性能的最大化處理不同分類的事件，提高性能。

  • CFRunLoopSourceRef：事件產生的地方，按照函數調用棧來分，Source的分類可以分為

    • Source0：非基於Port的，只包含一個回調(函數指針)，他並不能主動觸發事件。使用時，你需要先把這個Source標記為待處理，然后手動調用CFRunLoopWakeUp(RunLoop)，然后再讓它執行。
    • Source1：基於Port的，通過內核和其他線程通信分發的、系統事件。
    • 這里的Port是線程間通信的一種方式，簡而言之，如果兩個線程之間想通信，可以對方的Port來通信。
  • CFRunLoopTimerRef
    • 基於時間觸發器，當其加入RunLoop時，RunLoop會注冊對應的時間點，當時間點到，RunLoop會被喚醒執行里面的回調。

  • CFRunLoopObserverRef

    • 這是觀察者，能夠監聽RunLoop的狀態改變。

    • 可以監聽的時間點有以下幾個。

      /* Run Loop Observer Activities */ 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
kCFRunLoopAllActivities = 0x0FFFFFFFU };

       

    • 上面的Source/Timer/Observer被統稱為mode item,一個item可以被同時加入多個mode。但一個item被重復加入同一個mode時不會有效果，如果一個item里面一個mode也沒有，則RunLoop剛創建就被退出，不進入循環，這里在線程常駐的時候會講到。

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

    CF_EXPORT SInt32 CFRunLoopRunInMode(CFStringRef mode, CFTimeInterval seconds, Boolean returnAfterSourceHandled); CF_EXPORT void CFRunLoopAddCommonMode(CFRunLoopRef rl, CFStringRef mode);

     

  • 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沒有對應的mode.RunLoop會自動幫你創建對應的CFRunLoopModeRef。對於一個RunLoop來說，其內部的mode只能增加不能刪除。

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 的核心是基於 mach port 的，其進入休眠時調用的函數是mach_msg()。為了解釋這個邏輯，下面稍微介紹一下 OSX/iOS 的系統架構

 
  • 蘋果官方將整個系統大致划分為上述4個層次：
    • 應用層包括用戶能接觸到的圖形應用，例如 Spotlight、Aqua、SpringBoard 等。
    • 應用框架層即開發人員接觸到的 Cocoa 等框架。
    • 核心框架層包括各種核心框架、OpenGL 等內容。
    • 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)，其頭部定義了當前端口 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)，即函數ach_msg_trap()，陷阱這個概念在Mach中等同於系統調用。當你在用戶態調用mach_msg_trap()時會觸發陷阱機制，切換到內核態；內核態中內核實現的 mach_msg() 函數會完成實際的工作，如下圖：

 
  • RunLoop 的核心就是一個mach_msg()(見上面代碼的第7步)，RunLoop 調用這個函數去接收消息，如果沒有別人發送 port 消息過來，內核會將線程置於等待狀態。例如你在模擬器里跑起一個 iOS 的 App，然后在App靜止時點擊暫停，你會看到主線程調用棧是停留在 mach_msg_trap() 這個地
  • 當 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); }

 

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 了。

事件響應

  • 蘋果注冊了一個Source1(基於machport的)用來接收系統事件，其回調函數為 __IOHIDEventSystemClientQueueCallback()。

  • 當一個硬件事件(觸摸/鎖屏/搖晃等)發生后，首先由IOKit.framework 生成一個 IOHIDEvent事件並由SpringBoard接收。這個過程的詳細情況可以參考這里。SpringBoard只接收按鍵(鎖屏/靜音等)，觸摸，加速，接近傳感器等幾種 Event，隨后用macport轉發給需要的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。

  • 解決方案:如果有某些需求或者有強迫症的同學一定要做到時刻准確，那么可以用GCD的定時器來實現(下面應用場景會有講到)。

PerformSelecter(利用RunLoop常駐線程)

  • 當調用 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 處理的。

關於網絡請求
  • iOS 中，關於網絡請求的接口自下至上有如下幾層:
CFSocket CFNetwork ->ASIHttpRequest NSURLConnection ->AFNetworking NSURLSession ->AFNetworking2, Alamofire

 

    • CFSocket 是最底層的接口，只負責 socket 通信。

    • CFNetwork 是基於 CFSocket 等接口的上層封裝，ASIHttpRequest 工作於這一層。

    • NSURLConnection是基於CFNetwork的更高層的封裝，提供面向對象的接口，AFNetworking 工作於這一層

    • NSURLSession 是iOS7中新增的接口，表面上是和NSURLConnection 並列的，但底層仍然用到了

  • 下面主要介紹下 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執行實際的回調。
AFNetworking
  • 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 啟動前內部必須要有至少一個item(Obsever除外)，所以 AFNetworking在[runLooprun]之前先創建了一個新的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]; }

 

  • 注意RunLoop 啟動前內部必須要有至少一個item，雖然Obsever也是item的一種，但是只會等待Timer和Source ，Timer是因為有回調，Source是會接收事件，所以當RunLoop里面有Timer或者Source的時候，RunLoop會等待里面的item(除Obsever以外)主動給他發消息，然后Oberver被動的接收RunLoop發送過來的消息，亦即是說，能主動給RunLoop發消息的item會讓RunLoop跑起來並且不退出。
    CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) { }); CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode); [[NSRunLoop currentRunLoop] run];

 

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

  • AsyncDisplayKit是Facebook推出的用於保持界面流暢性的框架，其原理大致如下：

    • UI 線程中一旦出現繁重的任務就會導致界面卡頓，這類任務通常分為3類：排版，繪制，UI對象操作。

    • 排版通常包括計算視圖大小、計算文本高度、重新計算子式圖的排版等操作

    • 繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預先解壓)、元素繪制 (Quartz)等操作。

    • UI對象操作通常包括 UIView/CALayer 等 UI 對象的創建、設置屬性和銷毀。

  • 其中前兩類操作可以通過各種方法扔到后台線程執行，而最后一類操作只能在主線程完成，並且有時后面的操作需要依賴前面操作的結果 （例如TextView創建時可能需要提前計算出文本的大小）。ASDK 所做的，就是盡量將能放入后台的任務放入后台，不能的則盡量推遲 (例如視圖的創建、屬性的調整)。

  • 為此，ASDK 創建了一個名為 ASDisplayNode 的對象，並在內部封裝了 UIView/CALayer，它具有和 UIView/CALayer 相似的屬性，例如 frame、backgroundColor等。所有這些屬性都可以在后台線程更改，開發者可以只通過 Node 來操作其內部的 UIView/CALayer，這樣就可以將排版和繪制放入了后台線程。但是無論怎么操作，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去。

  • ASDK 仿照 QuartzCore/UIKit 框架的模式，實現了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer，監聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回調時，遍歷所有之前放入隊列的待處理的任務，然后一一執行。

常駐線程
  • 有這么一個需求，我們要在子線程中沒接收一個事件就調用一次方法。但是子線程在完成任務后就銷毀，全局變量強引用？試試
- (void)viewDidLoad { [super viewDidLoad]; NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(run:) object:@"etund"]; self.thread = thread; NSLog(@"-----%p",[NSRunLoop currentRunLoop]); [self.thread start]; } - (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ [self performSelector:@selector(test) onThread:self.thread withObject:nil waitUntilDone:NO]; } - (void)run:(NSString *)name{ NSLog(@"=========="); } - (void)test{ NSLog(@"------------------"); }

 

結果不能執行，這里要清楚線程的5個狀態，新建，就緒，運行，阻塞，死亡。意思就是就算你是強引用一個子線程，但是他執行完任務就已經處於死亡狀態了，只是他還存儲在內存，那么現在分析一下。

- 想在子線程中不斷執行任務，必須保證子線不處於死亡狀態
- 但是子線程執行完一次任務就進入死亡狀態
- 那我們可以把線程停留在進入死亡狀態之前，這里可以用RunLoop
  • 我們可以在線程初始化的時候執行的方法中給他創建一個運行時RunLoop,這是他就可以不斷接收source，也就是這樣
- (void)run:(NSString *)name{ [[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode]; // 1
 [[NSRunLoop currentRunLoop] run]; }

 

注意：上面第一行代碼必須加上，因為一個RunLoop里面必須有至少一個item(Obsever除外)

GCD定時器
  • 有這么一個需求，需要這么一個定時器，誤差幾乎為0的定時器，但是無論是NSTimer還是CGDisplayLink都會有誤差，而且誤差都比較大，這是我們可以用GCD來實現定時器，實際上，上面已經說了，RunLoop底層也是調用GCD的source來實現NSTimer的，只是NSTimer還受mode的影響，下面來看看怎么用GCD實現
// 獲取隊列
    dispatch_queue_t queue = dispatch_get_main_queue(); // 創建定時器
    self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue); // 設置定時器屬性(什么時候開始，間隔多大) // 定義開始時間
    dispatch_time_t start = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * NSEC_PER_SEC)); // 定義時間間隔
    uint64_t interver = (uint64_t)(1.0 * NSEC_PER_SEC); // 設置開始時間和時間間隔
    dispatch_source_set_timer(self.timer, start,interver, 0); // 設置回調
    dispatch_source_set_event_handler(self.timer, ^{ NSLog(@"==================") ; }); // dispatch_cancel(self.timer); // self.timer = nil; // 取消定時器 // 啟動定時器
    dispatch_resume(self.timer);

 


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 ios之runloop筆記 iOS關於RunLoop和Timer iOS開發RunLoop學習：一：RunLoop簡單介紹 iOS開發RunLoop學習:四：RunLoop的應用和RunLoop的面試題 iOS RunLoop 初識 iOS開發線程和RunLoop iOS學習——RUNLOOP、NSTimer IOS RunLoop 常駐線程的實現 iOS面試題之runloop iOS開發 - 啰嗦講解 Runloop
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM