Runloop的內部結構與運行原理

時間  2021-08-13
標籤 面試 api 數組 markdown app 框架 異步 async 函數 oop 欄目 快樂工作 简体版
原文   原文鏈接

什麼是Runloop

Runloop顧名思義，就是運行循環。首先它根程序運行過程有關係，其次它是一種轉圈圈的效果。但若是這麼解釋，恐怕誰都聽不懂。面試

想要弄明白Runloop，就要搞清楚跟它有關聯的一些概念，以及它自身的運做原理。api

沒有Runloop的程序

咱們經過Xcode新建一個命令行項目，main.m文件裏的代碼以下數組

#import <Foundation/Foundation.h>

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        NSLog(@"Hello, World!");
    }
    return 0;
}
複製代碼

運行程序，程序在執行完代碼 NSLog(@"Hello, World!");以後，就會經過 return 0;推出程序，這是一種線性的執行流程，從上到下，很容易理解。markdown

當咱們碰見Runloop

咱們再新建一個iOS項目，你看到的main.m文件是這個樣子的app

#import <UIKit/UIKit.h>
#import "AppDelegate.h"

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}
複製代碼

咱們很清楚，運行程序以後，咱們會進入app的界面，而後app就不會退出了，會一直運行着。你有沒有好奇過，一樣都是main函數，爲啥下面的這個可以不退出呢？對，這就是Runloop的功勞。框架

在命令行工程裏面的main.m裏面，是沒有加Runloop的，而iOS工程的main.m裏面，其實在UIApplicationMain()這個方法中，系統加上了Runloop，讓程序能夠一直循環運行下去不退出。異步

這麼解釋感受仍是有點僵硬，下面用僞代碼的形式來描述一下UIApplicationMain()內部狀況 說白了， Runloop其實就是一個do-while循環，每次循環一圈，都會判斷一次retVal，決定是否結束循環，繼續執行循環外的代碼。async

Runloop的做用簡述

  • Runloop的do-while本質說明它就是爲了保持程序的持續運行，不退出（試想一下手機上的app若是一打開就直接退出完事了，這個世界可能就沒有手機什麼事了）
  • 保持程序持續運行的根本目的，就是爲了處理app的各類事件（觸摸事件，定時器事件），由於這些事件並非編寫程序的時候就定好的，天知道用戶何時會點擊某個按鈕，對吧。所以想咱們一開始說的那種線性的程序運行方式，就沒法處理這樣的場景。當加上Runloop以後，在它的一次循環中，就能夠去處理程序已經接收到的各類事件，在處理這些事件的過程當中，程序還會不斷的接受新來的事件，這樣，下次循環就能夠繼續處理新來的事件。
  • 若是Runloop在某次循環以後，發現程序忽然沒有收集到更多事件供它去處理，它就會休眠，實際上就是系統讓程序停在了Runloop的do-while循環裏面的某一段代碼上（注意程序此時是停住，而不是退出哦），若是過了一會程序爲Runloop接受到了新來的事件，它的do-while循環就會被系統從新激活以繼續運行。這種機制的好處是，當Runloop休眠的時候，CPU能夠不用在它跟前侯着，轉而把時間精力分配給別的事務，提升了CPU的使用效率。

你可把CPU想象成一個媽媽，Runloop就是剛出生的寶寶，寶寶醒的時候，媽媽就必須一直看着他，沒功夫去幹別的事情，寶寶睡眠的時候，媽媽就能夠抓緊時間去作一些別的事情了。若是沒有Runloop休眠機制，至關於這個寶寶永遠不會睡覺，那這個媽媽不久涼涼了嘛～～函數

深刻理解Runloop對象

iOS中Runloop的API

  • Foundation: NSRunLoop
  • Core Foundation: CFRunLoopRef

NSRunLoop 和 CFRunLoopRef都表明Runloop對象，NSRunLoop是基於CFRunLoopRef的一層OC包裝，CFRunLoopRef是開源的oop

