我们常常会遇到或者被问到，NSRunloop到底是什么以及有什么作用？作为一枚iOS开发的老菜鸟......我是这样理解的：

如果我们子线程需要依赖另一事务(通常是另一线程)的某个状态，为了不让子线程一直处于while循环(亲身经历：有while死循环时退后台会时CPU占用增加而导致发热...)，又想让线程一直运行......

那么NSRunloop就是为了保活我们子线程而存在的，它在接受一些特定事件后能够”唤醒“线程，处理完毕后再让线程”休眠“，这样就能合理的调控系统资源。主线程能够接收到ui以及其他事件，也是通过rl来传递的，主线程的runloop是默认开启的，而子线程的runloop需要我们”手动“开启，我们来看下相关源码：

获取rl

我们无法直接创建子线程的runloop，而是通过GetCurrent获取当前runloop，底层会判断是否存在，如果没有则创建runloop，并放入table里。下次直接从table里返回runloop。

我们再看下NSRunloop的对象，它实际是一个cfrunloop的结构体，里面有锁、Modes、ModeItems等。

NSRunloop对象

这里再引入RunLoop主要涉及的五个类：

CFRunLoop：RunLoop对象、

CFRunLoopMode：五种RunLoop运行模式、

CFRunLoopSource：输入源/事件源，包括Source0 和 Source1

CFRunLoopTimer：定时源，就是NSTimer、

CFRunLoopObserver：观察者，用来监听RunLoop。

CFRunLoopMode：RunLoop运行模式，有五种：

①kCFRunLoopDefaultMode：默认的运行模式，通常主线程是在这个 Mode 下运行的。

②UITrackingRunLoopMode：界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响。

③UIInitializationRunLoopMode：在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用。

④GSEventReceiveRunLoopMode：接受系统事件的内部 Mode，通常用不到。

⑤kCFRunLoopCommonModes：是一个伪模式，可以在标记为CommonModes的模式下运行，RunLoop会自动将_commonModeItems里的 Source、Observer、Timer 同步到具有此标记的Mode里。

CFRunLoopSource：输入源/事件源，包括Source0 和 Source1两种：

Source1：基于mach_Port，处理来自系统内核或其它进程的事件，比如点击手机屏幕。

Source0 ：非基于Port的处理事件，也就是应用层事件，需要手动标记为待处理和手动唤醒RunLoop。

简单举例：一个APP在前台静止，用户点击APP界面，屏幕表面的事件会先包装成Event告诉source1(mach_port)，source1唤醒RunLoop将事件Event分发给source0，由source0来处理。

CFRunLoopTimer：定时源，就是NSTimer。在预设的时间点唤醒RunLoop执行回调。因为它是基于RunLoop的，因此它不是实时的（就是NSTimer 是不准确的。 因为RunLoop只负责分发源的消息。如果线程当前正在处理繁重的任务，就有可能导致Timer本次延时，或者少执行一次）。

CFRunLoopObserver：观察者，用来监听以下时间点：CFRunLoopActivity

kCFRunLoopEntry：RunLoop准备启动

kCFRunLoopBeforeTimers：RunLoop将要处理一些Timer相关事件

kCFRunLoopBeforeSources：RunLoop将要处理一些Source事件

kCFRunLoopBeforeWaiting：RunLoop将要进行休眠状态,即将由用户态切换到内核态

kCFRunLoopAfterWaiting：RunLoop被唤醒，即从内核态切换到用户态后

kCFRunLoopExit：RunLoop退出

kCFRunLoopAllActivities：监听所有状态

从runloop结构体可以看出，runloop对象里可以有多个mode，实际上mode和source、timer、observer也是一对多的关系。可以理解为一个线程只能有一个runloop，一个runloop可以有多种mode来处理各种不同的事务，每个mode下可以有多个source和timer。

我们在子线程获取到runloop对象后，必须要让它run起来，这样才能使runloop的保活功能生效(当然这是通过验证而得)。下面我们来看下run：

run源码

runloop在run的时候，底层实际是一个do while循环，这个循环不是一直在运行，而是通过端口集mach port set来控制循环，如果不需要处理事情的时候，就进行休眠状态，休眠后需要通过wakeup来唤醒，休眠时线程被block住，此时需要在另外一个线程对它进行唤醒。

从上图可知，调用CFRunLoopWakeUp的时候，实际是通过mach port来发送MACH_SEND_MSG的权限

循环机制内部流程

从上图可知，唤醒runloop有四种方式：

1、Timer事件(底层实际也是通过端口port来实现的)

2、Source 1(也是基于端口来实现的)

3、手动wake up(上面提过)

4、处于超时状态(可以手动设置超时时间，当超时后，会先唤醒runloop，然后再进行退出)

以下是Runloop源码，可以结合上面的循环机制加以理解：

第20行__CFRunLoopRun函数是核心，进入前后会通知观察者，__CFRunLoopRun内部是一个do-while循环。

举例：第77行__CFRunLoopDoTimers实际就会调用__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__，然后执行timer。通过查看调用栈也可以得到。

那这个Timer是如何添加进runloop的呢？

通过上面对CommonMode的了解，RunLoop会自动将_commonModeItems里的 Source、Observer、Timer 同步到具有此标记的CommonMode里。

在执行- (void)addTimer:(NSTimer *)timer forMode:(NSRunLoopMode)mode函数后，实际就是将timer添加到相应的mode里去，这里是[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

添加到CommonModes中后，在runloop开始run的时候，就可以通过__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__通知timer去执行。然后通过判断retVal的值，看runloop是否需要结束，或是让runloop休眠。至此就完成了一轮”圈“。

补充：CommonMode并不是一种实际的模式，和defaultmode完全不是一回事。简单的理解就是，如果设置了 CommonMode模式，那么runloop在切换mode的同时，也把timer的事件也带走了，所以无论切到哪种mode下，timer的事件都是可以处理的。

回答tableView滚动timer不走问题：

1.默认滚动事件和timer事件都是在kCFRunloopDefaultMode下的

2.此时tableView一滚动，mode切换到UITrackingRunloopMode中，上面说，runloop同一时间只能处理一种mode的事件，那么在DefaultMode的timer就无法响应了。

3.CommonMode又是一个同步多种mode的技术方案，此模式下，当runloop到UITrackingRunloopMode的时候，他把timer的事件也转移到UITrackingRunloopMode下，那么timer就能走了。

Runloop的应用1：

点击事件通过硬件(屏幕)夸进程转发给SpringBoard(桌面管理)，再通过mach port夸进程转发给当前app，app再通过Source1和Source0回调，最后传给app的UIWindow。

Runloop的应用2：

检测主线程卡顿