NSRunLoop原理详解——不再有盲点

编程最怕的就是有盲点，不确定，而runloop官网对其提及的又很少；那么看完这篇应该使你有底气很多~

RunLoop整体介绍

An event-processing loop, during which events are received and dispatched to appropriate handlers.

事件运行循环：就类似下面的while循环部分，当然要复杂很多，可以把它抽象成如下代码：

main() {
    initialize();
    do {
        message = get_next_message();
        process_message(message);
    } while (message != quit);
}

“消息”循环，等待消息（会休眠）->接收消息->处理消息。通过上面的代码，runloop本质就是提供了一种消息处理模式，只不过它封装抽象的太好了（一般开发的时候根本就感觉不到，或者说不用关心）。

runloop相当于帮我们打包了各种消息，并将消息发送给指定的接受者。

可以将runloop理解为一个函数，功能是一个消息循环，有消息则处理，没有消息则休眠。（注意：runloop实质是一个对象，但是不影响以上的假设）

简单使用：新建一个线程，添加一个定时器，然后运行即可

- (void)timerFire {
    NSLog(@"mode:%@",[[NSRunLoop currentRunLoop] currentMode]);
}

- (void)runLoopTest {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        NSTimer *tickTimer = [[NSTimer alloc] initWithFireDate:[NSDate date] interval:2 target:self selector:@selector(modeTestTimer) userInfo:nil repeats:YES];
        [[NSRunLoop currentRunLoop] addTimer:timerFire forMode:NSDefaultRunLoopMode];
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode  beforeDate:[NSDate distantFuture]];
    });
}

如果你接触过嵌入式操作系统(纯内核)开发，那么对下面代码肯定很熟悉

void ledTask (void *p_arg)
{
    initialize();
    while (1) {
        LED_ON();
        delay_ms(500);
        LED_OFF();
        delay_ms(500);
    };
}

LED闪烁线程，让一个LED灯1HZ的频率闪烁，功能很简单：首先初始化，然后进入while(1)死循环，延迟函数会使线程进入休眠（节省CPU）。直到程序死掉线程结束。是否和runloop很相似？

RunLoop消息类型（事件源）

一句话概括：很复杂，各种各样 ：）

不过，根据上图我们可以将消息分为二种类型，第一种类型又可以细分为三种，此三种共同点就是它们都是异步执行的

• Port：

监听程序的Mach ports，Mach ports是一个比较底层的东西，可以简单的理解为：内核通过port这种方式将信息发送，而mach则监听内核发来的port信息，然后将其整理，打包发给runloop。

• Customer：

很明显，由开发人员自己发送。不仅仅是发送，过程的话相当复杂，苹果也提供了一个CFRunLoopSource来帮助处理。由于很少用到，可以简单说下核心，但是对帮助我们理解runloop却很有帮助：

1. 定义输入源（数据结构）
2. 将输入源添加到runloop，那么这样就有了接受者，即为R1
3. 协调输入源的客户端（单独线程），专门监听消息，然后将消息打包成runloop能够处理的样式，即第一步定义的输入源。它类似Mach的功能
4. 谁来发送消息的问题？上面的machport是由内核发送的。自定义的当然要我们自己发送了。。。首先必须是另一个线程来发送（当然如果只是测试的话可以和第三步在同一个线程），先发送消息给输入源，然后唤醒R1，因为R1一般处于休眠状态，然后R1根据输入源来做相应的处理

• Selector Sources：

NSObject类提供了很多方法供我们使用，这些方法是添加到runloop的，所以如果没有开启runloop的话，不会运行（不过有个坑，请看下面介绍）。

/// 主线程
performSelectorOnMainThread:withObject:waitUntilDone:
performSelectorOnMainThread:withObject:waitUntilDone:modes:
/// 指定线程
performSelector:onThread:withObject:waitUntilDone:
performSelector:onThread:withObject:waitUntilDone:modes:
/// 针对当前线程
performSelector:withObject:afterDelay:
performSelector:withObject:afterDelay:inModes:
/// 取消，在当前线程，和上面两个方法对应
cancelPreviousPerformRequestsWithTarget:
cancelPreviousPerformRequestsWithTarget:selector:object:

下面提供的方法是在指定的线程运行aSelector ，一般情况下aSelector会添加到指定线程的runloop。但，如果调用线程和指定线程为同一线程，且wait 参数设为YES，那么aSelector会直接在指定线程运行，不再添加到runloop。

