什么是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和source1source0：包括 触摸事件处理、[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，其中有两个我们需要掌握，它们名字分别是
kCFRunLoopDefaultModeApp的默认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的内部结构以及运行原理就梳理完毕