Runloop對象的獲取

  • Foundation

[NSRunloop currentRunLoop];得到當前線程的RunLoop對象 [NSRunLoop mainRunLoop];得到主線程的Runloop對象

  • Core Foundation

CFRunLoopGetCurrent();得到當前線程的RunLoop對象 CFRunLoopGetMain();得到主線程的Runloop對象

Runloop與線程

爲何聊Runloop必定要搭上線程？咱們知道，程序裏的每一句代碼，都會在線程（主線程/子線程）裏面被執行，上面四種得到Runloop對象的代碼也不例外，必定是跑在線程裏面的。以前咱們說到，Runloop是爲了讓程序不退出，其實更準確地說，是爲了保持某個線程不結束，只要還有未結束的線程，那麼整個程序就不會退出，由於線程是程序的運行的調度的基本單元。

線程與Runloop的關係是一對一的，一個新建立的線程，是沒有Runloop對象的，當咱們在該線程裏第一次經過上面的API得到Runloop時，Runloop對象纔會被建立，而且經過一個全局字典將Runloop對象和該線程存儲綁定在一塊兒，造成一對一關係。

Runloop會在線程結束時銷燬，主線程的Runloop已經自動獲取過（建立），子線程默認沒有開啓RunLoop（直到你在該線程獲取它）。RunLoop對象建立後，會被保存在一個全局的Dictionary裏，線程做爲key，Runloop對象做爲value。

關於Runloop的建立和保存，咱們還能夠在CF源碼裏面詳細看看，Runloop的信息是寫在CF源碼文件夾的CFRunLoop.c文件裏面，咱們能夠在裏面搜索到CFRunLoopGetCurrent()函數的實現

CFRunLoopRef CFRunLoopGetCurrent(void) {
    CHECK_FOR_FORK();
    CFRunLoopRef rl = (CFRunLoopRef)_CFGetTSD(__CFTSDKeyRunLoop);
    if (rl) return rl;
    return _CFRunLoopGet0(pthread_self());
}
複製代碼

CFRunLoopGetCurrent()中又是經過_CFRunLoopGet0來得到Runloop對象的

Runloop的獲取建立流程

Runloop對象底層結構

咱們能夠在源碼CFRunloop.c中找到Runloop的定義

**************🥝🥝🥝🥝__CFRunLoop🥝🥝🥝🥝***********
typedef struct CF_BRIDGED_MUTABLE_TYPE(id) __CFRunLoop * CFRunLoopRef;
struct __CFRunLoop {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;          /* locked for accessing mode list */
    __CFPort _wakeUpPort;// used for CFRunLoopWakeUp 
    Boolean _unused;
    volatile _per_run_data *_perRunData;  // reset for runs of the run loop
    uint32_t _winthread;

 //♥️♥️♥️♥️♥️♥️♥️核心組成♥️♥️♥️♥️♥️♥️
    pthread_t _pthread;
    CFMutableSetRef _commonModes;
    CFMutableSetRef _commonModeItems;
    CFRunLoopModeRef _currentMode;
    CFMutableSetRef _modes;
 //♥️♥️♥️♥️♥️♥️♥️核心組成♥️♥️♥️♥️♥️♥️

    struct _block_item *_blocks_head;
    struct _block_item *_blocks_tail;
    CFAbsoluteTime _runTime;
    CFAbsoluteTime _sleepTime;
    CFTypeRef _counterpart;
};


**************🥝🥝🥝🥝__CFRunLoopMode🥝🥝🥝🥝***********
typedef struct __CFRunLoopMode *CFRunLoopModeRef;
struct __CFRunLoopMode {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;  /* must have the run loop locked before locking this */
    Boolean _stopped;
    char _padding[3];

    //♥️♥️♥️♥️♥️♥️♥️核心組成♥️♥️♥️♥️♥️♥️
    CFStringRef _name;
    CFMutableSetRef _sources0;
    CFMutableSetRef _sources1;
    CFMutableArrayRef _observers;
    CFMutableArrayRef _timers;
    //♥️♥️♥️♥️♥️♥️♥️核心組成♥️♥️♥️♥️♥️♥️