performSelectorOnMainThread:withObject:waitUntilDone:
performSelectorOnMainThread:withObject:waitUntilDone:modes:

performSelector:onThread:withObject:waitUntilDone:
performSelector:onThread:withObject:waitUntilDone:modes:

其实这也很好理解，假设这种情况也添加到指定线程的runloop，我们可以这样反向理解：1,当前线程runloop还没有开启，那么aSelector就不会被执行，然而你却一直在等待，造成线程卡死。2，当前线程runloop已经开启，那么调用performSelector这个方法的位置肯定是处于runloop的callout方法里面，在这里等待runloop再callout从而调用aSelector方法完成，显然也是死等待，线程卡死。。。

还有一些performSelector方法，是不会添加到runloop的，而是直接执行，可以按照上面的特殊情况进行理解。方法列举如下：

- (id)performSelector:(SEL)aSelector;
- (id)performSelector:(SEL)aSelector withObject:(id)object;
- (id)performSelector:(SEL)aSelector withObject:(id)object1 withObject:(id)object2;

看到这里，是否感觉有些乱？？？只要记住没有延迟或者等待的都不会添加到runloop，有延迟或者等待的还有排除上面提到的特殊情况。

• Timer Sources：它的事件发送是同步的，这个用的比较多，会在下一篇专门介绍

• Observers，观察者：首先它并不属于事件源(不会影响runloop的生命周期)，它比较特殊，用于观察runloop自身的一些状态的，有以下几种：

  1. 进入runloop
  2. runloop即将执行定时器
  3. runloop即将执行输入源（Port，Customer，Selector Sources）
  4. runloop即将休眠
  5. runloop被唤醒，在处理完唤醒它的事件之前
  6. 退出

下面举例,监听所有状态，在非主线程（可以看到一个完整的周期）：

+ (void)observerTest {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        /**
         param1: 给observer分配存储空间
         param2: 需要监听的状态类型:kCFRunLoopAllActivities监听所有状态
         param3: 是否每次都需要监听，如果NO则一次之后就被销毁，不再监听，类似定时器的是否重复
         param4: 监听的优先级，一般传0
         param5: 监听到的状态改变之后的回调
         return: 观察对象
         */
        CFRunLoopObserverRef  observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
            switch (activity) {
                case kCFRunLoopEntry:
                    NSLog(@"即将进入runloop");
                    break;
                case kCFRunLoopBeforeTimers:
                    NSLog(@"即将处理timer");
                    break;
                case kCFRunLoopBeforeSources:
                    NSLog(@"即将处理input Sources");
                    break;
                case kCFRunLoopBeforeWaiting:
                    NSLog(@"即将睡眠");
                    break;
                case kCFRunLoopAfterWaiting:
                    NSLog(@"从睡眠中唤醒，处理完唤醒源之前");
                    break;
                case kCFRunLoopExit:
                    NSLog(@"退出");
                    break;
                default:
                    break;
            }
        });
        // 没有任何事件源则不会进入runloop
        [NSTimer scheduledTimerWithTimeInterval:3 target:self selector:@selector(doFireTimer) userInfo:nil repeats:NO];
        CFRunLoopAddObserver([[NSRunLoop currentRunLoop] getCFRunLoop], observer, kCFRunLoopDefaultMode);
        [[NSRunLoop currentRunLoop] run];
    });
}

+ (void)doFireTimer {
    NSLog(@"---fire---");
}

打印结果：一个完整的周期

RunLoop模式

runloop的模式，使得runloop显得更加灵活，适应更多的应用场景。

上面提到的事件源，都是处于特定的模式下的，如果和当前runloop的模式不一致则不会得到响应，举个例子：

如果定时器处于mode1，而runloop运行在mode2，则定时器不会触发，只有runloop运行在mode1时，定时器才会触发。

系统为我们提供了多种模式,下面列一些比较常遇到的：

• kCFRunLoopDefaultMode: App的默认 Mode，通常主线程是在这个 Mode 下运行的。
• UITrackingRunLoopMode: 界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响。
• UIInitializationRunLoopMode: 在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用。
• NSRunLoopCommonModes: 包含了多种模式：default, modal, 和tracking modes。

