RunLoop
基本作用：
保持程序的持续运行
处理App中的各种事件（比如触摸、定时器、selector事件）
节省CPU资源，提高程序性能：有事件处理事件、无事件，等待事件
RunLoop对象
iOS中有2套API来访问和使用RunLoop
Foundation
NSRunLoop
[NSRunLoop currentRunLoop] // 获得当前线程的RunLoop对象
[NSRunLoop mainRunLoop] // 获得主线程的RunLoop对象
NSRunLoop是基于CFRunLoopRef的一层OC封装，所以要了解RunLoop内部结构，需要多研究CFRunLoopRef层面的API(CoreFoundation层面)
- Core Foundation
- CFRunLoopRef
CFRunLoopGetCurrent(); // 获得当前线程的RunLoop对象
CFRunLoopGetMain() // 获得主线程的RunLoop对象
NSRunLoop和CFRunLoopRef都代表着RunLoop对象
RunLoop与线程
每条线程都有唯一的一个与之对应的RunLoop对象主线程的RunLoop已经自动创建好了，子线程的RunLoop需要主动创建RunLoop在第一次获取时创建，在线程结束时销毁- 如果子线程的RunLoop没有设置Source or Timer事件，那么子线程的NSRunLoop会立刻关闭
子线程中的RunLoop
在子线程中创建RunLoop：
[NSRunLoop currentRunLoop]
- (void)testThread
{
NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(createRunLoop) object:nil];
[thread start];
}
- (void)createRunLoop
{
// 错误的创建方式
// NSRunLoop *runLoop = [[NSRunLoop alloc] init];
// 正确的RunLoop创建方式 , 每一个线程默认都会有一个RunLoop, 用到才创建
// 只要调用currentRunLoop方法，如果当前线程没有RunLoop。系统就会自动创建一个RunLoop,添加到当前线程中
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
NSLog(@"%@", runLoop);
}
RunLoop相关类
Coure Foundation中关于RunLoop的5个类
-
CFRunLoopRef代表一个RunLoop对象 -
CFRunLoopModeRefRunLoop的运行模式 -
CFRunLoopSourceRef处理点击、selector等事件 -
CFRunLoopTimerRef处理timer的事件 -
CFRunLoopObserverRef监听是否有事件需要处理
- 如果有就唤醒runLoop，根据事件的类型，交给 sourceRef或者 timerRef来处理
- 如果没有就让RunLoop进入休眠状态
RunLoop内部结构图
1. CFRunLoopModeRef
概念：
CFRunLoopModeRef代表RunLoop的运行模式一个RunLoop包含若干个Mode，每个Mode又包含若干个Sourse/Timer/Observer每次启动RunLoop时，只能指定一个Mode，这个Mode被称作CurrentModel-
若要切换Mode，只能退出Loop，再重新指定一个Mode进入(主要是为了分隔开不同组的Sourse/Timer/Observer，让其互不影响)
5种Mode
NSDefaultRunLoopMode : App的默认Mode,通常主线程是在这个Mode运行UITrackingRunLoopMode : 界面追踪Mode，用于ScrollView追踪触摸滑动，保证界面滑动时不受其他Mode影响- UIInitializationRunLoopMode：在刚启动App时进入的第一个Mode,启动完成后就不再使用
- GSEventRccciveRunLoopMode : 接受系统事件的内部Mode，通常用不到
NSRunLoopCommonModes: 这是一个占位用的Mode,不是一种真正的Mode
RunLoop同一时刻只能运行一种模式
2. CFRunLoopTimerRef- CFRunLoopTimerRef 是基于事件的触发器
CFRunLoopTImerRef 基本上说就是
NSTimer。他受RunLoop的Mode影响GCD的Timer 不受RunLoop影响
3. CFRunLoopSourceRef- CFRunLoopSourceRef是事件源 （输入源）
source 分类：
官方文档的分类
- Port-based Sources
- Custom Input Sources
- Cocoa Perform Selector Sources
按照函数调用栈(【函数调用顺序】)的分类
- Source0 : `非`基于Port的，用户主动触发事件
- Source1 : 基于Port的，通过内核和其他线程相互发送消息
4. CFRunLoopObserverRef
- CFRunLoopObserverRef是观察者，能够监听RunLoop的状态改变
- 可以监听的时间点有以下几个:
/* Run Loop Observer Activities */
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), //即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1), //即将处理Timmer
kCFRunLoopBeforeSources = (1UL << 2), //即将处理Source
kCFRunLoopBeforeWaiting = (1UL << 5), //即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), //刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), //即将退出Loop
kCFRunLoopAllActivities = 0x0FFFFFFFU //所有的状态
};
- 给主线程的
RunLoop添加一个Observer，监听主线程Runloop的处理
/**
参数说明：
第一个参数： 给Observer分配存储空间
第二个参数： 要监听哪种状态
第三个参数： 是否要重复监听。 （NO,只监听一次）
第四个参数： 优先级
第五个参数： 监听到事件的回调
*/
CFRunLoopObserverRef ref = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
switch (activity) {
case kCFRunLoopEntry: {
NSLog(@"即将进入Loop");
break;
}
case kCFRunLoopBeforeTimers: {
NSLog(@"即将处理Timmer");
break;
}
case kCFRunLoopBeforeSources: {
NSLog(@"即将处理Source");
break;
}
case kCFRunLoopBeforeWaiting: {
NSLog(@"即将进入休眠");
break;
}
case kCFRunLoopAfterWaiting: {
NSLog(@"刚从休眠中唤醒");
break;
}
case kCFRunLoopExit: {
NSLog(@"即将退出Loop");
break;
}
case kCFRunLoopAllActivities: {
NSLog(@"所有的状态");
break;
}
}
});
/**
第一个参数： 需要给哪个Runloop添加观察者
第二个参数： 添加哪个Observer对象
第三个参数： 在哪种模式下添加监听
*/
CFRunLoopAddObserver(CFRunLoopGetMain(), ref, kCFRunLoopDefaultMode);
5.CFRunLoopRef
- 如果一个RunLoop中没有Input Source事件和Timer source事件，RunLoop就会关掉。
RunLoop 相关问题
1. 自动释放池什么时候释放
通过RunLoop的 Observer 监听RunLoop 的状态
第一次创建，是在RunLoop进入的时候创建
最后一次释放，实在RunLoop退出的时候
其他创建和释放
每次休眠的时候， 都会释放前自动释放池，然后再创建一个新的自动释放池
即将退出的时候，释放自动释放池
这里需要确定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 了。
RunLoop使用场景
cocoa中的RunLoop
1 AFN
在AFN中当使用 NSURLConnection 去执行网络操作的时候，会遇到还没有收到服务器的回调，线程就已经退出了。为了解决这一问题，作者使用到了RunLoop。下面是AFN中的一段代码：
下面这段代码在AFURLConnectionOperation.m中的 162 行。
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
@autoreleasepool {
[[NSThread currentThread] setName:@"AFNetworking"];
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runLoop run];
}
}
+ (NSThread *)networkRequestThread {
static NSThread *_networkRequestThread = nil;
static dispatch_once_t oncePredicate;
dispatch_once(&oncePredicate, ^{
_networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
[_networkRequestThread start];
});
return _networkRequestThread;
}
2. 让Crash的App回光返照
App崩溃的发生分两种情况：
program received signal:SIGABRT
SIGABRT一般是过度release 或者 发送 unrecogized selector导致。EXC_BAD_ACCESS 是访问已被释放的内存导致,野指针错误。
由 SIGABRT 引起的Crash 是系统发这个signal给App，程序收到这个signal后，就会把主线程的RunLoop杀死，程序就Crash了 该例只针对 SIGABRT引起的Crash有效。
- Signal: 是Unix、类Unix等操作系统中进程间通讯的一种方式，用来通知一个事件发生。当一个singal发送给进程，操作系统就会中断进程的正常控制流程，如果在进程中定义了信号的处理函数，那么这个函数就会被执行，因此我们可以注册signal，并指定收到signal后要执行的函数
为了让App回光返照，我们需要来捕获 libsystem_sim_c.dylib 调用 abort() 函数发出的程序终止信号，然后让其执行我们定义的处理signal的方法。在方法中，我们需要开启一个RunLoop,保持主线程不退出
// 创建RunLoop
CFRunLoopRef runLoop = CFRunLoopGetCurrent();
// 设置Mode
NSArray *allModes = CFBridgingRelease(CFRunLoopCopyAllModes(runLoop));
// 弹窗告知 程序挂了
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"程序崩溃了" message:@"崩溃信息" delegate:nil cancelButtonTitle:@"取消" otherButtonTitles:nil];
[alertView show];
while (1) {
for (NSString *mode in allModes) {
// 快速的切换 Mode 就能处理滚动、点击等事件
CFRunLoopRunInMode((CFStringRef)mode, 0.001, false);
}
}
衍生拓展
RunLoop底层实现
RunLoop 的核心是基于 mach port 的，其进入休眠时调用的函数是 mach_msg()。Run
在硬件层上面的三个组成部分：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() 函数会完成实际的工作
当 RunLoopco 进行回调时，一般都是通过一个很长的函数调用出去 (call out)
事件响应
苹果注册了一个Source1(基于mach port)用来接收系统事件，其回调函数为__IOHIDEventSystemClientQueueCallback()。
响应过程如下：
- 当一个硬件事件(触摸/锁屏/摇晃等)发生后，IOKit.framework 生成一个 IOHIDEvent 事件并由SpringBoard（主界面）接收。SpringBoard 只接收按键(锁屏/静音等)，触摸，加速，接近传感器等几种 Event
- 随后用
mach port转发给需要的App进程。 - 苹果注册的那个 Source1 就会触发回调，并调用
_UIApplicationHandleEventQueue()进行应用内部的分发，_UIApplicationHandleEventQueue()会把 IOHIDEvent 处理并包装成 UIEvent 进行处理或分发，其中包括识别 UIGesture/处理屏幕旋转/发送给 UIWindow 等。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的。
手势识别
在屏幕上采取了一个手势，上面的
_UIApplicationHandleEventQueue()识别了一个手势时。其首先会调用 Cancel将当前的 touchesBegin/Move/End 系列回调打断。随后系统将对应的
UIGestureRecognizer 标记为待处理。--->source0:只包含了一个回调（函数指针），你需要先调用CFRunLoopSourceSignal(source)BeforeWaiting(Loop即将进入休眠) 事件，这个Observer的回调函数是_UIGestureRecognizerUpdateObserver()，其内部会获取所有刚被标记为待处理的GestureRecognizer，并执行GestureRecognizer的回调。当有
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 中，关于网络请求的接口自下至上有如下几层:
- CFSocket 是最底层的接口，只负责 socket 通信。
- CFNetwork 是基于CFSocket 等接口的上层封装，ASIHttpRequest 工作于这一层
- NSURLConnection 是基于 CFNetwork 的更高层的封装，提供面向对象的接口，AFNetworking工作于这一层
- 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 执行实际的回调
过程如下图
