一般来讲，一个线程一次只能执行一个任务，执行完任务后线程就会退出。如果我们需要线程随时处理任务而不退出，通常的代码逻辑是这样的：
function loop() {
initialize();
do {
var message = get_next_message();
process_message(message);
} while (message != quit);
}
这种模型通常被称为Event Loop。Event Loop在iOS里的实现就是RunLoop。实现这种模型的关键点在于：如何管理事件/消息；如何让线程在没有消息处理时处于休眠以避免资源占用、在有消息到来时被唤醒来处理消息。
所以，RunLoop实际上就是一个对象，这个对象管理了其需要处理的事件和消息，并提供了一个入口函数来执行上面的Event Loop的逻辑。
iOS系统中提供了两个这样的对象：NSRunLoop和CFRunLoopRef。
- CFRunLoopRef是在CoreFoundation框架内的，它提供了纯C函数的API，所有这些API都是线程安全的；
- NSRunLoop是基于CFRunLoopRef的封装，提供了面向对象的API，但这些对象不是线程安全的。
CFRunLoopRef是开源的，在这里可以下载到整个CoreFoundation。
RunLoop与线程的关系
iOS里有两个线程对象：NSThread和pthread_t。CFRunloop是基于pthread来管理的。
苹果不允许直接创建RunLoop，它只提供了两个自动获取的函数：CFRunLoopGetMain()和CFRunLoopGetCurrent()。这两个函数内部的逻辑大概是下面这样的：
/// 全局的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 访问 loopsDic 时的锁
static CFSpinLock_t loopsLock;
/// 获取一个 pthread 对应的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
OSSpinLockLock(&loopsLock);
if (!loopsDic) {
// 第一次进入时，初始化全局Dic，并先为主线程创建一个 RunLoop。
loopsDic = CFDictionaryCreateMutable();
CFRunLoopRef mainLoop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
}
/// 直接从 Dictionary 里获取。
CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
if (!loop) {
/// 取不到时，创建一个
loop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic, thread, loop);
/// 注册一个回调，当线程销毁时，顺便也销毁其对应的 RunLoop。
_CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
return loop;
}
CFRunLoopRef CFRunLoopGetMain() {
return _CFRunLoopGet(pthread_main_thread_np());
}
CFRunLoopRef CFRunLoopGetCurrent() {
return _CFRunLoopGet(pthread_self());
}
从上面的代码可以看出，线程和RunLoop之间是一一对应的，线程作为key、CFRunLoopRef作为value保存到了全局的字典里。线程刚创建时没有对应的RunLoop，RunLoop的创建是发生在第一次获取时，RunLoop的销毁是发生在线程结束时。你只能在一个线程的内部获取RunLoop(主线程除外)。
我们的应用程序不需要自己创建RunLoop,而是在合适的时间来启动RunLoop。可以通过 [NSRunLoop currentRunLoop] 或 [NSRunLoop mainRunLoop]来获取RunLoop。
RunLoop对外的接口
在CoreFoundation里面关于RunLoop有5各类：
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
其中CFRunLoopModeRef类并没有对外暴露，只是通过CFRunLoopRef的接口进行了封装。它们的关系如下：
RunLoop的Mode
CFRunLoopMode和CFRunLoop的结构大致如下：
struct __CFRunLoopMode {
CFStringRef _name; // Mode Name, 例如 @"kCFRunLoopDefaultMode"，@"kCFRunLoopCommonModes"
CFMutableSetRef _sources0; // Set
CFMutableSetRef _sources1; // Set
CFMutableArrayRef _observers; // Array
CFMutableArrayRef _timers; // Array
...
};
struct __CFRunLoop {
CFMutableSetRef _commonModes; // Set
CFMutableSetRef _commonModeItems; // Set<Source/Observer/Timer>
CFRunLoopModeRef _currentMode; // Current Runloop Mode
CFMutableSetRef _modes; // Set
...
};
滑动ScrollView时NSTimer失效的问题
主线程的RunLoop里有两个预制的mode：
KCFRunLoopDefaultMode和UITrackingRunLoopMode，这两个Mode都已经被标记为“Common”属性。DefaultMode是App平时所处的状态，TrackingRunLoopMode是追踪scrollView滑动是的状态。NSTimer初始化后默认是KCFRunLoopDefaultMode的状态。
要想让timer在两个状态中都能正常使用，一种方法是将timer分别加入两个mode中，还有一种，就是将timer加入到顶层的RunLoop的“commonModeItems”中。“commonModeItems”被更新到所有具有“Common”属性的Mode里去。
开启一个NSTimer实际上就是在当前的RunLoop中注册了一个新的事件源，当scrollView滑动的过程中，当前的RunLoop会处于UITrackingRunLoopMode的模式下，在这个模式下，是不会处理NSDefaultRunLoopMode的消息。简单地说就是NSTimer不会开启新的进程，只是在RunLoop里注册了一下，RunLoop每次loop时都会检测这个timer，看是否可以触发。当RunLoop处于A Mode中，而timer注册在B Mode时就无法检测到这个timer，所以需要把timer也注册到A Mode，这样就可以检测到。
解决方法：
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
如果定时器所在的runloop没有运行，或者runloop所处的mode和定时器的不一致，都会导致定时器失效。
NSRunLoopMode
typedef NSString *NSRunLoopMode;
NSRunLoopCommonMode：被添加到RunLoop里的对象使用这个mode会被那些已经描述作为“common”Modes的所有的RunLoop所监测到。
NSDefaultRunLoopMode：这个model处理输入源除了NSConnection对象。
NSEventTrackingRunLoopMode
NSModalPanelRunLoopMode
UITrackingRunLoopMode
NSThread
NSThread * th = [[NSThread alloc] initWithTarget:self selector:@selector(test) object:nil];
[th start];
start方法会异步地生成一个新的线程并且在线程中调用NSThread对象的main方法。
start方法只能使用一次，自此调用会引起crash
如果想多次使用这个线程怎么处理呢：
- (void)viewDidLoad {
[super viewDidLoad];
_thread = [[NSThread alloc] initWithTarget:self selector:@selector(startThread) object:nil];
[_thread start];
[self useThread];
[self useThread];
}
- (void)startThread{
NSLog(@"start");
}
- (void)useThread{
[self performSelector:@selector(log) onThread:_thread withObject:nil waitUntilDone:NO];
}jiu
- (void)log{
NSLog(@"log");
}
运行之后发现，log方法并没有调用，原因是线程在执行完startThread方法后，便退出了。为了让线程能够再次使用，可以让线程对应的runLoop运行起来。我们把上面的startThread方法修改一下：
- (void)startThread{
NSRunLoop * runloop = [NSRunLoop currentRunLoop];
[runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runloop run];
}
然后运行可以看到打印的log。
即使RunLoop开始运行，如果RunLoop中的modes为空，或者要执行的mode里没有item，那么RunLoop会直接在当前loop中返回，并进入睡眠状态。
如果把上面的[runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];给去掉，也是没有log的。
当在另外一个线程执行selector的时候，这个线程必须有一个运行的runloop。
如果在主线程里使用 initWithRequest:delegate:startImmediately:创建了一个NSURLConnetion，当调用star方法时，这个NSURLConnetion会被安排到当前的runloop里，并且是默认的mode。如果此时滑动uiscrollview，由于主线程的runloop的mode被切换到UITrackingRunLoopMode,导致NSURLConnetion的代理方法无法回调。
所以需要用到scheduleInRunLoop: scheduleInRunLoop
NSURL * url = [NSURL URLWithString:@"https://www.baidu.com"];
NSURLRequest *request = [[NSURLRequest alloc] initWithURL:url cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:15];
NSURLConnection *connection = [[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:NO];
[connection scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSRunLoopCommonModes];
[connection start];
RunLoop的管理不是全自动的，你仍然需要开启运行runLoop并且在适当的时候处里到来的事件。应用的每一个线程都有对应的RunLoop对象，只有除了主线程之外的线程需要启动运行它们的RunLoop，app的框架会自动的配置和运行主线程的RunLoop。
RunLoop从两个不同类型的源里接收事件。Input sources 异步地传递事件，这些事件通常来源于另外一个线程或应用。Timer Source同步地传递事件，通常发生在预订的时间或重复间隔。
Input Source异步地把事件提交到相应的handles并且调用了runUntilDate:（与线程相关联的RunLoop对象调用这个方法）来退出。Timer Source提供事件到handles但不会引起RunLoop退出。
除了处理Input Source，RunLoop也会生成关于RunLoop运行行为的通知。注册成为RunLoop的观察者可以收到那些通知并且使用它们在线程上做一些额外的处理。
RunLoop的Mode是一个集合，它包括了输入源，timers，observers（会受到通知）。每次你运行了你的RunLoop，你需要为RunLoop指定一个mode。
你可以自定义一个mode，给mode的name设置一个自定义的字符串。你必须要给自定义的mode添加source，timers和observes。
| mode | Name | Description |
|---|---|---|
| Default | NSDefaultRunLoopMode | 大部分情况下，你需要使用这个mode来开启你的RunLoop并且配置你的输入源 |
| Common modes | NSRunLoopCommonModes | 这是一组可配置的常用模式，将输入源于此模式相关联还将其与组中的每种模式向关联。默认情况下，此设置包括了默认模式和事件追踪模式。 |
Input Source
Input Source异步地传递事件到线程里。Input Source通常有两类：一种是基于Port的input source，用于检测应用程序的Mach ports；一种是自定义的input source，用于监测自定义的事件源。这两个源唯一的区别是如何发出信号的，基于Port的源由内核自动发出信号，自定义源必须从另一个线程手动发出信号。
当你创建一个intput source，你可以把它分配到runloop的多个mode中。如果一个intput source不在runloop当下的监测到的mode中，他所生成的任何事件都会被挂起知道runloop切换到正确的mode中。
什么时候使用runloop
应用的主线程是默认开启了runloop。当我们使用自定义的线程时，如果想要向和线程进行更多的交互，想要线程处于活跃状态，就要考虑使用runloop。
如果使用到了以下操作，需要使用runloop：
- 使用了port或自定义的inputsource来与其他线程通信；
- 在线程中使用了定时器；
- 在线程中使用了performSelector：
- 保持线程执行周期性的任务。
RunLoop对象
在run一个runloop之前，必须要至少添加一个inputsource，否则run后runloop会立即退出。
除了添加inputsource，也可以添加observes来监测runloop的运行状态。你可以使用CFRunLoopObserveRef来创建对象并使用CFRunLoopAddObserve函数来添加。RunLoop Observe必须使用Core Foundation框架来创建。