除了系统给我们的模式，我们自己也可以自定义。

NSRunLoopMode 的类型为字符串类型，定义：typedef NSString * NSRunLoopMode，自定义类型就很简单了，示例代码如下：直接调用runLoopModeTest方法即可测试

- (void)modeTestTimer {
    NSLog(@"mode:%@",[[NSRunLoop currentRunLoop] currentMode]);
}
/// 这里使用非主线程，主要考虑如果一直处于customMode模式，则主线瘫痪
- (void)runLoopModeTest {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        NSTimer *tickTimer = [[NSTimer alloc] initWithFireDate:[NSDate date] interval:2 target:self selector:@selector(modeTestTimer) userInfo:nil repeats:YES];
        [[NSRunLoop currentRunLoop] addTimer:tickTimer forMode:@"customMode"];
        [[NSRunLoop currentRunLoop] runMode:@"customMode"  beforeDate:[NSDate distantFuture]];
    });
}

runloop模式的切换

• 对于非主线程，我们可以退出当前模式，然后再进入另一个模式，也可以直接进入另一个模式，即嵌套
• 对于主线程，我们当然也可以像上面一样操作，但是主线程有其特殊性，有很多系统的事件。系统会做一些切换，我们更关心的是系统是如何切换的？系统切换模式时，并没有使用嵌套

主线程没有使用runloop嵌套是根据我的测试得出，没办法，官方文档太太太少，也没有更底层源码，只有CFRunLoop的源码:http://opensource.apple.com/tarballs/CF/CF-855.17.tar.gz。

根据以上

最后总结下，thread--runloop--mode--event sources，关系可以表示如下：

RunLoop生命周期

可以分为三步：创建->运行(开启，内部循环)->退出

1. runloop创建

苹果是不允许开发人员手动创建runloop，runloop是伴随着线程的创建而创建，线程与runloop是一一对应的，具有唯一性，另外创建还区分是否为主线程

• 主线程：系统会自动创建

• 非主线程：系统不会自动创建，开发人员必须显示的调用[NSRunLoop currentRunLoop]方法来获取runloop的时候，系统才会创建，类似懒加载

系统只提供了两种方法获取runloop，currentRunLoop和mainRunLoop，可以看出非主线程只有在自己的线程内才能获得runloop。

2. runloop运行

• 开启：主线程系统会自动运行，那么非主线程也是需要开发人员显式调用的，可以通过如下方法

NSRunLoop提供的方法：
- (void)run; // 默认模式
- (void)runUntilDate:(NSDate *)limitDate;
- (BOOL)runMode:(NSRunLoopMode)mode beforeDate:(NSDate *)limitDate;

CFRunLoop提供的函数：
/// 默认模式
void CFRunLoopRun(void);
/// 在指定模式，指定时间，运行
CFRunLoopRunResult CFRunLoopRunInMode(CFRunLoopMode mode, CFTimeInterval seconds, Boolean returnAfterSourceHandled);

当执行了上面的运行方法后，如果runloop所在的模式没有对应的事件源，即上面图中提到的input sources、timer sources，会直接退出当前runloop（注意：是当前）。另外注意的是，input sources里面的Selector Sources，它有一些特殊情况，上面也提到了。这些情况下runloop还是会直接退出。

网上有很多说到事件源包括了observe，其实是不包含的，即runloop是否退出与observe没有关系，observe只是监听runloop本身的状态而已。

• 内部循环（略复杂）

这样看起来还是比较清晰的。

关于自动释放池提一下(下一篇会做详细说明)：

• 第1步的观察者（优先级较高）会创建自动释放池
• 第6步的观察者，会销毁老的自动释放池，并创建新的自动释放池，对于一个runloop来说，此步骤会不断的循环
• 第10步的观察者，销毁自动释放池

上面提到的自动释放池的处理当然是系统帮我们处理的，非主线程和主线程系统都帮我们做了处理。官方说到，如果你使用POSIX thread APIs创建线程，那就是另外一套内存回收系统了，是不会用autoreleasePool，系统当然也不会创建。

3. runloop退出

可以用以下方式退出runloop

• 设置最大时间到期：推荐使用这种方式
• modeItem(事件源)为空：但并不推荐这样退出，因为一些系统的Item我们并不知道
• 调用CFRunLoopStop，退出runloop并将程序控制权交给调用者（如果runloop有嵌套，则只退出最内层runloop），一些情况下，CFRunLoopStop并不能真正的退出runloop，比如你使用下面的2种方法开启runloop：

