?xml version="1.0" encoding="UTF-8"?
参考文章：深入理解RunLoop
RunLoop的作用？
保持程序运行。一般来说一个线程一次只能执行一次任务，执行完成后线程会退出。RunLoop能够保证线程执行完任务后不退出。
处理App的各种事件（触摸事件、timer事件、seletor事件等）
节省CPU资源，提高程序性能。线程休眠时不占用cpu资源，等待唤醒执行任务
哪些可以唤醒runloop？
Source
当调用dispatch_async(dispatch_get_main_queue(),block)时
Timer
外表手动唤醒
Runloop对象？
Fundation框架
NSRunLoop（基于CFRunloopRef的封装，面向对象的API，线程不安全）
CoreFundation
CFRunLoopRef，纯C函数的API，线程安全
CFRunLoopRef 的代码是开源的，可以在这里 http://opensource.apple.com/tarballs/CF/CF-855.17.tar.gz 下载到整个CoreFoundation的源码。
获取RunLoop对象
苹果不允许直接创建RunLoop对象，但是提供了函数获取。
RunLoop对象通过懒加载获取
Fundation
[NSRunloop currentRunLoop] // 获取当前线程的RunLoop对象
[NSRunloop mainRunLoop] // 获取主线程的RunLoop对象
CoreFundation
CFRunLoopGetCurrent(); // 获取当前线程的RunLoop对象
CFRunLoopGetMain(); // 获取主线程的RunLoop对象
RunLoop和线程的关系
1.每一条线程都有唯一的一个与之对象的RunLoop对象
2.主线程的RunLoop在启动的时候程序自动创建，子线程的RunLoop不会自动创建。
3.Runloop在第一次获取时创建（懒加载），在线程结束时销毁
RunLoop源码：
CF_EXPORT CFRunLoopRef _CFRunLoopGet0(pthread_t t){
if(pthread_equal(t,kNilPthreadT)){
t = pthread_main_thread_np();
}
// 创建主线程中的runloop对象
//__CFRunLoops 全局的Dictionary对象，key时p_thread，value是CFRunLoopRef。保存线程和Runloop，维护线程和Runloop的一一对应关系
__CFSpinLock(&loopsLock);
if(!__CFRunLoops){
// 第一次进入时创建__CFRunLoops，并且为主线程创建一个RunLoop对象
__CFSpinUnlock(&loopsLock);
CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault,0,NULL,&kCFTypeDictionaryValueCallBacks);
CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np());
CFDictionarySetValue(dict,pthreadPointer(pthread_main_thread_np()),mainLoop);
if(!OSAtomicCompareAndSwapPtrBarrier(NULL,dict,(void * volatile *)&__CFRunLoops)){
CFRelease(dict);
}
CFRelease(mainLoop);
__CFSpinLock(&loopsLock);
}
// 从全局的Dictio中获取runloop
CFRunLoopRef loop =(CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops,pthreadPointer(t));
__CFSpinUnlock(&loopsLock);
if(!loop){
CFRunLoopRef newLoop = __CFRunLoopCreate(t);
__CFSpinLock(&loopsLock);
loop =(CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops,pthreadPointer(t));
if(!loop){
CFDictionarySetValue(__CFRunLoops,pthreadPointer(t),newLoop);
loop = newLoop;
}
// don't release run loops inside the loopsLock,because CFRunLoopDeallocate may end up taking it
__CFSpinUnlock(&loopsLock);
CFRelease(newLoop);
}
// 注册一个回调，当线程销毁时，销毁RunLoop
if(pthread_equal(t,pthread_self())){
_CFSetTSD(__CFTSDKeyRunLoop,(void *)loop,NULL);
if(0 == _CFGetTSD(__CFTSDKeyRunLoopCntr)){
_CFSetTSD(__CFTSDKeyRunLoopCntr,(void *)(PTHREAD_DESTRUCTOR_ITERATIONS-1),(void(*)(void *))__CFFinalizeRunLoop);
}
}
return loop;
}
从上面的代码中可以看出，线程和RunLoop对象时一一对应的关系，对应关系保存在一个Dictionary中。所以我们在子线程中使用[NSRunloop currentRunLoop]获取RunLoop对象时，如果Dictionary中没有，则会去创建一个，并保存在Dictionary中。如果不获取RunLoop对象则不会去创建。RunLoop的销毁是发生在线程结束时。
RunLoop相关的类
Core Fundation中RunLoop相关的类有5个
CFRunLoopRef：RunLoop对象
CFRunLoopModeRef：RunLoop所在的运行模式
CFRunLoopSourceRef：事件源
CFRunLoopTimerRef：定时器
CFRunLoopObserverRef：观察者
CFRunLoopModeRef
CFRunLoopModeRef
CFRunLoopModeRef类并没有对外暴露，只是通过CFRunLoopRef的接口进行了封装。他们的关系如下
一个RunLoop包含若干个Mode，一个Mode中又包含若干个Source/Timer/Observer。每次调用RunLoop的主函数时，只能指定一个Mode，这个Mode就是CurrentMode。如果需要切换Mode，则必须退出RunLoop，再重新指定一个Mode进入。这样做是为了分隔开不同组中的Source/Timer/Observer，让其互不影响。
CFRunLoopSourceRef
CFRunLoopSourceRef是事件产生的地方。Source有两个版本：Source0和Source1
Source0只包含一个回调（函数指针），它并不会主动触发事件。使用时，需要先调用CFRunLoopSourceSignal(source)，将这个soucre标记为待处理，然后手动调用CFRunLoopSourceWakeUp(runloop)来唤醒RunLoop，让其处理这个事件。（点击按钮、点击屏幕）
Source1包含一个mach_port和一个回调（函数指针），被用于用过内核和其他线程相互发送消息。这种Source能注定唤醒RunLoop的线程。硬件事件(触摸/锁屏/摇晃等)
CFRunLoopTimerRef
CFRunLoopTimerRef是基于时间的触发器，他和NSTimer时toll-free bridged的，可以混用。包含一个时间长度和一个回调（函数指针）。当其加入到RunLoop时，RunLoop会注册对应的时间点，当时间点到时，RunLoop会被唤醒以执行那个回调。
CFRunLoopObserverRef
CFRunLoopObserverRef是观察者，每一个Observer都包含了一个回调（函数指针），当RunLoop的状态发生变化时，观察者就能通过回调接收到这个变化。
可以观测的点有一下几个：
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), // 即将退出Loop
};
上面的source、timer、observer被统称为mode item，一个item可以被加入多个mode中。单一个item被重复加入同一个mode时没有效果的。如果mode中一个item都没有，则RunLoop会直接退出，不进入循环。
RunLoop的Mode
CFRunLoop和CFRunLoopMode的结构大致如下
struct __CFRunLoopMode {
CFStringRef _name; // Mode Name, 例如 @"kCFRunLoopDefaultMode"
CFMutableSetRef _sources0; // Set
CFMutableSetRef _sources1; // Set
CFMutableArrayRef _observers; // Array
CFMutableArrayRef _timers; // Array
...
};
struct __CFRunLoop {
CFMutableSetRef _commonModes; // Set
CFMutableSetRef _commonModeItems; // Set
CFRunLoopModeRef _currentMode; // Current Runloop Mode
CFMutableSetRef _modes; // Set
...
};
这里有个概念叫“CommonModes”：一个Mode可以将自己标记为“Common”属性（通过将其的ModeName添加到RunLoop的“CommonModes”中）。每当RunLoop的内容发生变化的时候都会自动将_commonModeItems里的Source/Observer/Timer同步到具有“Common”标记的所有Mode中。
应用场景举例：主线程的RunLoop里有两个预置的Mode：kCFRunLoopDefaultMode和UITrackingRunLoopMode。这两个Mode都已经被标记为"Common"属性。DefaultMode是App平时所处的状态，TrackingRunLoopMode是追踪ScrollView滑动时的状态。当你创建一个Timer并加到DefaultMode时，Timer会得到重复回调，但此时滑动一个TableView时，RunLoop会将mode切换为TrackingRunLoopMode，这时Timer就不会被回调，并且也不会影响到滑动操作。
有时你需要一个Timer，在两个Mode中都能得到回调，一种办法就是将这个Timer分别加入这两个Mode。还有一种方式，就是将Timer加入到顶层的RunLoop的"commonModeItems"中。"commonModeItems"被RunLoop自动更新到所有具有"Common"属性的Mode里去。
CFRunLoop对外暴露的管理Model的接口只有下面两个：
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);
Mode暴露的管理mode item的接口有下面几个
CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopAddObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopAddTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
CFRunLoopRemoveSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopRemoveObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopRemoveTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
RunLoop的内部逻辑
/// 用DefaultMode启动
void CFRunLoopRun(void) {
CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}
/// 用指定的Mode启动，允许设置RunLoop超时时间
int CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean stopAfterHandle) {
return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}
/// RunLoop的实现
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
/// 首先根据modeName找到对应mode
CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
/// 如果mode里没有source/timer/observer, 直接返回。
if (__CFRunLoopModeIsEmpty(currentMode)) return;
/// 1. 通知 Observers: RunLoop 即将进入 loop。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
/// 内部函数，进入loop
__CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
Boolean sourceHandledThisLoop = NO;
int retVal = 0;
do {
/// 2. 通知 Observers: RunLoop 即将触发 Timer 回调。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: RunLoop 即将触发 Source0 (非port) 回调。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
/// 执行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 4. RunLoop 触发 Source0 (非port) 回调。
sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
/// 执行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 5. 如果有 Source1 (基于port) 处于 ready 状态，直接处理这个 Source1 然后跳转去处理消息。
if (__Source0DidDispatchPortLastTime) {
Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
if (hasMsg) goto handle_msg;
}
/// 通知 Observers: RunLoop 的线程即将进入休眠(sleep)。
if (!sourceHandledThisLoop) {
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
}
/// 7. 调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。
/// ? 一个基于 port 的Source 的事件。
/// ? 一个 Timer 到时间了
/// ? RunLoop 自身的超时时间到了
/// ? 被其他什么调用者手动唤醒
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort) {
mach_msg(msg, MACH_RCV_MSG, port); // thread wait for receive msg
}
/// 8. 通知 Observers: RunLoop 的线程刚刚被唤醒了。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);
/// 收到消息，处理消息。
handle_msg:
/// 9.1 如果一个 Timer 到时间了，触发这个Timer的回调。
if (msg_is_timer) {
__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
}
/// 9.2 如果有dispatch到main_queue的block，执行block。
else if (msg_is_dispatch) {
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
}
/// 9.3 如果一个 Source1 (基于port) 发出事件了，处理这个事件
else {
CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
if (sourceHandledThisLoop) {
mach_msg(reply, MACH_SEND_MSG, reply);
}
}
/// 执行加入到Loop的block
__CFRunLoopDoBlocks(runloop, currentMode);
if (sourceHandledThisLoop && stopAfterHandle) {
/// 进入loop时参数说处理完事件就返回。
retVal = kCFRunLoopRunHandledSource;
} else if (timeout) {
/// 超出传入参数标记的超时时间了
retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(runloop)) {
/// 被外部调用者强制停止了
retVal = kCFRunLoopRunStopped;
} else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
/// source/timer/observer一个都没有了
retVal = kCFRunLoopRunFinished;
}
/// 如果没超时，mode里没空，loop也没被停止，那继续loop。
} while (retVal == 0);
}
/// 10. 通知 Observers: RunLoop 即将退出。
__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}
RunLoop的使用
AutoreleasePool
即将进入Runloop的时候创建AutoreleasePool。
RunLoop即将进入休眠的时候释放并创建新的AutoreleasePool。
即将退出Runloop的时候释放AutoreleasePool。
App启动后，苹果在主线程RunLoop里注册了两个Observer，其回调都是_wrapRunLoopWithAutoreleasePoolHandler()。
第一个Observer监视的事件是Entry(即将进入Loop)，其回调内会调用_objc_autoreleasePoolPush()创建自动释放池。其order是-2147483647，优先级最高，保证创建释放池发生在其他所有回调之前。
第二个Observer监视了两个事件：BeforeWaiting(准备进入休眠)时调用_objc_autoreleasePoolPop()和_objc_autoreleasePoolPush()释放旧的池并创建新池；Exit(即将退出Loop)时调用_objc_autoreleasePoolPop()来释放自动释放池。这个Observer的order是2147483647，优先级最低，保证其释放池子发生在其他所有回调之后。
在主线程执行的代码，通常是写在诸如事件回调、Timer回调内的。这些回调会被RunLoop创建好的AutoreleasePool环绕着，所以不会出现内存泄漏，开发者也不必显示创建Pool了。
事件响应
苹果注册了一个Source1（基于mach_port的）用来接收系统事件
手势识别
苹果注册了一个Observer监测BeforeWaiting(Loop即将进入休眠)事件，这个Observer的回调函数是_UIGestureRecognizerUpdateObserver()，其内部会获取所有刚被标记为待处理的GestureRecognizer，并执行GestureRecognizer的回调。
界面更新
当在操作UI时，比如改变了Frame、更新了UIView/CALayer的层次时，或者手动调用了UIView/CALayer的setNeedsLayout/setNeedsDisplay方法后，这个UIView/CALayer就被标记为待处理，并被提交到一个全局的容器去。
苹果注册了一个Observer监听BeforeWaiting(即将进入休眠)和Exit(即将退出Loop)事件，回调去执行一个函数。这个函数会遍历所有待处理的UIView/UILayer以执行实际的绘制和调整，并更新UI
定时器
NSTimer其实就是CFRunLoopTimerRef，他们之间是toll-free bridged的。一个NSTimer注册到RunLoop后，RunLoop会为其重复的时间点注册好事件。例如10:00,10:10,10:20这几个时间点。RunLoop为了节省资源，并不会在非常准确的时间点回调这个Timer。Timer有个属性叫做Tolerance(宽容度)，标示了当时间点到后，容许有多少最大误差。
如果某个时间点被错过了，例如执行了一个很长的任务，则那个时间点的回调也会跳过去，不会延后执行。就比如等公交，如果10:10时我忙着玩手机错过了那个点的公交，那我只能等10:20这一趟了。
CADisplayLink是一个和屏幕刷新率一致的定时器（但实际实现原理更复杂，和NSTimer并不一样，其内部实际是操作了一个Source）。如果在两次屏幕刷新之间执行了一个长任务，那其中就会有一帧被跳过去（和NSTimer相似），造成界面卡顿的感觉。在快速滑动TableView时，即使一帧的卡顿也会让用户有所察觉。Facebook开源的AsyncDisplayLink就是为了解决界面卡顿的问题，其内部也用到了RunLoop。
PerformSelector
当调用NSObject的performSelecter:afterDelay:后，实际上其内部会创建一个Timer并添加到当前线程的RunLoop中。所以如果当前线程没有RunLoop，则这个方法会失效。
当调用performSelector:onThread:时，实际上其会创建一个Timer加到对应的线程去，同样的，如果对应线程没有RunLoop该方法也会失效。
GCD
当调用dispatch_async(dispatch_get_main_queue(),block)时，libDispatch会向主线程的RunLoop发送消息，RunLoop会被唤醒，并从消息中取得这个block，并在回调__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()里执行这个block。但这个逻辑仅限于dispatch到主线程，dispatch到其他线程仍然是由libDispatch处理的。