    CFMutableDictionaryRef _portToV1SourceMap;
    __CFPortSet _portSet;
    CFIndex _observerMask;
#if USE_DISPATCH_SOURCE_FOR_TIMERS
    dispatch_source_t _timerSource;
    dispatch_queue_t _queue;
    Boolean _timerFired; // set to true by the source when a timer has fired
    Boolean _dispatchTimerArmed;
#endif
#if USE_MK_TIMER_TOO
    mach_port_t _timerPort;
    Boolean _mkTimerArmed;
#endif
#if DEPLOYMENT_TARGET_WINDOWS
    DWORD _msgQMask;
    void (*_msgPump)(void);
#endif
    uint64_t _timerSoftDeadline; /* TSR */
    uint64_t _timerHardDeadline; /* TSR */
};
複製代碼

咱們須要掌握與Runloop相關的5個相關的類

  • CFRunLoopRef——這個就是Runloop對象
  • CFRunLoopModeRef——其內部主要包括四個容器，分別用來存放source0、source1、observer以及timer
  • CFRunLoopSourceRef——分爲source0和source1

source0：包括 觸摸事件處理、[performSelector: onThread: ] source1：包括 基於Port的線程間通訊、系統事件捕捉

  • CFRunLoopTimerRef——timer事件，包括咱們設置的定時器事件、[performSelector: withObject: afterDelay:]
  • CFRunLoopObserverRef——監聽者，Runloop狀態變動的時，會通知監聽者進行函數回調，UI界面的刷新就是在監聽到Runloop狀態爲BeforeWaiting時進行的。

對於以上這幾個類相互之間的關係，能夠經過以下的圖來描繪

從圖中可看出，一個RunLoop對象裏面包含了若干個RunLoopMode，RunLoop內部是經過一個集合容器_modes來裝這些RunLoopMode的。

RunLoopMode內部核心內容是4個數組容器，分別用來裝source0，source1，observer和timer，RunLoop對象內部有一個_currentMode，它指向了該RunLoop對象的其中一個RunLoopMode，它表明的含義是RunLoop當前所運行的RunLoopMode，所謂「運行」也就是說，RunLoop當前只會執行_currentMode所指向的RunLoopMode裏面所包括的事件（source0、source一、observer、timer）

另外，RunLoop對象內部還有另外兩個成員 _commonModes和_commonModeItems，這個稍後解釋。

還有就是RunLoop對象內部還包括一個線程對象_pthread，這就是跟它一一對應的那個線程對象。

source0

上面介紹了包括觸摸事件處理、[performSelector: onThread: ]，這個也能夠經過代碼來驗證一下。首先看一下觸摸事件，在ViewController裏面重寫方法

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    NSLog(@"點擊屏幕");
}
複製代碼

加上斷點，而後運行程序，點擊屏幕，此時程序會停在 有時咱們沒法在Xcode的debug navigator看到完整的函數調用棧

這時能夠經過LLDB指令bt，在控制檯打印出完整的函數調用棧信息能夠看出系統是經過一個CF的函數__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__來調用UIKit進行事件處理的，上面這個名字老長的函數，從命名就看的很清楚了，Runloop如今處理的是一個source0。 經過一樣的方法，能夠證實[performSelector: onThread: ]生成的也是一個source0。

- (void)viewDidLoad {
    [super viewDidLoad];
//建立線程
    NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(runThread) object:nil];
    //啓動線程
    [thread start];
    //向線程加入perform事件
    [self performSelector:@selector(performEvent) onThread:thread withObject:nil waitUntilDone:YES];
// 下面這個方法一樣產生source0
// [self performSelector:@selector(performEvent) onThread:thread withObject:nil waitUntilDone:YES modes:@[NSDefaultRunLoopMode]];
}


