Runloop的内部结构与运行原理

什么是Runloop

Runloop顾名思义，就是运行循环。首先它根程序运行过程有关系，其次它是一种转圈圈的效果。但如果这么解释，恐怕谁都听不懂。

想要弄明白Runloop，就要搞清楚跟它有关联的一些概念，以及它自身的运作原理。

没有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;推出程序，这是一种线性的执行流程，从上到下，很容易理解。

当我们遇见Runloop

我们再新建一个iOS项目，你看到的main.m文件是这个样子的

#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，决定是否结束循环，继续执行循环外的代码。

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是[开源的]

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对象底层结构

我们可以在源码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、source1、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事件");
}
复制代码

source1

上面介绍了source1包括系统事件捕捉和基于port的线程间通信。什么是系统事件捕捉？又如何理解基于port的线程间通信？其实，我们手指点击屏幕，首先产生的是一个系统事件，通过source1来接受捕捉，然后由Springboard程序包装成source0分发给应用去处理，因此我们在App内部接受到触摸事件，就是source0，这一前一后的关系要理清楚。

基于port的线程间通信通过下面的图示大致理解即可

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中的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可以帮助程序节省CPU资源，提高性能，有事情做做事，没事情做就休眠休息，而正是__CFRunLoopServiceMachPort帮助我们实现了这个休眠功能。这个函数的作用，就是阻塞线程，让线程真正停下来，不在继续往下执行，等待被唤醒。那么这个阻塞是如何实现的呢？

为了不在继续执行下面的代码，你可能会想到用一个无限循环 while(1){;}，这样其后面的代码部分就都不会执行，但这并不是真正的休眠，只不过程序走到while(1){;}这个死循环里面出不来了，但是线程并没有真正停下来，while(1){;}所编译成的那几句汇编指令正在不停的被CPU反复的执行，所以仍然需要占用CPU资源。

而__CFRunLoopServiceMachPort函数是一种真正意义上的休眠，它使得当前线程真正停下来，并且不再需要占用CPU资源去执行汇编指令了。其内部其实调用了mach_msg()函数，这是系统内核提供给我们的一个API，它使的我们作为应用层面的开发人员，可以调用内核层面的函数，线程休眠就是一种内核层面的操作。

到此RunLoop的内部结构以及运行原理就梳理完毕

作者：RUNNING_NIUER