苹果开发文档阅读笔记之Runloop

本文参照苹果官方文档，力图以不同角度、不同方式来描述Runloop及其相关特性，以便更立体更全面地理解Runloop。

Runloop是一种消息处理模型，或者说消息处理循环。Runloop的作用就是让应用程序在线程空闲时进行休眠，而在接收到消息时再进行相应的处理。这样尽可能地减少不必要的CPU占用时间，优化资源配置。

Runloop和线程是一一对应的，具体说来就是一个线程对应有一个Runloop，它们在底层是使用字典Dictionary的键值对来保存的。iOS应用程序的主线程，以及NSTimer的相关API已经自动启用了其对应的Runloop，不需要人为创建。但如果希望保持人为创建的子线程的生命周期，则需要显式的创建获取其对应的Runloop并做一些相关配置。

Runloop就是进入线程后负责监听事件并让对应事件处理模块进行回调的循环体。Runloop从两种事件源监听并接收事件：一个是Input Sources，一个是Timer Sources。值得注意的是，Input Sources传递的是异步事件，这些事件一般是从其他应用程序的线程中传递过来的消息；而Timer Sources传递的都是同步事件，这些事件都会在特定的时间点或者以重复的时间间隔发生。

Runloop在处理输入事件的同时，还会生成一些描述自身当前状态的通知Notification。系统使用了一些观察者Observer来注册观察这些通知，因此观察者会在Runloop对应的状态改变时收到通知，然后在当前线程做相应的处理。

有一个很重要的概念就是Runloop Modes。Runloop同一时间只会工作在一种Mode下，然后切换到其他Mode中。一个Mode就是一个集合，里面包括一组Input Sources、一组Runloop将会监听的Timer Sources以及一组注册到当前Runloop的Observers。不同Mode可以有不同的input sources、timer sources及observers的集合，也可以存在交集。

当你创建并启动一个Runloop时，你需要指定一个Mode给这个Runloop，这样这个Runloop就只会监听此Mode集合中的Timer Sources、只接收处理此Mode中的Input Sources，并且只有此Mode中的Observers会收到这个Runloop状态变化的通知。属于其他Mode集合中的sources、timers和observers会被挂起，这些Mode中的source只会让新的事件挂起等待、timer会跳过本该定时回调的时机、observer也不会收到状态变化的通知。直到你将这个Runloop的Mode切换成对应的那个，那么相应的这些源才会正常接收事件，处理回调，接收通知等。

具体说一下Input Sources，苹果官方文档将Input Sources分成了基于端口的源Port-Based Sources、自定义源Custom Sources以及Cocoa选择器源Cocoa Perform Selector Sources。再次强调的是，这三种输入源都是异步地将事件传递给你的线程。

PORT-BASED SOURCES

Port-Based Sources是Cocoa和Core Foundation层自动创建的，使用的是端口相关的对象和方法；这些源会监控应用程序的Mach端口，因此会自动收到来自Kernel发出的信号通知。一般在Cocoa层，你不需要直接创建一个input source，而是简单地通过NSPort的方法来创建一个port对象然后加入到指定的runloop里，这个port对象会自动配置创建所需要的输入源；如果在Core Foundation层，你就需要手动创建runloop的源以及对应的port对象。

COCOA PERFORM SELECTOR SOURCES

按照苹果文档上描述，Cocoa Perform Selector Sources也属于自定义源，这是Cocoa定义的一种通过使用Selector来进行线程间通信的一种输入源。这种源跟基于端口的源的一个区别是，当一个perform selector source调用了其选择器后，它会自动从当前runloop中把自己移除掉，而input sources会一直保持自己；但这种源跟基于端口的输入源也有一个共同点，就是这种源的请求是在线程中串行执行的，这样做的好处是当很多方法在同一个线程被调用时，可以避免一些同步的问题。在新版本的OSX/iOS里你可以使用Perform Selector Sources将选择器传递给任意线程（旧版只能适用于主线程），但前提是传递的目标线程必须有一个激活了的runloop正在运行，这样才能成功监听接收这个源的事件。Runloop会在每一次循环时处理全部当前正在在排队的Selector事件，并不是一次循环处理一个事件。因此这种Perform Selector Sources是不能主动唤醒runloop的，只能等待runloop被其他源唤醒后再对排队的(queued)事件进行处理。

TIMER SOURCES

Timer Sources定时器源会同步地把定时事件传递给指定线程。定时器其实就是一种定时通知线程自身何时需要处理事件的一种机制，只不过定时器是基于时间的，而Observers是基于runloop的状态改变。值得注意的是，定时器的回调不一定是精确地每次都执行，因为假如runloop的mode被切换成当前定时器没有注册的时，这个定时器就会被挂起，直到当前runloop的mode被换回来；还有另一种情况，就是当前runloop的一次循环中，系统在处理定时器回调之前一直在处理其他输入源的回调，这样导致定时器设定的时间点可能被错过，那么这个定时器在本次循环中也不会调用回调了，而是忽略掉这一次循环的回调机会，等待下一次；当然最后一种情况是，如果当前runloop根本没有启用，那定时器更是永远都不会产生回调。

最后一种情况是，定时器在设定好的时间点因为特定原因一次或连续数次没有来得及发出回调，而是产生了足够大的延迟，那么定时器并不会错过几次就补偿几次回调，而是在数次延迟后仅调用一次回调，然后就会等待下一次的预定时间点执行。

OBSERVERS

输入源是通过同步或异步的方式将事件传递给指定线程，而runloop观察者会在runloop循环过程中特定位置、到达特定状态时进行调用。一般系统会在runloop即将休眠之前将本次循环中收到的所有渲染绘制、UI刷新、自动释放池出栈入栈事件统一处理。Runloop观察者除了能够观察到一个“即将休眠”的状态之外，还有很多对应状态可供观察，以下：

即将处理定时器
即将处理一个输入源
即将进入休眠
刚被唤醒（尚未处理任何事件）
退出运行循环```

你只能使用Core Foundation手动给当前线程添加观察者，同时你也需要指定这个观察者是一次性的还是需要重复使用的。因为观察者也类似于定时器，如果设定为一次性的，那只要它被调用一次之后就会将自身移除。