什么是RunLoop
简单地说RunLoop的作用是，通过RunLoop对象接收事件，执行处理事件。苹果通过RunLoop实现自动释放池、延迟回触摸事件、屏幕刷新等功能。
由于一个线程一次只能执行一个任务，执行完成后线程就会退出。如果我们需要一个机制，让线程能随时处理事件但并不退出。Event Loop 的逻辑:关键的地方是如何管理事件/消息，如何让线程在没有处理消息时休眠以避免资源占用、在有消息到来时立刻被唤醒
RunLoop实际上就是一个对象，这个对象管理了其需要处理的事件和消息，并提供了一个入口函数来执行上面 Event Loop 的逻辑。线程执行了这个函数后，就会一直处于这个函数内部 "接受消息->等待->处理" 的循环中，直到这个循环结束（比如传入 quit 的消息），函数返回。
在iOS中提供两个对象获取RunLoop对象。NSRunLoop 和 CFRunLoopRef声明在不同的框架之上
RunLoop的优点
- 使程序一直运行并接受用户输入
- 决定程序在何时应该处理哪些Event
- 调用解耦（Message Queue）
- 节省CPU时间
RunLoop处理事件的类型
- Source（异步事件）：从一个线程到另一个线程，从一个Application到另一个Application
- timer（异步事件）：特定时间或者特定周期时间发生的事件
- 观察者：可以注册为
RunLoop对象的观察者，在RunLoop不同阶段得到通知，并回调执行相应地事件
RunLoop与线程的关系
RunLoop对象不能直接创建，只能通过两个自动获取的函数：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。他们的大致实现是：在全局中存放一个字典，key为线程名，value为线程对应的RunLoop对象。通过当前线程获取相应的RunLoop对象。线程刚创建时并没有RunLoop对象，如果你不主动获取，那它一直都不会有。RunLoop对象的创建是发生在第一次获取时，RunLoop对象的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop（主线程除外）
RunLoop Mode
CFRunLoopMode的结构为
struct __CFRunLoopMode {
CFStringRef _name; // Mode Name, 例如 @"kCFRunLoopDefaultMode"
CFMutableSetRef _sources0; // Set
CFMutableSetRef _sources1; // Set
CFMutableArrayRef _observers; // Array
CFMutableArrayRef _timers; // Array
...
};
CFRunLoop 的结构为
struct __CFRunLoop {
CFMutableSetRef _commonModes; // Set
CFMutableSetRef _commonModeItems; // Set
CFRunLoopModeRef _currentMode; // Current Runloop Mode
CFMutableSetRef _modes; // Set
...
};
一个 RunLoop包含若干个 Mode，每个 Mode 又包含若干个 Source/Timer/Observer(Mode 的item)。每次调用RunLoop的主函数时，只能指定其中一个 Mode，这个Mode被称作 CurrentMode。如果需要切换 Mode，只能退出 Loop，再重新指定一个 Mode 进入。这样做主要是为了分隔开不同组的 Source/Timer/Observer，让其互不影响。 RunLoop执行事件是以Mode为单位，Mode用于过滤事件。只有被关联到CurrentMode的来源才能被观察和发生时间。
CommonModes属性
CommonModes：一个 Mode可以通过将其 ModeName 添加到RunLoop的 "commonModes" 属性中。每当RunLoop的内容发生变化时，RunLoop 都会自动将 _commonModeItems 里的 Source/Observer/Timer 同步到具有 "Common" 标记的所有Mode里。
例如：主线程的 RunLoop 里有两个预置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。这两个 Mode 都已经被标记为"Common"属性(添加到了commonModes中了)。DefaultMode 是 App 平时所处的状态，TrackingRunLoopMode 是追踪 ScrollView 滑动时的状态。当你创建一个 Timer 并加到 DefaultMode 时，Timer 会得到重复回调，但此时滑动一个TableView时，RunLoop 会将 mode 切换为 TrackingRunLoopMode，这时 Timer 就不会被回调，并且也不会影响到滑动操作。----->如果你自定义一个mode，就在mode下的RunLoop上添加item，当当前mode内容变化，这个item就会被调用
commonModeItems
"commonModeItems" 被 RunLoop 自动更新到所有具有"Common"属性的 Mode 里去。---->效果和添加到所有在CommonModes条目下的Modes的效果一致
Mode接口
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);
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);
你只能通过 mode name 来操作内部的 mode，当你传入一个新的 mode name 但 RunLoop 内部没有对应 mode 时，RunLoop会自动帮你创建对应的 CFRunLoopModeRef。对于一个 RunLoop 来说，其内部的 mode 只能增加不能删除。
RunLoop的引用对象
CFRunLoopRef-
CFRunLoopModeRef：只是对CFRunLoopRef的封装 -
CFRunLoopSourceRef: 是事件产生的地方 - CFRunLoopTimerRef
- CFRunLoopObserverRef
上述的引用对象就是上述Mode所包含的Source/Timer/Observer
CFRunLoopSourceRef
Source有两个版本：Source0 和 Source1。主要的差别是主动和手动的唤醒RunLoop
Source0：只包含了一个回调（函数指针），它并不能主动触发事件。使用时，你需要先调用 CFRunLoopSourceSignal(source)，将这个 Source 标记为待处理，然后手动调用 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop，让其处理这个事件。--->加入到RunLoop得待处理队列中，手动唤醒RunLoop
Source1 :包含了一个 mach_port 和一个回调（函数指针），被用于通过内核和其他线程相互发送消息。这种 Source 能主动唤醒RunLoop的线程
CFRunLoopTimerRef
CFRunLoopTimerRef是基于时间的触发器，它和 NSTimer是桥接的，可以混用。其包含一个时间长度和一个回调（函数指针）。当其加入到 RunLoop 时，RunLoop会注册对应的时间点，当时间点到时，RunLoop会被唤醒以执行那个回调
CFRunLoopObserverRef
CFRunLoopObserverRef是观察者，每个 Observer 都包含了一个回调（函数指针），当 RunLoop 的状态发生变化时，观察者就能通过回调接受到这个变化。
```
struct CFRunLoopActivity : RawOptionSetType {
init(_ rawValue: CFOptionFlags)
init(rawValue rawValue: CFOptionFlags)
static var Entry: CFRunLoopActivity { get }
static var BeforeTimers: CFRunLoopActivity { get }
static var BeforeSources: CFRunLoopActivity { get }
static var BeforeWaiting: CFRunLoopActivity { get }
static var AfterWaiting: CFRunLoopActivity { get }
static var Exit: CFRunLoopActivity { get }
static var AllActivities: CFRunLoopActivity { get }
}
#### RunLoop的内部逻辑
[官方文档](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html#//apple_ref/doc/uid/10000057i-CH16-SW23)的描述
翻译为中文就是
执行的过程正如上述所描述的，它需要一个runloop对象，一个modeName，一个超时时间，一个是否在处理完成后停止runloop（默认是false）的bool作为参数
在正确获取到当前的mode，和确定当前mode下有items后执行上述过程
当你调用 CFRunLoopRun() 时，线程就会一直停留在这个循环里；直到超时或被手动停止，该函数才会返回。
##RunLoop 的底层实现
这部分是阅读了大神的博客后了解到的
`RunLoop` 的核心是基于 `mach port` 的，其进入休眠时调用的函数是 `mach_msg()`。
在硬件层上面的三个组成部分：Mach、BSD、IOKit (还包括一些上面没标注的内容)，共同组成了 XNU 内核。
XNU 内核的内环被称作 Mach，其作为一个微内核，仅提供了诸如处理器调度、IPC (进程间通信)等非常少量的基础服务。
BSD 层可以看作围绕 Mach 层的一个外环，其提供了诸如进程管理、文件系统和网络等功能。
IOKit 层是为设备驱动提供了一个面向对象(C++)的一个框架。
在 Mach 中，所有的东西都是通过自己的对象实现的，进程、线程和虚拟内存都被称为"对象"。和其他架构不同， **Mach 的对象间不能直接调用，只能通过消息传递的方式实现对象间的通信**。"消息"是 Mach 中最基础的概念，消息在两个端口 (port) 之间传递，这就是 Mach 的 IPC (进程间通信) 的核心。
上述RunLoop的内部逻辑的步骤7就是通过Mach对象之间传递的消息实现，唤醒的。这个Mach的函数为mach_msg() 函数，定义如下
mach_msg_return_t mach_msg(
mach_msg_header_t *msg,
mach_msg_option_t option,
mach_msg_size_t send_size,
mach_msg_size_t rcv_size,
mach_port_name_t rcv_name,
mach_msg_timeout_t timeout,
mach_port_name_t notify);
它会产生一个系统调用。调用这个函数就切换到了内核态。内核态中内核实现的 mach_msg() 函数会完成实际的工作，
##RunLoop能实现的功能
系统默认注册了5个Mode:
1. `kCFRunLoopDefaultMode`: App的默认 Mode，通常主线程是在这个 Mode 下运行的。
2. `UITrackingRunLoopMode`: 界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响。
3. `UIInitializationRunLoopMode`: 在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用。
4. `GSEventReceiveRunLoopMode`: 接受系统事件的内部 Mode，通常用不到。
5. `kCFRunLoopCommonModes`: 这是一个占位的 Mode，没有实际作用。
当 `RunLoop` 进行回调时，一般都是通过一个很长的函数调用出去 (call out)
##Cocoa中的Runloop
###AutoreleasePool
这里需要确定`AutoreleasePool`在主线程进入之前被创建，在所有事件被调用之后`AutoreleasePool`被释放。所以会注册两个观察者进行监听。并且这两个观察者的回调函数都是`_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()`。
响应过程如下：
1. 当一个硬件事件(触摸/锁屏/摇晃等)发生后，IOKit.framework 生成一个 IOHIDEvent 事件并由SpringBoard（主界面）接收。SpringBoard 只接收按键(锁屏/静音等)，触摸，加速，接近传感器等几种 Event
2. 随后用` mach port` 转发给需要的App进程。
3. 苹果注册的那个 Source1 就会触发回调，并调用 `_UIApplicationHandleEventQueue()` 进行应用内部的分发，`_UIApplicationHandleEventQueue()` 会把 IOHIDEvent 处理并包装成 UIEvent 进行处理或分发，其中包括识别 UIGesture/处理屏幕旋转/发送给 UIWindow 等。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的。
###手势识别
1. 在屏幕上采取了一个手势，上面的` _UIApplicationHandleEventQueue()` 识别了一个手势时。
2. 其首先会调用 `Cancel`将当前的 touchesBegin/Move/End 系列回调打断。随后系统将对应的 `UIGestureRecognizer` 标记为待处理。--->source0:只包含了一个回调（函数指针），你需要先调用 `CFRunLoopSourceSignal(source)`
3. `BeforeWaiting` (Loop即将进入休眠) 事件，这个Observer的回调函数是 `_UIGestureRecognizerUpdateObserver()`，其内部会获取所有刚被标记为待处理的` GestureRecognizer`，*并执行GestureRecognizer的回调*。
4. 当有 `UIGestureRecognizer` 的变化(创建/销毁/状态改变)时，这个回调都会进行相应处理。
###界面更新
当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 `setNeedsLayout/setNeedsDisplay`方法后，这个 UIView/CALayer 就被标记为待处理(source0)，并被提交到一个全局的容器去。 Observer 监听 `BeforeWaiting`(即将进入休眠) 和 `Exit` (即将退出Loop) 事件，回调去执行一个很长的函数：
`_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()`。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。
###定时器
`NSTimer` 其实就是` CFRunLoopTimerRef`，他们之间是 toll-free bridged 的。一个 `NSTimer` 注册到` RunLoop `后，`RunLoop` 会为其重复的时间点注册好事件。`RunLoop`为了节省资源，并不会在非常准确的时间点回调这个`Timer`。`Timer` 有个属性叫做 `Tolerance `(宽容度)，标示了当时间点到后，容许有多少最大误差。如果某个时间点被错过了，例如执行了一个很长的任务，则那个时间点的回调也会跳过去，不会延后执行。就比如等公交，如果 10:10 时我忙着玩手机错过了那个点的公交，那我只能等 10:20 这一趟了。
`CADisplayLink` 是一个和屏幕刷新率一致的定时器（但实际实现原理更复杂，和` NSTimer `并不一样，其内部实际是操作了一个 Source）。如果在两次屏幕刷新之间执行了一个长任务，那其中就会有一帧被跳过去（和 `NSTimer` 相似），造成界面卡顿的感觉。在快速滑动`TableView`时，即使一帧的卡顿也会让用户有所察觉。Facebook 开源的 `AsyncDisplayLink` 就是为了解决界面卡顿的问题，其内部也用到了` RunLoop`.
###PerformSelecter
当调用 NSObject 的 `performSelecter:afterDelay:` 后，实际上其内部会创建一个 Timer 并添加到当前线程的 `RunLoop` 中。**所以如果当前线程没有 `RunLoop`，则这个方法会失效**。
当调用 `performSelector:onThread:` 时，实际上其会创建一个 Timer` 加到对应的线程去，同样的，如果对应线程没有 `RunLoop` 该方法也会失效。
###关于GCD
实际上 `RunLoop` 底层也会用到 `GCD` 的东西，比如 `RunLoop` 是用 `dispatch_source_t `实现的 Timer。但同时 GCD 提供的某些接口也用到了` RunLoop`， *例如` dispatch_async()`*。--->GCD默认实现了Runloop，两者实际上是协作
*当调用 `dispatch_async(dispatch_get_main_queue(), block) `时，`libDispatch` 会向主线程的 `RunLoop` 发送消息，`RunLoop`会被唤醒*，并从消息中取得这个 block，并在回调 `__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()`(这个可以在GCD中设置断点看到) 里执行这个 block。但这个逻辑仅限于 dispatch 到主线程，dispatch到其他线程仍然是由 `libDispatch` 处理的。
###关于网络请求
iOS 中，关于网络请求的接口自下至上有如下几层:
1. `CFSocket` 是最底层的接口，只负责 socket 通信。
2. `CFNetwork` 是基于` CFSocket` 等接口的上层封装，`ASIHttpRequest` 工作于这一层
3. `NSURLConnection` 是基于 `CFNetwork` 的更高层的封装，提供面向对象的接口，`AFNetworking `工作于这一层
4. `NSURLSession` 是 iOS7 中新增的接口，表面上是和 `NSURLConnection` 并列的，但底层仍然用到了 `NSURLConnection` 的部分功能 (比如 com.apple.NSURLConnectionLoader 线程)，AFNetworking 和 Alamofire 工作于这一层。
####NSURLConnection 的工作过程
当调用了`NSURLConnection` start后，Delegate 就会不停收到事件回调。实际上，start 这个函数的内部会会获取` CurrentRunLoop`，然后在其中的 `DefaultMode` 添加了4个 Source0 (即需要手动触发的Source)。`CFMultiplexerSource` 是负责各种 Delegate 回调的，`CFHTTPCookieStorage` 是处理各种 Cookie 的。
开始传输的时候， `NSURLConnection` 创建了两个新线程：`com.apple.NSURLConnectionLoader` 和 `com.apple.CFSocket.private`。其中 `CFSocket` 线程是处理底层 socket 连接的。`NSURLConnectionLoader` 这个线程内部会使用 `RunLoop` 来接收底层 socket 的事件，并通过之前添加的 Source0 通知到上层的 Delegate
`NSURLConnectionLoader` 中的` RunLoop `通过一些基于 mach port 的 Source 接收来自底层 `CFSocket` 的通知。当收到通知后，其会在合适的时机向 `CFMultiplexerSource` 等 Source0 发送通知，同时唤醒 Delegate 线程的 RunLoop 来让其处理这些通知。`CFMultiplexerSource` 会在 Delegate 线程的 `RunLoop` 对 Delegate 执行实际的回调
过程如下图