-(void)runThread {
    //確保線程常駐
    [[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
    [[NSRunLoop currentRunLoop] run];
}

- (void)performEvent {
    NSLog(@"處理Perform事件");
}
複製代碼

[performSelector: onThread: ]生成source0

source1

上面介紹了source1包括系統事件捕捉和基於port的線程間通訊。什麼是系統事件捕捉？又如何理解基於port的線程間通訊？其實，咱們手指點擊屏幕，首先產生的是一個系統事件，經過source1來接受捕捉，而後由Springboard程序包裝成source0分發給應用去處理，所以咱們在App內部接受到觸摸事件，就是source0，這一前一後的關係要理清楚。

基於port的線程間通訊經過下面的圖示大體理解便可image.png

CFRunLoopTimerRef

一樣，能夠在Xcode裏面經過LLDB的bt指令，查看NSTimer事件和[performSelector: withObject: afterDelay]事件的函數調用棧，發現它們都是經過 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__函數被吊起的。從函數名看出，它們確實是屬於timer事件（CFRunLoopTimerRef）

CFRunLoopObserverRef

咱們知道 observer 是用來監聽Runloop狀態的。還能夠處理UI界面刷新，那咱們些的那些UI界面相關的控制代碼，是怎麼被執行的呢？圖示以下 Runloop狀態總共有如下幾種

/* Run Loop Observer Activities */
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry = (1UL << 0),//進入runloop循環
    kCFRunLoopBeforeTimers = (1UL << 1),//即將處理timer事件
    kCFRunLoopBeforeSources = (1UL << 2),//即將處理source事件
    kCFRunLoopBeforeWaiting = (1UL << 5),//即將進入休眠（等待消息喚醒）
    kCFRunLoopAfterWaiting = (1UL << 6),//休眠結束（被消息喚醒）
    kCFRunLoopExit = (1UL << 7),//退出runloop循環
    kCFRunLoopAllActivities = 0x0FFFFFFFU//集合以上全部的狀態
};
複製代碼

想要在調試中看到Runloop的狀態變化，能夠經過Runloop的api添加observer，具體以下

//建立observer
    //經過block建立
    CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault, kCFRunLoopAllActivities, true, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
        //observer回調處理
        switch (activity) {
            case kCFRunLoopEntry:
                NSLog(@"kCFRunLoopEntry");
                break;
            case kCFRunLoopBeforeTimers:
                NSLog(@"kCFRunLoopBeforeTimers");
                break;
            case kCFRunLoopBeforeSources:
                NSLog(@"kCFRunLoopBeforeSources");
                break;
            case kCFRunLoopBeforeWaiting:
                NSLog(@"kCFRunLoopBeforeWaiting");
                break;
            case kCFRunLoopAfterWaiting:
                NSLog(@"kCFRunLoopAfterWaiting");
                break;
            case kCFRunLoopExit:
                NSLog(@"kCFRunLoopExit");
                break;

            default:
                break;
        }
    })

    //添加observer到runloop中
    CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
    //釋放observer
    CFRelease(observer);
複製代碼

程序運行以後，你會在控制檯看到不斷的有以下打印能夠看出，Runloop的狀態切換時，都會被observer監聽到。

_modes和_commonModes

你會好奇，RunLoop內部要這麼多RunLoopMode幹什麼，爲何不把事件都放在一個Mode裏面就好，如今用一個實際案例來解釋這個問題。

首先，咱們在一個iOS工程裏面，在界面上添加一個UITextView

而後在ViewController裏面開啓一個可循環的定時器

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(timerEvent) userInfo:nil repeats:YES];
}

- (void)timerEvent {
    NSLog(@"處理Timer事件");
}

@end
複製代碼

運行程序以後，控制檯回每隔1秒調用一次timerEvent方法執行 系統是怎麼辦到的呢，其實，[NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(timerEvent) userInfo:nil repeats:YES];內部，就是每隔一秒鐘，往當前線程（主線程）的RunLoop對象內部的其中一個Mode添加timer事件，並放在它的timer容器裏面，

