什么是RunLoop，RunLoop有哪些使用场景
每次面试，Runloop这个概念几乎是必问的。所以，还是写点东西出来做个记录，同时也加深一下自己的记忆。
一.什么是RunLoop
RunLoop 既运行循环机制，在应用级别考虑，应用程序中所有的任务处理（用户交互事件、网络请求回调数据接收等）都是在线程中执行，一般来讲一个线程一次只能执行一个任务，执行完线程销毁（OC 中子线程异步销毁，主线程除外），但是问题来了如何让线程保活呢？并且如何让线程在没有处理消息时休眠以避免资源占用、在有消息到来时立刻被唤醒呢？RunLoop 就是解决这些问题的，它所做的一切都是基于线程，可以说是为线程而生
OSX/iOS 系统中，提供的 两个 RunLoop 对象：CFRunLoopRef是在 CoreFoundation 框架内的，它提供了纯 C 函数的 API，且其是开源的，开源下载地址(CoreFoundation 源码)。NSRunLoop是基于 CFRunLoopRef 的封装，提供了面向对象的 API，并不开源。分析 CoreFoundation 库内的 RunLoop 源码分析。CoreFoundation 源码中 CFRunLoop 关于 RunLoop 的有五个类：
CFRunLoopRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
CFRunLoopModeRef
这五大类是如何通过C语言封装成的呢 ?
typedefstruct__CFRunLoop*CFRunLoopRef;
typedefstruct__CFRunLoopSource*CFRunLoopSourceRef;
typedefstruct__CFRunLoopObserver*CFRunLoopObserverRef;
typedefstruct__CFRunLoopTimer*CFRunLoopTimerRef;
由 CFRunLoop.h文件查看到如上源码
typedefstruct__CFRunLoopMode*CFRunLoopModeRef;
由 CFRunLoopModeRef 类于CFRunLoop.c 第 521 行可找到，下面具体分析其各种的源码结构
RunLoop
CFRunLoop.c文件中 第 636 行：
struct__CFRunLoop{
CFRuntimeBase _base;
pthread_mutex_t_lock;/* locked for accessing mode list */
__CFPort _wakeUpPort;// used for CFRunLoopWakeUp 内核向该端口发送消息可以唤醒
runloopBoolean _unused;
volatile_per_run_data *_perRunData;// reset for runs of the run loop
pthread_t_pthread;//RunLoop对应的线程
uint32_t_winthread;
CFMutableSetRef _commonModes;//存储的是字符串，记录所有标记为common的mode
CFMutableSetRef _commonModeItems;//等同NSMutableSet 存储所有commonMode的item(source、timer、observer)
CFRunLoopModeRef _currentMode;//当前运行的mode
CFMutableSetRef _modes;//存储的是CFRunLoopModeRef
struct_block_item*_blocks_head;//doblocks的时候用到
struct_block_item*_blocks_tail;
CFTypeRef _counterpart;
};
由源码可知，一个RunLoop对象，主要包含了对应的一个线程，若干个 Mode，若干个 commonMode，还有一个当前运行的 Mode（_currentMode）。
我们并不能去创建这个 CFRunLoopRef（为什么呢？），而是通过如下方法去获取当前线程的 RunLoop：
// CFRunLoop.h 中73行源码
CF_EXPORT CFRunLoopRef CFRunLoopGetCurrent(void);// 获取当前线程runloop
CF_EXPORT CFRunLoopRef CFRunLoopGetMain(void);// 获取主线程 runloop
具体使用姿势：
// 获取当前Runloop
CFRunLoopRef runloop =CFRunLoopGetCurrent();
RunLoopMode - 运行模式
CFRunLoop.c文件中 第 523 行：
struct__CFRunLoopMode{
CFRuntimeBase _base;
pthread_mutex_t _lock;/* must have the run loop locked before locking this */
CFStringRef _name;//mode名称
Boolean _stopped;//mode是否被终止
char _padding[3];
//几种事件
CFMutableSetRef _sources0;//sources0
CFMutableSetRef _sources1;//sources1
CFMutableArrayRef _observers;//通知
CFMutableArrayRef _timers;//定时器
CFMutableDictionaryRef _portToV1SourceMap;//字典 key是mach_port_t，value是CFRunLoopSourceRef
__CFPortSet _portSet;//保存所有需要监听的port，比如_wakeUpPort，_timerPort都保存在这个数组中
CFIndex _observerMask;
#ifUSE_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;
#end
if#ifUSE_MK_TIMER_TOOmach_port_t _timerPort;
Boolean _mkTimerArmed;
#endif
#ifDEPLOYMENT_TARGET_WINDOWS
DWORD _msgQMask;
void (*_msgPump)(void);
#endif
uint64_t _timerSoftDeadline;/* TSR */
uint64_t _timerHardDeadline;/* TSR */
};
一个 CFRunLoopMode 对象有一个 name ，若干 source0、source1、timer、observer和若干port，所有事件都是由 Mode 在管理，而 一个线程下的 RunLoop 管理着若干个 Mode (ModeItems)。在一个线程中 runloop 保活线程并且在 指定 Mode下使其接受处理事件，又在每次 runloop 循环中(之前讲的死循环概念)进行 Mode间的切换。
Cocoa框架和Core Foundation框架中定义了五种 Mode (Guides and Sample Code )
Default 默认Mode，APP运行起来之后，主线程的RunLoop默认在该Mode下运行
NSDefaultRunLoopModeCocoa 框架
kCFRunLoopDefaultModeCore Foundation 框架
Event tracking 追踪触摸的手势，所有 UI 交互事件都运行在这个Mode下
UITrackingRunLoopMode(Cocoa)
Common modes 共有型 Model 含有上面两种Mode模式的意义
NSRunLoopCommonModes(Cocoa)
kCFRunLoopCommonModes(Core Foundation)
Connection 系统内核模式，系统调用事件发生会切换到相应模式下，开发者无法操作
GSEventReceiveRunLoopMode(Cocoa)
Modal 项目初始化模式，只会走一次
UIInitializationRunLoopMode(Cocoa)
RunLoop Source - 事件源
CFRunLoop.c文件中 第 943 行：
struct __CFRunLoopSource {
CFRuntimeBase _base;
uint32_t _bits;//用于标记Signaled状态，source0只有在被标记为Signaled状态，才会被处理
pthread_mutex_t _lock;
CFIndex_order;/* immutable */
CFMutableBagRef _runLoops;
union{
CFRunLoopSourceContextversion0;/* immutable, except invalidation */
CFRunLoopSourceContext1version1;/* immutable, except invalidation */
} _context;
};
事件源顾名思义事件的产生地，由上源码会发现 Source 分为两种：
Source0 非基于Port的
只包含了一个回调（函数指针），它并不能主动触发事件。使用时，你需要先调用 CFRunLoopSourceSignal(source)，将这个 Source 标记为待处理 signal 状态，然后手动调 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop，让其处理这个事件。
其作用范围是应用程序中事件，由App自己管理的UIEvent、CFSocket都是source0。以下是source0的结构体：
typedef struct{
CFIndex version;
void* info;
const void*(*retain)(constvoid*info);
void(*release)(constvoid*info);
CFStringRef(*copyDescription)(constvoid*info);
Boolean (*equal)(constvoid*info1,constvoid*info2);
CFHashCode(*hash)(constvoid*info);
void(*schedule)(void*info,CFRunLoopRefrl,CFStringRefmode);
void(*cancel)(void*info,CFRunLoopRefrl,CFStringRefmode);
void(*perform)(void*info);
}CFRunLoopSourceContext;
Source1
包含了一个 mach_port 和一个回调（函数指针），被用于通过内核和其他线程相互发送消息。可以接收内核消息并触发回调，这种 Source 能主动唤醒 RunLoop 的线程。
其作用范围是由RunLoop和内核管理，source1带有mach_port_t，可以接收内核消息并触发回调，以下是source1的结构体:
typedef struct{
CFIndex version;
void* info;
constvoid*(*retain)(constvoid*info);
void(*release)(constvoid*info);
CFStringRef(*copyDescription)(constvoid*info);
Boolean (*equal)(constvoid*info1,constvoid*info2);
CFHashCode(*hash)(constvoid*info);
#if (TARGET_OS_MAC && !(TARGET_OS_EMBEDDED || TARGET_OS_IPHONE)) || (TARGET_OS_EMBEDDED || TARGET_OS_IPHONE)
mach_port_t (*getPort)(void*info);
void* (*perform)(void*msg,CFIndexsize,CFAllocatorRefallocator,void*info);
#else
void* (*getPort)(void*info);
void(*perform)(void*info);
#endif
}CFRunLoopSourceContext1;
CFRunLoopObserver - 观察者
CFRunLoop.c文件中 第 981 行：
struct__CFRunLoopObserver {
CFRuntimeBase _base;
pthread_mutex_t _lock;
CFRunLoopRef _runLoop;
CFIndex _rlCount;
CFOptionFlags _activities; /* immutable */
CFIndex _order; /* immutable */
CFRunLoopObserverCallBack _callout; /* immutable */
CFRunLoopObserverContext _context; /* immutable, except invalidation */
};
Observer 是 mode 下数组保存 ，其都包含了一个回调（函数指针），当 RunLoop 的状态发生变化时，观察者就能通过回调接受到这个变化。回调函数CFRunLoopObserverCallBack
CFRunLoopObserver 可以观察的状态有如下6种:
/* Run Loop Observer Activities */
typedefCF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL <<0),
kCFRunLoopBeforeTimers = (1UL <<1),
kCFRunLoopBeforeSources = (1UL <<2),
kCFRunLoopBeforeWaiting = (1UL <<5),
kCFRunLoopAfterWaiting = (1UL <<6),
kCFRunLoopExit = (1UL <<7),
kCFRunLoopAllActivities =0x0FFFFFFFU
};
CFRunLoopTimer
CFRunLoop.c文件中 第 1049 行：
struct__CFRunLoopTimer {
CFRuntimeBase _base;
uint16_t _bits;
pthread_mutex_t _lock;
CFRunLoopRef _runLoop;
CFMutableSetRef _rlModes;
CFAbsoluteTime _nextFireDate;
CFTimeInterval _interval; /* immutable */
CFTimeInterval _tolerance; /* mutable */
uint64_t _fireTSR; /* TSR units */
CFIndex _order; /* immutable */
CFRunLoopTimerCallBack _callout; /* immutable */
CFRunLoopTimerContext _context; /* immutable, except invalidation */
};
是基于时间的触发器，它和 NSTimer 是toll-free bridged的，可以相互转换的。其包含一个时间长度和一个回调（函数指针）。当其加入到 RunLoop 时，可以在设定的时间点 RunLoop 会被唤醒并执行回调。
RunLoop 与线程的关系
苹果不允许直接创建 RunLoop，它只提供了两个自动获取的函数：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 这两个函数内部的逻辑大概是下面这样:
CFRunLoopRef CFRunLoopGetMain(void) {
CHECK_FOR_FORK();
staticCFRunLoopRef __main =NULL;// no retain needed
if(!__main) __main = _CFRunLoopGet0(pthread_main_thread_np());// no CAS needed
return__main;
}
CFRunLoopRef CFRunLoopGetCurrent(void) {
CHECK_FOR_FORK();
CFRunLoopRef rl = (CFRunLoopRef)_CFGetTSD(__CFTSDKeyRunLoop);
if(rl)returnrl;
return_CFRunLoopGet0(pthread_self());
}
获取RunLoop函数
staticCFMutableDictionaryRef __CFRunLoops =NULL;
staticCFSpinLock_t loopsLock = CFSpinLockInit;
// should only be called by Foundation
// t==0 is a synonym for "main thread" that always works
CF_EXPORT CFRunLoopRef _CFRunLoopGet0(pthread_t t) {
if(pthread_equal(t, kNilPthreadT)) {
t = pthread_main_thread_np();
}
__CFSpinLock(&loopsLock);
if(!__CFRunLoops) {
__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);
}
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);
}
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);
}
}
returnloop;
从上面的代码可以看出，线程和 RunLoop 之间是一一对应的，其关系是保存在一个全局的 Dictionary 里。线程刚创建时并没有 RunLoop，如果你不主动获取，那它一直都不会有。RunLoop 的创建是发生在第一次获取时，RunLoop 的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop（主线程除外）。
AutoreleasePool和RunLoop
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 的) 用来接收系统事件，其回调函数为 __IOHIDEventSystemClientQueueCallback()。
当一个硬件事件(触摸/锁屏/摇晃等)发生后，首先由 IOKit.framework 生成一个 IOHIDEvent 事件并由 SpringBoard 接收。这个过程的详细情况可以参考这里。SpringBoard 只接收按键(锁屏/静音等)，触摸，加速，接近传感器等几种 Event，随后用mach port 转发给需要的App进程。
随后苹果注册的那个 Source1 就会触发回调，并调用 _UIApplicationHandleEventQueue() 进行应用内部的分发,此过程是Source0 完成的。
_UIApplicationHandleEventQueue() 会把 IOHIDEvent 处理并包装成 UIEvent 进行处理或分发，其中包括识别 UIGesture/处理屏幕旋转/发送给 UIWindow 等。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的
手势识别
当上面的 _UIApplicationHandleEventQueue() 识别了一个手势时，其首先会调用 Cancel 将当前的 touchesBegin/Move/End 系列回调打断。随后系统将对应的 UIGestureRecognizer 标记为待处理。
苹果注册了一个 Observer 监测 BeforeWaiting (Loop即将进入休眠) 事件，这个Observer的回调函数是 _UIGestureRecognizerUpdateObserver()，其内部会获取所有刚被标记为待处理的 GestureRecognizer，并执行GestureRecognizer的回调。
当有 UIGestureRecognizer 的变化(创建/销毁/状态改变)时，这个回调都会进行相应处理。
界面刷新
当UI改变（ Frame变化、 UIView/CALayer 的继承结构变化等）时，或手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer 就被标记为待处理。
苹果注册了一个用来监听BeforeWaiting和Exit的Observer，在它的回调函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面
定时器
当使用NSTimer的scheduledTimerWithTimeInterval方法时。事实上此时Timer会被加入到当前线程的Run Loop中，且模式是默认的NSDefaultRunLoopMode。而如果当前线程就是主线程，也就是UI线程时，某些UI事件，比如UIScrollView的拖动操作，会将Run Loop切换成NSEventTrackingRunLoopMode模式，在这个过程中，默认的NSDefaultRunLoopMode模式中注册的事件是不会被执行的。也就是说，此时使用scheduledTimerWithTimeInterval添加到Run Loop中的Timer就不会执行。
所以为了设置一个不被UI干扰的Timer，我们需要手动创建一个Timer，然后使用NSRunLoop的addTimer:forMode:方法来把Timer按照指定模式加入到Run Loop中。这里使用的模式是：NSRunLoopCommonModes，这个模式等效于NSDefaultRunLoopMode和NSEventTrackingRunLoopMode的结合。
无论是单次执行的NSTimer还是重复执行的NSTimer都不是准时的，这与当前NSTimer所处的线程有很大的关系，如果NSTimer当前所处的线程正在进行大数据处理(假设为一个大循环)，NSTimer本次执行会等到这个大数据处理完毕之后才会继续执行
这期间有可能会错过很多次NSTimer的循环周期，但是NSTimer并不会将前面错过的执行次数在后面都执行一遍，而是继续执行后面的循环，也就是在一个循环周期内只会执行一次循环。
无论循环延迟的多离谱，循环间隔都不会发生变化，在进行完大数据处理之后，有可能会立即执行一次NSTimer循环，但是后面的循环间隔始终和第一次添加循环时的间隔相同。这个事件是怎么执行的？并且为什么有的时候会延迟？为什么子线程中创建的Timer并不执行？
首先，在进入循环开始以后，就要处理source0事件，处理后检测一下source1端口是否有消息，如果一个Timer的时间间隔刚好到了则此处有可能会得到一个消息，则runLoop直接跳转至端口激活处从而去处理Timer事件。
第二，为什么会延迟？我们知道，两次端口事件是在两个runLoop循环中分别执行的。比如Timer的时间间隔为1秒，在第一次Timer回调结束后，在很短时间内立即进入runLoop的下一次循环，这次并不是Timer回调并且是一个计算量非常大的任务，计算时间超过了1秒，那么runLoop的第二个循环就要执行很久，无法进入下一个循环等待有可能即将到来的Timer第二次回调的信号，所以Timer第二次回调就会推迟了。
第三，为什么在子线程中创建的Timer并且提交到当前runLoop中并不会运行？这还是要从runLoop的获取函数中看，当调用currentRunLoop的时候会取当前线程对应的runLoop，而首次是取不到的，则会创建一个新的runLoop。但是！这个runLoop并没有run。就是没有开启
- (void)applicationDidBecomeActive:(UIApplication*)application{
// NSThread 创建一个子线程
[NSThreaddetachNewThreadSelector:@selector(testTimerSheduleToRunloop1) toTarget:selfwithObject:nil];
}
// 测试把timer加到不运行的runloop上的情况
- (void)testTimerSheduleToRunloop1
{
NSLog(@"Test timer shedult to a non-running runloop");
SvTestObject *testObject4 = [[SvTestObject alloc] init];
NSTimer*timer = [[NSTimeralloc] initWithFireDate:[NSDatedateWithTimeIntervalSinceNow:1] interval:1target:testObject4 selector:@selector(timerAction:) userInfo:nilrepeats:NO];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
// 打开下面一行输出runloop的内容就可以看出，timer却是已经被添加进去//
NSLog(@"the thread's runloop: %@", [NSRunLoop currentRunLoop]);
// 下面一行, 该线程的runloop就会运行起来，timer才会起作用
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:3]];
NSLog(@"invoke release to testObject4");
}
- (void)applicationWillResignActive:(UIApplication*)application
{
NSLog(@"SvTimerSample Will resign Avtive!");
}
PerformSelecter
当调用 NSObject 的 performSelecter:afterDelay: 后，实际上其内部会创建一个 Timer 并添加到当前线程的 RunLoop 中。所以如果当前线程没有 RunLoop，则这个方法会失效。
当调用 performSelector:onThread: 时，实际上其会创建一个 Timer 加到对应的线程去，同样的，如果对应线程没有 RunLoop 该方法也会失效。
Runloop 开发中运用
滑动与图片刷新：
当tableview的cell上有需要从网络获取的图片的时候，滚动tableView，异步线程会去加载图片，加载完成后主线程就会设置cell的图片，但是会造成卡顿。可以让设置图片的任务在CFRunLoopDefaultMode下进行，当滚动tableView的时候，RunLoop是在 UITrackingRunLoopMode 下进行，不去设置图片，而是当停止的时候，再去设置图片。
GCD
实际上 RunLoop 底层也会用到 GCD 的东西，当调用 dispatch_async(dispatch_get_main_queue(), block) 时，libDispatch 会向主线程的 RunLoop 发送消息，RunLoop会被唤醒，并从消息中取得这个 block，并在回调 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里执行这个 block。但这个逻辑仅限于 dispatch 到主线程，dispatch 到其他线程仍然是由 libDispatch 处理的。
友情链接：
