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教程