而後在RunLoop的不斷循環中，被依次處理。所謂處理timer事件，就是去調用timer所綁定的OC方法，或者block。

當時滑動界面上咱們剛纔添加的那個UITextView時，你會發現控制檯裏面timerEvent的方法停住了，爲啥呢？這個問題常常在iOS面試時碰到，相信你也知道答案。剛纔咱們介紹RunLoop內部結構的時候瞭解到，其內部有若干個RunLoopMode，其中有兩個咱們須要掌握，它們名字分別是

  • kCFRunLoopDefaultMode

App的默認Mode，一般主線程時在這個Mode下運行的

  • UITrakingRunLoopMode

界面追蹤Mode，顧名思義，App有若是有Scrollview的觸摸滑動事件，會放到該Mode的事件容器裏，因此當用戶經過屏幕操做界面上的ScrollView時，App會切換到該Mode下運行，處理當前的滑動事件。

上面咱們經過經過scheduledTimerWithTimeInterval方法增長的timer事件，其實是被系統默認放到了主線程RunLoop的kCFRunLoopDefaultMode內，當咱們不滑動屏幕時，主線程跑在這個Mode下，因此能夠處理咱們添加的timer事件。

當咱們手指滑動屏幕的時候，主線程會被切換到UITrakingRunLoopMode下去運行，所以就處理不了咱們的timer事件了，由於timer事件壓根就沒有添加到前線程運行的Mode裏面。

這樣劃分開的好處就是，能夠把不一樣優先級的事件，分開放置，互不干擾。由於蘋果的最高理念是用戶體驗至上，當用戶在滑動操做界面的時候，蘋果認爲最好的體驗是儘量讓用戶感受不到卡頓，若是把耗時較大的事件和滑動事件放在同一個Mode裏面同時去處理，就有可能形成界面卡頓。擁有多個Mode，就能將事件分開處理，保證用戶體驗。UITrakingRunLoopMode這個名子也就是提醒開發人員，不要把不相關的耗時操做事件添加到這個Mode裏面，以避免影響用戶體驗。

要解決上面的案例中的問題，讓滑動界面的同時，還能夠處理timer事件，就須要利用NSTimer的另一個方法來添加計時器

- (void)viewDidLoad {
    [super viewDidLoad];
//建立一個timer
    NSTimer *timer = [NSTimer timerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
        NSLog(@"timer事件2");
    }];
//將timer添加到RunLoop的指定模式裏面
    [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
}
複製代碼

代碼中，我將建立的timer添加到了NSRunLoopCommonModes中，這個NSRunLoopCommonModes其實不是一個具體的模式，它能夠理解成一個標籤，被打上這種標籤的具體Mode會被放入到RunLoop內部的一個容器成員_commonModes 裏面，它是一個CFMutableSetRef，默認狀況下，_commonModes 內部裝着kCFRunLoopDefaultMode + UITrakingRunLoopMode 這兩個Mode，等於說這兩個Mode是具備NSRunLoopCommonModes標記的，所以都被添加進了_commonModes ，根據上面的代碼，timer將不會被添加到某個具體的Mode裏，而是會被放入RunLoop的_commonModeItems 這個容器裏。只要App運行在_commonModes 所包含的某個Mode下，就會去處理_commonModeItems 裏面的事件。固然，所運行的那個Mode本身自己所包含的事件也是會被處理的，這點不要忽略。以上，就是解決timer失效問題的方法和底層的原理。

從源碼梳理Runloop的運行流程

