什么是Runloop
Runloop即运行循环。为什么你的APP放在那里不去动它，在某个时间点去操作它，它还会给你反馈。就是因为Runloop的存在。
总结一下，因为Runloop的存在，保证你的程序不会死。
主要负责什么？
- 使程序一直运行并接受用户输入
- 决定程序在何时处理一些Event
- 调用解耦(Message Queue)
- 节省CPU时间（没事的时候闲着，有事的时候处理）
谁依赖NSRunloop
- NSTimer
- UIEvent
- autorelease
- NSObject(NSDelaydPerforming)
- NSObject(NSThreadPerformAddtion)
- CADisplayLink
- CATransition
- CAAnimation
- dispatch_get_main_queue()
- AFNetworking(NSURLConnection)
- ...
主线程几乎所有的函数都从以下的6个之1的调起
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__
构成元素
因为NSRunloop是对CFRunloop的封装，所以这里只看CFRunLoop就可以了。
CFRunLoopTimer的封装
系统提供的NSTimer、CADisplayLink、performSelector等都是对CFRunLoopTimer的封装。
CFRunLoopSource
Source是RunLoop的数据源抽象类(用OC的话来讲就是protocol)。
RunLoop定义了两个版本的Source,分别是Source0和Source1。
- Source0：处理APP内部事件、APP自己负责管理(触发)，如UIEvent、CFSocket
- Source1：由RunLoop和内核管理，Mach Port驱动，如CFMachPort、CFMessagePort
CFRunLoopObserver
观察者，向外部报告RunLoop当前状态的更改
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), // 即将退出Loop
};
框架中很多机制都由CFRunLoopObserver触发，比如CAAnimation
举例:
self.navigationController pushViewController:<#(nonnull UIViewController *)#> animated:<#(BOOL)#>
当程序执行完这行代码时，我们可以看到经历push动画之后，到达了一个新的界面。
但其实并不是执行完这行代码就出现了Push的动画。
其实，执行这段代码时不会立刻就掉push动画，而是要RunLoop循环一圈收集所有的Animation操作，汇集起来一起去调。
CFRunLoopObserver与AutoreleasePool
对象的释放并不是在{}括号结束。而是稍微延迟了一点。
堆栈如下：
_wrapRunLoopAutoreleasePoolHandler
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
UIKit通过RunLoopOberser在RunLoop两次Sleep间对AutoreleasePool进行Pop和Push，将这次Loop产生的Autorelease对象释放。
也就是RunLoop跑一圈没事了就睡，被唤醒了再跑下一圈，在两次sleep之间对自动释放池进行释放。
CFRunLoopMode
注意
RunLoop在同一段时间只能且必须在一种特定Mode下Run。
更换Mode时，需要停止当前Loop，然后重启新Mode。
Mode是iOS滑动顺畅的关键。
类型
- NSDefaultRunLoopMode
默认状态(空闲状态)，比如点击按钮都是这个状态 - UITrackingRunLoopMode
滑动时的Mode。比如滑动UIScrollView时。 - UIInitializationRunLoopMode
私有的，APP启动时。就是从iphone桌面点击APP的图标进入APP到第一个界面展示之前，在第一个界面显示出来后，UIInitializationRunLoopMode就被切换成了NSDefaultRunLoopMode。 - NSRunLoopCommonModes
它是NSDefaultRunLoopMode和UITrackingRunLoopMode的集合。结构类似于一个数组。在这个mode下执行其实就是两个mode都能执行而已。
典型的应用场景这样：当前界面有开启一个NSTimer，并且滑动UIScrollView。正常开启NSTimer后，滑动UIScrollView时它是不滑动的。解决办法就是把这个timer加入到当前的RunLoop，并把RunLoop的mode设置为NSRunLoopCommonModes。这样就可以保证不管你是NSDefaultRunLoopMode里跑，还是UITrackingRunLoopMode里跑，这个timer都可以执行。
self.timer = [NSTimer scheduledTimerWithTimeInterval:0.0625
target:self
selector:@selector(progressChange)
userInfo:nil
repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];
当你开始滑动UIScrollView时，RunLoop的mode状态变化如下：
NSDefaultRunLoopMode -> UITrackingRunLoopMode -> NSDefaultRunLoopMode
开始滑动时，第一次mode的切换会把NSDefaultRunLoopMode停掉。然后开启新的UITrackingRunLoopMode。当滑动停止时，由UITrackingRunLoopMode切换回NSDefaultRunLoopMode，这时UITrackingRunLoopMode被停止，又切换回了老的NSDefaultRunLoopMode（这个老的NSDefaultRunLoopMode应该是重新开始的）。
RunLoop和GCD的关系
RunLoop和GCD的关系，准确来说是只要使用了dispatch_get_main_queue()，就与RunLoop有了关系。
因为GCD中dispatch到main queue的block被分发到main RunLoop执行。
RunLoop的挂起和唤醒
我写了个demo，运行，然后点击debug栏的暂停，查看堆栈，如下：
- 指定用于唤醒的mach_port接口
- 调用mach_msg监听唤醒端口，被唤醒前，系统内核将这个线程挂起，停留在mach_msg_trap状态
- 由另一个线程（或另一个进程中的某个线程）向内核发送这个端口的msg后，trap状态被唤醒，RunLoop继续开始干活。
RunLoop迭代执行顺序
伪代码：
SetupThisRunLoopRunTimeoutTimer(); //by GCD timer
do{
__CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
__CFRunLoopDoObservers(kCFRunLoopBeforeSources);
__CFRunLoopDoBlocks();
__CFRunLoopDoSource0();
CheckIfExistMessagesInMainDispatchQueue(); //GCD
__CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);
var wakeUpPort = SleepAndWaitForWakingUpPorts();
//mach_msg_trap
//Zzz...
//Received mach_msg , wake up
__CFRunLoopDoObservers(kCFRunLoopAfterWaiting);
//Handle msgs
if(wakeUpPort == timerPort){
__CFRunLoopDoTimers();
}else if(wakeUpPort == mainDispatchQueuePort) {
//GCD
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE_()
}else {
__CFRunLoopDoSource1();
}
__CFRunLoopDOBlocks();
}while(!stop && !timeout);
代码解读
//首先do..while循环不能是一个死循环,所以在这里设置一个过期时间
//这件事是GCD干的，用来检测do..while循环跑了多久
SetupThisRunLoopRunTimeoutTimer();
//开始跑循环
do{
//告诉observer我要跑timer了
__CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
//告诉observer我要跑source了
__CFRunLoopDoObservers(kCFRunLoopBeforeSources);
__CFRunLoopDoBlocks();
//程序跑到这里会查询Source0有什么消息
__CFRunLoopDoSource0();
//询问GCD你有没有存在主线程的东西需要我帮你调
CheckIfExistMessagesInMainDispatchQueue(); //GCD
//告诉observer我要睡了，RunLoop进入到挂起状态
__CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);
//进入trap状态，程序跑到这里就卡在这不动了，等待被某个Port唤醒
var wakeUpPort = SleepAndWaitForWakingUpPorts();
//被唤醒后，告诉observer我被唤醒了
__CFRunLoopDoObservers(kCFRunLoopAfterWaiting);
//假如是被timer唤醒的
if(wakeUpPort == timerPort){
//就去循环遍历和timer有关的回调
__CFRunLoopDoTimers();
}else if(wakeUpPort == mainDispatchQueuePort) {
//如果是主线程的GCD把我唤醒的，那RunLoop就知道GCD要让它做事了，然后就取调GCD的这些事件
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE_()
}else {
//如果都不是，就是Source1，Source1是基于Port事件的，比如网络某个端口来数据了，就会把RunLoop唤醒，去对来的数据进行处理
__CFRunLoopDoSource1();
}
__CFRunLoopDoBlocks();
}while(!stop && !timeout);
//判断条件：有没有被外部干掉 && 到了过期时间
//如果过期时间不手动进行设置的话，默认值是一个很大的值，可能是Int_Max
AFNetworking是如何玩转RunLoop的
+ (void)networkRequestThreadEntryPoint:(id)_unuserd object {
@autoreleasepool {
[[NSThread currentThread] setName:@"AFNetworking"];
//为了不让runloop run起来没事干导致消失
//所以给runloop加了一个NSMachPort，给它一个mode去监听
//实际上port什么也没干，就是让runloop一直在等，目的就是让runloop一直活着
//这是一个创建常驻服务线程的好方法
NSRunloop *runloop = [NSRunLoop currentRunLoop];
[runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runloop run];
}
}
+ (NSThread *)networkRequestThread {
static NSThread *_networkReuqestThread = nil;
static dispatch_once_t oncePredicate;
dispatch_once(&oncePredicate, ^{
_networkRequestThread =
[[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
[_networkRequestThread start];
});
return _networkRequestThread;
}
一个TableView延迟加载图片的新思路
以前是怎么解决的？
通过UITableView的代理方法，判断如果处于滑动状态就不去设置cell上的图片，如果没有处于滑动状态就取设置cell上的图片。
而现在通过Runloop就有一个十分简便的方法。
//在cell里面把设置图片的事情在NSDefaultRunloopMode里面去做。
//当主线程的tableview不再滑动的时候就会去设置图片
UIImage *dowloadImage = ...;
[self.iconImageView performSelector:@selector(setImage:) withObject:dowloadImage afterDelay:0 inModes:@[NSDefaultRunloopMode]];
这样去设置图片就简便了很多，不用再去判断tableview的代理方法。代码也会很清爽。