运行循环 - RunLoop
1.RunLoop简介
1.1 什么是RunLoop
简单来说就是：运行循环，可以理解成一个死循环，一直在运行。
RunLoop实际上就是一个对象，这个对象用来处理程序运行过程中出现的各种事件(触摸、Timer、网络)，从而保持线程的持续运行，而且在没有事件处理的时候，会进入休眠，从而节省CPU资源，提高程序性能。
OSX/iOS系统中，提供了两个这样的对象：NSRunLoop 和 CFRunLoopRef。CFRunLoopRef 是在CoreFoundation 框架内的，它提供了纯 C 函数的 API，所以这些API都是现成安全的；NSRunLoop是基于 CFRunLoopRef 的封装，提供了面向对象的API，但是这些API不是现成安全的。
1.2 RunLoop和线程
RunLoop 和线程有很密切的关系，我们知道线程的任务是用来执行一个或多个特定的任务，但是在默认情况下，线程执行完之后就会退出。这时候，如果我们想让这个线程一直去处理任务，并不退出，所以就有了RunLoop。
- 一条线程对应一个RunLoop对象，但是子线程中的RunLoop默认是不运行的，需要调用RunLoop的run方法，这个方法就是一个死循环
- 我们只能在当前线程中操作当前线程的RunLoop对象；
- RunLoop对象是在第一次获取RunLoop对象时创建，在线程结束的时候销毁；
- 主线程RunLoop对象，系统帮我们创建好了，子线程的RunLoop对象，需要我们自己去创建。
1.3 默认情况下的主线程的RunLoop原理
我们在启动一个程序的时候，系统会调用创建项目时自动生成的 main.m 文件：
int main(int argc, char * argv[]) {
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
其中 UIApplicationMain 函数内部帮我们开启了主线程的 RunLoop，UIApplicationMain 函数内部有一个无线循环的代码，上面开启 RunLoop 的代码可以简单的理解为以下代码：
int main(int argc, char * argv[]) {
BOOL running = YES;
do {
// 执行各种任务，处理各种事件
// ......
} while (running);
return 0;
}
从上面可以看出，程序一直在 do-while 循环中执行，所以 UIApplicationMain 函数一直没有返回，我们在运行程序之后，不会马上退出，会保持持续运行状态。
来看一张官方的 RunLoop 模型图：
从上图中可以看出，RunLoop 就是线程中的的一个循环，RunLoop 在循环中会不断检测，通过 Input Source (输入源) 和 Timer Source(定时源) 两种事件源来等待接收事件，然后对接收到的事件通知线程处理，并在没有事件的时候休息。
2.RunLoop相关类
下面我们来了解一下 Core Fundation 框架下，关于RunLoop 的5个类：
- CFRunLoopRef：代表RunLoop对象
- CFRunLoopModeRef：代表RunLoop的运行模式
- CFRunLoopSourceRef：就是RunLoop模型中提到的输入源/事件源
- CFRunLoopTimerRef：就是RunLoop模型中的定时源
- CFRunLoopObserverRef：观察者，能够监听RunLoop的状态改变
下面是这5个类的关系图：
通过上图，我们可以看出，一个RunLoop对象(CFRunLoopRef)包含若干个运行模式(CFRunLoopModeRef)，每一个运行模式下又包含着若干个输入源(CFRunLoopSourceRef)，定时源(CFRunLoopTimerRef)，观察者(CFRunLoopObserverRef)
- 每次RunLoop启动的时候，只能指定其中的一种运行模式(CFRunLoopModeRef)，这个运行模式被称为 currentMode
- 如果需要切换运行模式(CFRunLoopModeRef)，只能退出 RunLoop，在重新指定一个运行模式(CFRunLoopModeRef)进入
- 这样做主要是为了分割开输入源(CFRunLoopSourceRef)，定时源(CFRunLoopTimerRef)，观察者(CFRunLoopObserverRef)，使其不受影响
2.1 CFRunLoopRef
CFRunLoopRef 就是 Core Foundation 框架下的 RunLoop 类，我们可以通过以下方式来获取 RunLoop 对象：
- Core Foundation
CFRunLoopGetCurrent(); // 获得当前线程的RunLoop对象 CFRunLoopGetMain(); // 获得主线程的RunLoop对象
- Foundation
[NSRunLoop currentRunLoop]; // 获得当前线程的RunLoop对象 [NSRunLoop mainRunLoop]; // 获得主线程的RunLoop对象
2.2 CFRunLoopModeRef
系统默认定义了多种运行模式：
- kCFRunLoopDefaultMode : App的默认运行模式，通常主线程是在这个运行模式下运行
- UITrackingRunLoopMode ：跟踪用户的交互事件 (用于scrollView追踪触摸滑动，保证界面滑动时不受其他mode影响)，只能是触摸事件唤醒，级别最大
- UIInitializationRunLoopMode：在刚启动App的时候进入的第一个mode，启动完成后就不在使用
- GSEventReceiveRunLoopMode：接受系统内部事件，通常用不到
- kCFRunLoopCommonMode：占位模式，不是一种真正的运行模式，
2.3 CFRunLoopTimerRef
CFRunLoopTimerRef 定时源，理解为基于时间的触发器，基本上就是NSTimer。
下面我们来演示下 CFRunLoopModeRef 和 CFRunLoopTimerRef 结合的使用用法，从而加深理解：
– 我们先新建一个iOS项目，在Main.storyboard中拖入一个Text View。
– 在ViewController.m 文件中加入以下代码
- (void)viewDidLoad {
[super viewDidLoad];
// 定义一个定时器，约定两秒之后调用self的run方法
NSTimer *timer = [NSTimer timerWithTimeInterval:2.0 target:self selector:@selector(run) userInfo:nil repeats:YES];
// 将定时器添加到当前RunLoop的NSDefaultRunLoopMode下
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
}
- (void)run
{
NSLog(@"---run");
}
– 然后运行，这时候我们会发现如果我们不对模拟器进行任何操作的话，定时器会稳定的每隔2秒调用run 方法打印
– 但是当我们拖动Text View 滚动时，我们发现 :run 方法不打印了，也就是说 NSTimer 不工作了。而当我们松开鼠标的时候， NSTimer就又开始正常工作了。
这是因为：
- 当我们不做任何操作的时候，RunLoop 处于 NSDefaultRunLoopMode 下
- 而当我们拖动 Text View 的时候，RunLoop 就结束 NSDefaultRunLoopMode，切换到了 UITrackingRunLoopMode 模式下，这个模式下没有添加 NSTimer，所以我们的 NSTimer 就不工作了
- 但当我们松开鼠标的时候，RunLoop就结束 UITrackingRunLoopMode 模式，又切换回 NSDefaultRunLoopMode 模式，所以 NSTimer 就又开始正常工作了。
可以试着将上面代码中的：
// 将定时器添加到当前RunLoop的NSDefaultRunLoopMode下
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
换成
// 将定时器添加到当前RunLoop的NSDefaultRunLoopMode下
[[NSRunLoop currentRunLoop] addTimer:timer forMode:UITrackingRunLoopMode];
也就是将定时器添加到当前 RunLoop 的UITrackingRunLoopMode 下，你就会发现定时器只会在拖动 Text View 的模式下工作，而不做操作的时候，定时器就不工作。
那难道我们就不能再这两种模式下让NSTimer都能正常工作吗？
当然可以啊，这就用到了之前说的 伪模式(kCFRunLoopCommonModes) ,也可以理解为占位模式，这其实不是一种真实的模式，而是一种标记模式，意思就是可以在打上Common Modes标记的模式下运行。
那么此时，我们需要将 NSDefaultRunLoopMode 和 UITrackingRunLoopMode 打上标记，所以我们只要将NSTimer 添加到当前 RunLoop 的占位模式下就可以让 NSTimer 在不做操作和拖动 Text View 两种情况下愉快的工作了。
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
顺便讲一下 NSTimer 中的 scheduledTimerWithTimeInterval 方法和 RunLoop 的关系：
[NSTimer scheduledTimerWithTimeInterval:2.0 target:self selector:@selector(run) userInfo:nil repeats:YES];
这句代码调用了 scheduledTimer 返回的定时器，NSTimer 会自动被加入到了 RunLoop 的 NSDefaultRunLoopMode 模式下，这句代码相当于下面两句代码：
NSTimer *timer = [NSTimer timerWithTimeInterval:2.0 target:self selector:@selector(run) userInfo:nil repeats:YES]; [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
2.4 CFRunLoopSourceRef
CFRunLoopSourceRef 是事件源，它有两种分类方法：
第一种：按照官方文档来分类（就像RunLoop模型图中那样）：
- Port-Based Sources (基于端口)
- Custom Input Sources （自定义）
- Cocoa Perform Selector Sources
第二种：按照函数调用栈来分类：
- Source0：非基于Port(这是个啥？进行间通信的轻量级的方式？)，处理App内部事件、App负责管理，如UIEvent、CFS ocket.
- Source1：基于Port，通过内核和其他线程通信，接收、分发系统事件
这两种分类方式其实没有区别，只不过第一种是通过官方理论来分类，第二种是在实际应用中通过调用函数来分类、。
下面我们举个例子大致来了解一下函数调用栈和Source：
当我们点击红色区域的时候，会弹出下面的窗口，这就是点击事件产生的函数调用栈：
所以点击事件是这样来的：
- 首先程序启动，调用 16 行的main函数，main函数调用15行的UIApplicationMain函数，然后一直往上调用函数，最终调用到 0 行的BtnClick 函数，即点击函数。
- 同时我们可以看到11 行中有Sources0，也就是说我们点击事件是属于 Sources0 函数的，点击事件就是在 Sources0 中处理的。
- 而至于 Sources1，则是用来接收、分发系统事件，然后再分发到Sources0中处理的。
2.5 CFRunLoopObserverRef
CFRunLoopObserverRef 是观察者，用来监听RunLoop的状态改变：
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 即将进入Loop：1
kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理Timer：2
kCFRunLoopBeforeSources = (1UL << 2), // 即将处理Source：4
kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠：32
kCFRunLoopAfterWaiting = (1UL << 6), // 即将从休眠中唤醒：64
kCFRunLoopExit = (1UL << 7), // 即将从Loop中退出：128
kCFRunLoopAllActivities = 0x0FFFFFFFU // 监听全部状态改变
};
下面我们通过代码来监听RunLoop中的状态改变：
1. 添加以下代码:
- (void)viewDidLoad {
[super viewDidLoad];
// 创建观察者
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
NSLog(@"监听到RunLoop发生改变---%zd",activity);
});
// 添加观察者到当前RunLoop中
CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);
// 释放observer，最后添加完需要释放掉
CFRelease(observer);
}
2.然后运行，看下打印结果：
2017-12-18 23:05:06.992894+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:06.993346+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:06.993608+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:06.993798+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:06.993986+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:06.994204+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:06.997608+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:06.997771+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:06.997951+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:06.998064+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:06.998226+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:06.998342+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:06.999366+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:06.999518+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:06.999653+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:06.999757+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:07.002657+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:07.003307+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:07.067024+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---2 2017-12-18 23:05:07.067467+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---4 2017-12-18 23:05:07.068242+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---32 2017-12-18 23:05:07.248755+0800 RunLoop[10436:1007150] 监听到RunLoop发生改变---64
可以看到RunLoop的状态在不断的改变，最终变成了状态 32，也就是即将进入睡眠状态，说明RunLoop之后就会进入睡眠状态。
3. RunLoop 原理
下面，我们来理解下RunLoop的运行逻辑了：
这张图对于我们理解RunLoop很有帮助，下面我们说下官方文档给我们的RunLoop逻辑：
在每次运行开启RunLoop的时候，所在线程的RunLoop会自动处理之前未处理的事件，并且通知相关的观察者：
- 通知观察者RunLoop已经启动
- 通知观察者即将要开始的定时器
- 通知观察者任何即将启动的非基于端口的源
- 启动任何准备好的非基于端口的源
- 如果基于端口的源准备好并处于等待状态，立即启动，并进入步骤9
- 通知观察者线程进入休眠状态
- 将线程置于休眠直到任一下面的事件发生：某一事件到达基于端口的源 – 定时器启动 – RunLoop设置的时间已经超时 – RunLoop被显示唤醒
- 通知观察者线程将被唤醒
- 处理未处理的事件 – 如果用户定义的定时器启动，处理定时器事件并重启RunLoop，进入步骤2 – 如果输入源启动，传递相应的消息 – 如果RunLoop被显示唤醒而且时间还没超时，重启RunLoop，进入步骤2
- 通知观察者RunLoop结束。
4 使用场景
4.1 后台常驻线程(很常用)
我们在开发程序的过程中，如果后台操作特别频繁，经常会在子线程做一些耗时操作(下载文件、后台播放音乐等)，我们最好能让这条线程永远常驻内存。
那么怎么做呢？
添加一条用于常驻内存的强引用的子线程，在该线程的RunLoop下添加一个 Sources，开启 RunLoop。
- (void)viewDidLoad {
[super viewDidLoad];
// 创建线程，并调用run1方法执行任务
self.thread = [[NSThread alloc] initWithTarget:self selector:@selector(run1) object:nil];
// 开启线程
[self.thread start];
}
- (void) run1
{
// 这里写任务
NSLog(@"----run1-----");
// 添加下边两句代码，就可以开启RunLoop，之后self.thread就变成了常驻线程，可随时添加任务，并交于RunLoop处理
[[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode];
[[NSRunLoop currentRunLoop] run];
// 测试是否开启了RunLoop，如果开启RunLoop，则来不了这里，因为RunLoop开启了循环。
NSLog(@"未开启RunLoop");
}
运行之后发现打印了 —run1— ，而未开启RunLoop则未打印。
这样我们就开启了一条常驻线程，如果我们再去添加其他任务的时候，—run1—还会继续打印，这就实现了常驻线程的需求。