上面咱們討論Runloop內部的循環在運行過程當中，被分紅了若干個狀態，那麼這些狀態之間是按如何順序切換的呢，Runloop內部的執行邏輯到底如何呢，這就須要經過源碼來一窺究竟了。RunLoop的源文件CFRunLoop.c是比較複雜的，並且是純C實現的，你們看的時候不免會不太習慣，並且這裏面有不少函數，那個纔是Runloop的入口函數呢。其實咱們在上面證實 觸摸事件屬於source0的時候，就能夠從函數調用棧裏面找到答案 很明顯，在經過觸摸事件觸發的函數調用棧裏面，CF框架最初是經過CFRunLoopRunSpecific函數進入Runloop的，接下來便調用了__CFRunLoopRun，從名字就能看出這裏可定是入口了。咱們來看一下這兩個函數，因爲這兩個函數都比較複雜，爲了便於理解Runloop的執行邏輯，代碼通過精簡，保留核心步驟代碼，而且標記爲①～⑫個主要步驟，展現以下

SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) {     /* DOES CALLOUT */
    
    //📢📢📢📢***①***📢📢📢📢通知observer----------kCFRunLoopEntry
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);

    //🚗🚗🚗🚗🚗🚗🚗🚗啓動runloop
    result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);

    //📢📢📢📢***⑫***📢📢📢📢通知observer----------kCFRunLoopEntry
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
 
    return result;
}


static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode) {

    //⚠️⚠️⚠️退出do-while循環的標籤retVal
    int32_t retVal = 0;

    //♥️♥️♥️runloop的核心就是這樣一個do-while循環
    do {
        
      //📢📢📢📢***②***📢📢📢📢通知observer-----kCFRunLoopBeforeTimers
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);


      //📢📢📢📢***③***📢📢📢📢通知observer-----kCFRunLoopBeforeSources
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);


      //⚙️⚙️⚙️⚙️***④***⚙️⚙️⚙️⚙️處理Blocks
	   __CFRunLoopDoBlocks(rl, rlm);


      //⚙️⚙️⚙️⚙️***⑤***⚙️⚙️⚙️⚙️處理source0-------
        Boolean sourceHandledThisLoop = __CFRunLoopDoSources0(rl, rlm, stopAfterHandle);

        if (sourceHandledThisLoop) {
            //⚙️⚙️⚙️⚙️⚙️⚙️⚙️⚙️須要的話處理Blocks
            __CFRunLoopDoBlocks(rl, rlm);
	}


      //♦️♦️♦️♦️***⑥***♦️♦️♦️♦️判斷有沒有source1

        if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) {

            //🎯🎯🎯🎯🎯🎯🎯🎯若是有source1，跳轉到標籤handle_msg處
            goto handle_msg;
        }


      //📢📢📢📢***⑦***📢📢📢📢通知observer-----kCFRunLoopBeforeWaiting
	   __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);

      //開始休眠
	  __CFRunLoopSetSleeping(rl);

      //等待別的消息來喚醒當前線程 
      __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy);
            
      //線程喚醒
	  __CFRunLoopUnsetSleeping(rl);


     //📢📢📢📢 ⑧ 📢📢📢📢通知observer-----kCFRunLoopAfterWaiting 結束休眠
      __CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);

//🎯🎯🎯
handle_msg://⚙️⚙️⚙️⚙️***⑨***⚙️⚙️⚙️⚙️處理喚醒事件


        //🥝🥝🥝🥝🥝被timer喚醒
        if (rlm->_timerPort != MACH_PORT_NULL && livePort == rlm->_timerPort) {
        //🔧🔧🔧🔧🔧🔧🔧🔧處理timer
            __CFRunLoopDoTimers(rl, rlm, mach_absolute_time())
        }
        //🥝🥝🥝🥝🥝被GCD喚醒
        else if (livePort == dispatchPort) {
        //🔧🔧🔧🔧🔧🔧🔧🔧處理GCD
            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
            
        } 
        //🥝🥝🥝🥝🥝source1喚醒
        else {
        //🔧🔧🔧🔧🔧🔧🔧🔧處理Source1
            __CFRunLoopDoSource1(rl, rlm, rls, msg, msg->msgh_size, &reply) || sourceHandledThisLoop;
		
	    }


      //⚙️⚙️⚙️⚙️***⑩***⚙️⚙️⚙️⚙️處理Blocks
	   __CFRunLoopDoBlocks(rl, rlm);
        
      //⚙️⚙️⚙️⚙️***⑪***⚙️⚙️⚙️⚙️設置返回值retVal
	  if (sourceHandledThisLoop && stopAfterHandle) {
	      retVal = kCFRunLoopRunHandledSource;
          } else if (timeout_context->termTSR < mach_absolute_time()) {
              retVal = kCFRunLoopRunTimedOut;
	  } else if (__CFRunLoopIsStopped(rl)) {
              __CFRunLoopUnsetStopped(rl);
	      retVal = kCFRunLoopRunStopped;
	  } else if (rlm->_stopped) {
	      rlm->_stopped = false;
	      retVal = kCFRunLoopRunStopped;
	  } else if (__CFRunLoopModeIsEmpty(rl, rlm, previousMode)) {
	      retVal = kCFRunLoopRunFinished;
	  }
        
  } while (0 == retVal);
    
  return retVal;
}
複製代碼