- (void)run; // 默认模式
- (void)runUntilDate:(NSDate *)limitDate;

当执行NSRunLoop的run方法，一旦成功(默认模式下有事件源)，那么run会不停的调用runMode:beforeDate:来运行runloop，那么即便CFRunLoopStop退出了一个runloop，很快会有另一个runloop执行。即：如果你想退出一个runloop，那么你就不该调用run方法来开启runloop

runUntilDate:与run一样不停的执行runMode:beforeDate:方法，CFRunLoopStop也是退不出来的，不同的是runUntilDate:自己有个期限，超过这个期限会自动退出

很明显，你会想到利用事件源为空来退出，这种方法上面已经说了，不推荐。。。

一个不想回答的问题：runloop本身的释放。有人会纠结这个问题，经过多方查问、资料、源码、测试加自身理解，得出：runloop退出后，是不会被释放的(或者说立即)，它大概很可能是伴随着线程的释放而释放。。。。。。欢迎补充

Runloop嵌套

嵌套，刚接触时感觉很神奇，然而一入嵌套深似海。。。特别是约瑟夫环的问题（http://www.jianshu.com/p/3c62ac7d9285）。。。

在当前runloop的callout函数里面执行上runloop,例程代码如下：

/**
 runloop嵌套测试，
 */
+ (void)nestTest {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        NSTimer *tickTimer = [[NSTimer alloc] initWithFireDate:[NSDate date] interval:1 target:self selector:@selector(timerHandle1) userInfo:nil repeats:YES];
        [[NSRunLoop currentRunLoop] addTimer:tickTimer forMode:NSDefaultRunLoopMode];
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode  beforeDate:[NSDate dateWithTimeIntervalSinceNow:2]];
        NSLog(@"-end-");
    });
}

/**
 不停的运行与退出最内层runloop
 */
+ (void)timerHandle1 {
    NSLog(@"timer111-%@",[[NSRunLoop currentRunLoop] currentMode]);
    // 防止多次添加timer，开发中应特别注意
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        NSTimer *tickTimer2 = [[NSTimer alloc] initWithFireDate:[NSDate date] interval:1 target:self selector:@selector(timerHandle2) userInfo:nil repeats:YES];
        [[NSRunLoop currentRunLoop] addTimer:tickTimer2 forMode:UITrackingRunLoopMode];
    });
    [[NSRunLoop currentRunLoop] runMode:UITrackingRunLoopMode  beforeDate:[NSDate distantFuture]];
}

+ (void)timerHandle2 {
    NSLog(@"timer222-%@",[[NSRunLoop currentRunLoop] currentMode]);
    CFRunLoopStop([[NSRunLoop currentRunLoop] getCFRunLoop]);
}

打印结果

例程中外层runloop运行在NSDefaultRunLoopMode模式下，然后在它的callout函数(定时器1)又执行runloop，运行在UITrackingRunLoopMode模式下，实现嵌套，然后在内层runloop的callout(timerHandle2)，停止运行当前runloop，即停止内层runloop，这时又回到外层循环。外层runloop只运行2秒到期。-end-

上面嵌套是运行在不同模式下，当同一模式下的runloop出现嵌套时，苹果依然处理的很好。举例：

1. 将t1（timer1）添加到r1（runloop1），并在NSDefaultRunLoopMode模式下运行
2. 在t1的响应函数里，将t2添加到r2，r2在NSDefaultRunLoopMode模式下运行
3. 此时很明显，r2处于嵌套内层，则只应该运行t2的响应函数
4. 在t2的响应函数里，退出r2，此时回到r1
5. 会运行t1与t2的响应函数

可能你会觉得很诧异，t2怎么也会运行呢？？？？其实这很符合逻辑：

假设在第2步骤中，我们没有执行r2，即没有r2，那么t2还是加到了r1上。既然是加到了r1那执行就不难理解了。（是否感觉苹果很强大？）

注意：r1与r2代表的是同一runloop，只是调用栈不同，或者说嵌套层。如果把runloop理解为一个函数，那么就可以理解为函数r1调用了自身，那个"自身"称为r2。

参考：http://www.jianshu.com/p/4263188ed940