將上面的執行流程總結圖示以下

Runloop運行流程圖

如下是RunLoop中的7個核心操做單元

  • ①__CFRunLoopDoSource1：處理source1事件，其內部調用了

__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__

  • ②__CFRunLoopDoSources0：處理source0事件，其內部調用了

__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__

  • ③__CFRunLoopDoObservers：通知觀察者，其內部調用了

__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__

  • ④__CFRunLoopDoTimers：處理定時器事件，其內部調用了

__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__

  • ⑤__CFRunLoopDoBlocks：處理blocks，其內部調用了

__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__

  • ⑥__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__：處理GCD異步主線程任務
  • ⑦__CFRunLoopServiceMachPort休眠線程，等待消息喚醒

注意點一 ——GCD與RunLoop

GCD和RunLoop是兩個獨立的機制，大部分狀況下是彼此不相關的。可是上面咱們看到RunLoop裏面有一個核心操做叫__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__，翻譯過來大概是 RunLoop正在服務（GCD的）主線程隊列，說明GCD講一些事情交給了RunLoop處理。實際上，當咱們從子線程異步調回到主線程執行任務時，GCD會將這個主線程任務丟給RunLoop，最後經過__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__函數傳送給GCD內部去處理，下面的代碼就是這種狀況

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
   NSLog(@"點擊屏幕");
   
   dispatch_async(dispatch_get_global_queue(0, 0), ^{
       NSLog(@"子線程事件");
       dispatch_async(dispatch_get_main_queue(), ^{
           NSLog(@"回到主線程");
           
       });
   });
}
複製代碼

函數調用以下RunLoop處理GCD任務

注意點二—— 線程的休眠細節

以前咱們說過RunLoop能夠幫助程序節省CPU資源，提升性能，有事情作作事，沒事情作就休眠休息，而正是__CFRunLoopServiceMachPort幫助咱們實現了這個休眠功能。這個函數的做用，就是阻塞線程，讓線程真正停下來，不在繼續往下執行，等待被喚醒。那麼這個阻塞是如何實現的呢？

爲了避免在繼續執行下面的代碼，你可能會想到用一個無限循環 while(1){;}，這樣其後面的代碼部分就都不會執行，但這並非真正的休眠，只不過程序走到while(1){;}這個死循環裏面出不來了，可是線程並無真正停下來，while(1){;}所編譯成的那幾句彙編指令正在不停的被CPU反覆的執行，因此仍然須要佔用CPU資源。

而__CFRunLoopServiceMachPort函數是一種真正意義上的休眠，它使得當前線程真正停下來，而且再也不須要佔用CPU資源去執行彙編指令了。其內部其實調用了mach_msg()函數，這是系統內核提供給咱們的一個API，它使的咱們做爲應用層面的開發人員，能夠調用內核層面的函數，線程休眠就是一種內核層面的操做。

到此RunLoop的內部結構以及運行原理就梳理完畢

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程