LeeWong
首页 标签 归档 关于我

runloop 的那些事儿(转)

2018-02-28 iOS基础

最近在看iOS的一些基础原理,看到涂耀辉的这篇关于Runloop的,感觉原理+代码的这种讲解方式非常好,特地转过来，由于简书后半部分排版有点乱,这里特地按照我的思路重新整理一下！

先看AFN的一段经典代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
+ (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;
}

+ (void)networkRequestThreadEntryPoint:(id)__unused object {
    @autoreleasepool {
        [[NSThread currentThread] setName:@"AFNetworking"];
        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        [runLoop run];
    }
}

  • 1、首先我们要明确一个概念，线程一般都是一次执行完任务，就销毁了。
  • 2、而添加了runloop，并运行起来，实际上是添加了一个do,while循环，这样这个线程的程序一直卡在这个do,while循环上，这样相当于线程的任务一直没有执行完，所以线程一直不会销毁。
  • 3、所以，一旦我们添加了一个runloop，并run了，我们如果要销毁这个线程，必须停止runloop，至于停止的方式，我们接下去往下看。

注:这里创建的名为AFNetworking的线程,由于其被添加到Runloop上 所以除非Runloop被销毁,否则线程也不会被销毁

1、添加监听事件的端口

[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];

2、Runloop跑起来

[runLoop run];

不过以这种方式启动Runloop后只有一种方式可以终止该Runloop：
移除之前添加的端口 这样Runloop中没有事件了，所以可以直接退出。
[NSRunLoop currentRunLoop]removePort:<#(nonnull NSPort *)#> forMode:<#(nonnull NSRunLoopMode)#>

因此 我们可以得出AFN中并没有记录该port,所以压根就不会退出Runloop,所以这是一个常驻线程

再看看AFN3.X

开启RunLoop:

CFRunLoopRun();

终止RunLoop:

CFRunLoopStop(CFRunLoopGetCurrent());

RAC中的RunLoop

1
2
3
4
5
//自己用一个Bool值done去控制runloop的运行，每次只运行这
//个模式的runloop，0.1秒。0.1秒后开启runloop的下一次运行
do {
    [NSRunLoop.mainRunLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.1]];
} while (!done);

RunLoop概念

RunLoop官方图

Runloop，顾名思义就是跑圈，他的本质就是一个do,while循环，当有事做时做事，没事做时睡眠。至于怎么做事，怎么睡眠，这个是由系统内核来调度的，我们后面会讲到

每个线程都有一个Run Loop，主线程的Run Loop会在App运行时自动运行，子线程中需要手动获取运行，第一次获取时，才会去创建。

每个Run Loop都会以一个模式mode来运行，可以使用NSRunLoop的

-(BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate
方法来设置运行在那个特定的mode

  • 1 Run Loop的处理两大类事件源：Timer Source和Input Source(包括performSelector***方法簇,Port或者自定义Input Source)，每个事件源都会绑定在Run Loop的某个特定模式mode上，而且只有RunLoop在这个模式运行的时候才会触发该Timer和Input Source。

  • 2、如果没有任何事件源添加到RunLoop上，RunLoop就会立刻exit，这也是一开始的AF例子，为什么需要绑定一个Port的原因。

OS下Run Loop的主要运行模式mode有：

1、NSDefaultRunLoopMode: 默认的运行模式，除了NSConnection对象的事件。
2、NSRunLoopCommonModes: 是一组常用的模式集合，将一个input source关联到这个模式集合上，等于将input source关联到这个模式集合中的所有模式上。在iOS系统中NSRunLoopCommonMode包含NSDefaultRunLoopMode、NSTaskDeathCheckMode、UITrackingRunLoopMode。

假如我有个timer要关联到这些模式上，一个个注册很麻烦，我可以用

1
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

将UITrackingRunLoopMode或者其他模式添加到这个NSRunLoopCommonModes模式中，然后只需要将Timer关联到NSRunLoopCommonModes，即可以实现Run Loop运行在这个模式集合中任何一个模式时，这个Timer都可以被触发

当然，默认情况下NSRunLoopCommonModes包含了NSDefaultRunLoopMode和UITrackingRunLoopMode。我指的是如果有其他自定义Mode。

3、UITrackingRunLoopMode: 用于跟踪触摸事件触发的模式（例如UIScrollView上下滚动），主线程当触摸事件触发时会设置为这个模式，可以用来在控件事件触发过程中设置Timer。
4、GSEventReceiveRunLoopMode: 用于接受系统事件，属于内部的Run Loop模式。
5、自定义Mode：可以设置自定义的运行模式Mode，你也可以用CFRunLoopAddCommonMode添加到NSRunLoopCommonModes中

总结一下：

Run Loop运行时只能以一种固定的模式运行，如果我们需要它切换模式，只有停掉它，再重新开启它。

运行时它只会监控这个模式下添加的Timer Source和Input Source，如果这个模式下没有相应的事件源，Run Loop的运行也会立刻返回的。

注意Run Loop不能在运行在NSRunLoopCommonModes模式，因为NSRunLoopCommonModes其实是个模式集合，而不是一个具体的模式，我可以在添加事件源的时候使用NSRunLoopCommonModes，只要Run Loop运行在NSRunLoopCommonModes中任何一个模式，这个事件源都可以被触发

Run Loop运行接口

Foundation层和CoreFoundation层都有对应的接口可以操作RunLoop：

Foundation层对应的是NSRunLoop，Core Foundation层对应的是CFRunLoopRef；

两组接口差不多，不过功能上还是有许多区别的：
例如CF层可以添加自定义Input Source事件源、(CFRunLoopSourceRef)Run Loop观察者Observer(CFRunLoopObserverRef)，很多类似功能的接口特性也是不一样的。

NSRunLoop的运行接口：

1
2
3
4
5
6
7
8
9
//运行 NSRunLoop，运行模式为默认的NSDefaultRunLoopMode模式，没有超时限制
- (void)run;

//运行 NSRunLoop: 参数为运时间期限，运行模式为默认的NSDefaultRunLoopMode模式 
- (void)runUntilDate:(NSDate *)limitDate;

//运行 NSRunLoop: 参数为运行模式、时间期限，返回值为YES表示是处理事件后返回的，NO表示是超时或者停止运行导致返回的
- (BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate;

CFRunLoopRef的运行接口：

1
2
3
4
5
6
7
8
9
10
11
12
//运行 CFRunLoopRef
void CFRunLoopRun();

//运行 CFRunLoopRef: 参数为运行模式、时间和是否在处理Input Source后退出标志，返回值是exit原因
SInt32 CFRunLoopRunInMode (mode, seconds, returnAfterSourceHandled);

//停止运行 CFRunLoopRef
void CFRunLoopStop( CFRunLoopRef rl );

//唤醒CFRunLoopRef
void CFRunLoopWakeUp ( CFRunLoopRef rl );

下面分类进行详解

- (void)run; 无条件运行

  • AFN2.X使用的方式
  • 不建议使用，因为这个接口会导致Run Loop永久性的运行在NSDefaultRunLoopMode模式。
  • 即使用CFRunLoopStop(runloopRef);也无法停止Run Loop的运行，除非能移除这个runloop上的所有事件源，包括定时器和source事件，不然这个子线程就无法停止，只能永久运行下去。

- (void)runUntilDate:(NSDate *)limitDate; 有一个超时时间限制
比上面的接口好点，有个超时时间，可以控制每次Run Loop的运行时间，也是运行在NSDefaultRunLoopMode模式。
这个方法运行Run Loop一段时间会退出给你检查运行条件的机会，如果需要可以再次运行Run Loop。
注意CFRunLoopStop(runloopRef),也无法停止Run Loop的运行

1
2
3
4
5
while (!Done)
{
    [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:10]];
    NSLog(@"exiting runloop.........:");
}

注意这个Done是我们自定义的一个Bool值，用来控制是否还需要开启下一次的runloop。

这个例子大概做了如下的事：这个Runloop会每10秒退出一次，然后输出exiting runloop………，然后下一次根据我们的Done值来判断是否再去运行runloop

`//有一个超时时间限制，而且设置运行模式

  • (BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate;`

  • 这种运行方式是可以被CFRunLoopStop(runloopRef)所停止的(大家可以自己写个例子试试)。

  • 这个方法和第二个方法还有一个很大的区别就是这样去运行runloop会多一种退出方式。这里我指的退出方式是除了timer触发以外的事件，都会导致runloop退出

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
- (void)testDemo1
{
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        NSLog(@"线程开始");
        //获取到当前线程
        self.thread = [NSThread currentThread];
        
        NSRunLoop *runloop = [NSRunLoop currentRunLoop];
        //添加一个Port，同理为了防止runloop没事干直接退出
        [runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        
        //运行一个runloop，[NSDate distantFuture]：很久很久以后才让它失效
        [runloop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
        
        NSLog(@"线程结束");

    });
    
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        //在我们开启的异步线程调用方法
        [self performSelector:@selector(recieveMsg) onThread:self.thread withObject:nil waitUntilDone:NO];
    });
}

- (void)recieveMsg
{
    NSLog(@"收到消息了，在这个线程：%@",[NSThread currentThread]);
}

输出结果：

1
2
3
4
2016-11-22 14:04:15.250 TestRunloop3[70591:1742754] 线程开始
2016-11-22 14:04:17.250 TestRunloop3[70591:1742754] 收到消息了，在这个线程：<NSThread: 0x600000263c80>{number = 3, name = (null)}
2016-11-22 14:04:17.250 TestRunloop3[70591:1742754] 线程结束

在这里我们用了performSelector: onThread...这个方法去进行线程间通信，这只是其中一种最简单的方式。但是缺点也很明显，就是在去调用这个线程的时候，如果线程已经不存在了，程序就会crash。后面我们会仔细讲各种线程间的通信。

线程为什么会结束呢？

我们先看一下RunLoop的源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
/// RunLoop的实现
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
     
    /// 首先根据modeName找到对应mode
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
    /// 如果mode里没有source/timer/observer, 直接返回。
    if (__CFRunLoopModeIsEmpty(currentMode)) return;
     
    /// 1. 通知 Observers: RunLoop 即将进入 loop。
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
     
    /// 内部函数，进入loop
    __CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
         
        Boolean sourceHandledThisLoop = NO;
        int retVal = 0;
        do {
  
            /// 2. 通知 Observers: RunLoop 即将触发 Timer 回调。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
            /// 3. 通知 Observers: RunLoop 即将触发 Source0 (非port) 回调。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
            /// 执行被加入的block
            __CFRunLoopDoBlocks(runloop, currentMode);
             
            /// 4. RunLoop 触发 Source0 (非port) 回调。
            sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
            /// 执行被加入的block
            __CFRunLoopDoBlocks(runloop, currentMode);
  
            /// 5. 如果有 Source1 (基于port) 处于 ready 状态，直接处理这个 Source1 然后跳转去处理消息。
            if (__Source0DidDispatchPortLastTime) {
                Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
                if (hasMsg) goto handle_msg;
            }
             
            /// 6.通知 Observers: RunLoop 的线程即将进入休眠(sleep)。
            if (!sourceHandledThisLoop) {
                __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
            }
             
            /// 7. 调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。
            /// ? 一个基于 port 的Source 的事件。
            /// ? 一个 Timer 到时间了
            /// ? RunLoop 自身的超时时间到了
            /// ? 被其他什么调用者手动唤醒
            __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort) {
                mach_msg(msg, MACH_RCV_MSG, port); // thread wait for receive msg
            }
  
            /// 8. 通知 Observers: RunLoop 的线程刚刚被唤醒了。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);
             
            /// 9.收到消息，处理消息。
            handle_msg:
  
            /// 10.1 如果一个 Timer 到时间了，触发这个Timer的回调。
            if (msg_is_timer) {
                __CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
            } 
  
            /// 10.2 如果有dispatch到main_queue的block，执行block。
            else if (msg_is_dispatch) {
                __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
            } 
  
            /// 10.3 如果一个 Source1 (基于port) 发出事件了，处理这个事件
            else {
                CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
                sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
                if (sourceHandledThisLoop) {
                    mach_msg(reply, MACH_SEND_MSG, reply);
                }
            }
             
            /// 执行加入到Loop的block
            __CFRunLoopDoBlocks(runloop, currentMode);
             
  
            if (sourceHandledThisLoop && stopAfterHandle) {
                /// 进入loop时参数说处理完事件就返回。
                retVal = kCFRunLoopRunHandledSource;
            } else if (timeout) {
                /// 超出传入参数标记的超时时间了
                retVal = kCFRunLoopRunTimedOut;
            } else if (__CFRunLoopIsStopped(runloop)) {
                /// 被外部调用者强制停止了
                retVal = kCFRunLoopRunStopped;
            } else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
                /// source/timer/observer一个都没有了
                retVal = kCFRunLoopRunFinished;
            }
             
            /// 如果没超时，mode里没空，loop也没被停止，那继续loop。
        } while (retVal == 0);
    }
     
    /// 11. 通知 Observers: RunLoop 即将退出。
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}

大概流程是这样的：

1、函数的主体是一个do,while循环，用一个变量retVal，来控制循环的执行。默认为0，无限循环。
2、刚进入循环1，2，3，4，5在做一件事，就是检查是否有事件需要处理，如果有的话，就直接跳到9去处理事件。
3、处理完事件之后，到第10，会去判断4种是否应该跳出循环的情况，给变量retVal赋一个不为0的值，来跳出循环。
4、如果走到6，则判断没有事做，那么runloop就睡眠了，停在第7行，这一行

1
2
3
4
5
6
7
8
9
10
11
12
13
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort)
 { 
      // thread wait for receive msg 
      mach_msg(msg, MACH_RCV_MSG, port); 
}

这一行类似sync这样的一个同步机制（其实不是，举个例子。。）
，把程序阻塞在这一行，直到有消息返回值，才继续往下进行。
这一阻塞操作是系统内核来挂起的，阻塞了当前的线程，
当有消息返回时，因为当前线程是被阻塞的，
系统内核会再开辟一个新的线程去返回这个消息。
然后程序继续往下进行。

5、走到第8、9，通知Observers，然后处理事件。
6、到10，去判断是否退出循环的条件，如果满足条件退出循环，runloop结束。反之，又从新开始循环，从2开始。

那为什么执行完之后RunLoop会退出呢？

1
2
3
4
5
if (sourceHandledThisLoop && stopAfterHandle)
{ 
    /// 进入loop时参数说处理完事件就返回。 
    retVal = kCFRunLoopRunHandledSource; 
}

这种形式开启的runloop, stopAfterHandle这个参数为YES，
而sourceHandledThisLoop这个参数在如下代码中被赋值为YES：

1
2
3
4
5
6
7
8
9
/// 10.3 如果一个 Source1 (基于port) 发出事件了，处理这个事件
else {
    CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
    sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
    if (sourceHandledThisLoop) {
        mach_msg(reply, MACH_SEND_MSG, reply);
    }
}

所以在这里我们触发了事件之后，runloop被退出了，这时候我们也明白了为什么timer并不会导致runloop的退出。

Core Foundation中运行runloop的接口

1
2
3
4
5
6
7
8
9
//运行 CFRunLoopRef
void CFRunLoopRun();
//运行 CFRunLoopRef: 参数为运行模式、时间和是否在处理Input Source后退出标志，返回值是exit原因
SInt32 CFRunLoopRunInMode (mode, seconds, returnAfterSourceHandled);
//停止运行 CFRunLoopRef
void CFRunLoopStop( CFRunLoopRef rl );
//唤醒 CFRunLoopRef
void CFRunLoopWakeUp ( CFRunLoopRef rl );

下面详细介绍一下：

void CFRunLoopRun();

  • 运行在默认的kCFRunLoopDefaultMode模式下，直到使用CFRunLoopStop接口停止这个Run Loop，或者Run Loop的所有事件源都被删除。
  • NSRunloop是基于CFRunloop来封装的，NSRunloop是线程不安全的，而CFRunloop则是线程安全的。

注意:在这里我们可以看到和上面NSRunloop有一个直观的区别就是，CFRunLoopStop能直接停止掉所有用CFRunloop运行起runloop

现在回忆一下上面
- (BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate;
这个方法也是可以用CFRunLoopStop来停止 其实这是因为上面的方法是依据：
SInt32 CFRunLoopRunInMode (mode, seconds, returnAfterSourceHandled);
这个方法实现的,可以明显的看出参数是一模一样的,前者默认returnAfterSourceHandled参数为YES，当触发一个非timer事件后，runloop就终止了

SInt32 CFRunLoopRunInMode (mode, seconds, returnAfterSourceHandled);
其中

  • 第一个参数是指RunLoop运行的模式（例如kCFRunLoopDefaultMode或者kCFRunLoopCommonModes），
  • 第二个参数是运行时间，第三个参数是是否在处理事件后让Run Loop退出返回，NSRunloop的第三种开启runloop的方法，综上述，我们知道，实际上就是设置stopAfterHandle这个参数为YES
  • 我们知道调用runloop运行，代码是停在这一行不返回的，当返回的时候runloop就结束了，所以这个返回值就是runloop结束原因的返回，为一个枚举值，具体原因如下
1
2
3
4
5
6
7
enum {
    kCFRunLoopRunFinished = 1, //Run Loop结束，没有Timer或者其他Input Source
    kCFRunLoopRunStopped = 2, //Run Loop被停止，使用CFRunLoopStop停止Run Loop
    kCFRunLoopRunTimedOut = 3, //Run Loop超时
    kCFRunLoopRunHandledSource = 4 ////Run Loop处理完事件，注意Timer事件的触发是不会让Run Loop退出返回的，即使CFRunLoopRunInMode的第三个参数是YES也不行
};

看到这，我们发现我们忽略了NSRunloop第三种开启方式的返回值。
- (BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate;

它其实就是基于CFRunLoopRunInMode封装的，它的返回值为一个Bool值，如果是PerfromSelector***事件或者其他Input Source事件触发处理后，RunLoop会退出返回YES，其他返回NO。

下面举个例子来验证这个问题：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
- (void)testDemo2
{
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        
        NSLog(@"starting thread.......");
        NSTimer *timer = [NSTimer timerWithTimeInterval:1 target:self selector:@selector(doTimerTask1:) userInfo:remotePort repeats:YES];
        [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
            
        //最后一个参数，是否处理完事件返回,结束runLoop
        SInt32 result = CFRunLoopRunInMode(kCFRunLoopDefaultMode, 100, YES);
        /*
         kCFRunLoopRunFinished = 1, //Run Loop结束，没有Timer或者其他Input Source
         kCFRunLoopRunStopped = 2, //Run Loop被停止，使用CFRunLoopStop停止Run Loop
         kCFRunLoopRunTimedOut = 3, //Run Loop超时
         kCFRunLoopRunHandledSource = 4 ////Run Loop处理完事件，注意Timer事件的触发是不会让Run Loop退出返回的，即使CFRunLoopRunInMode的第三个参数是YES也不行
         */
        switch (result) {
            case kCFRunLoopRunFinished:
                NSLog(@"kCFRunLoopRunFinished");
                
                break;
            case kCFRunLoopRunStopped:
                NSLog(@"kCFRunLoopRunStopped");

            case kCFRunLoopRunTimedOut:
                NSLog(@"kCFRunLoopRunTimedOut");

            case kCFRunLoopRunHandledSource:
                NSLog(@"kCFRunLoopRunHandledSource");
            default:
                break;
        }
        
        NSLog(@"end thread.......");
        
    });

}

- (void)doTimerTask1:(NSTimer *)timer
{
    
    count++;
    if (count == 2) {
        [timer invalidate];
    }
    NSLog(@"do timer task count:%d",count);

输出结果如下：

1
2
3
4
5
6
2016-11-23 09:19:28.342 TestRunloop3[88598:1971412] starting thread.......
2016-11-23 09:19:29.347 TestRunloop3[88598:1971412] do timer task count:1
2016-11-23 09:19:30.345 TestRunloop3[88598:1971412] do timer task count:2
2016-11-23 09:19:30.348 TestRunloop3[88598:1971412] kCFRunLoopRunFinished
2016-11-23 09:19:30.348 TestRunloop3[88598:1971412] end thread.......

很清楚的可以看到，当timer被置无效的时候，runloop里面没有了任何的事件源，所以退出了，退出原因为：kCFRunLoopRunFinished，线程也就结束了。

总结

RunLoop停止和取消的方法

1、移除掉runloop中的所有事件源（timer和source）
2、设置一个超时时间。
3、只要CFRunloop运行起来就可以用：
void CFRunLoopStop( CFRunLoopRef rl );去停止。
4、除此之外用NSRunLoop下面这个方法运行也能使用
void CFRunLoopStop( CFRunLoopRef rl );停止：

1
2
[NSRunLoop currentRunLoop]runMode:<#(nonnull
 NSRunLoopMode)#> beforeDate:<#(nonnull NSDate *)#>

实际过程中，可以根据需求，我们可以设置一个自己的Bool值，
来控制runloop的开始与停止,类似下面这样：

1
2
3
  while (!cancel) {
CFRunLoopRunInMode(kCFRunLoopDefaultMode, 1, YES);
}
  • 每次runloop只运行1秒就停止，然后开始下一次的runloop。
  • 这里最后一个参数设置为YES，当有非timer事件进来，也会立即开始下一次runloop。
  • 当然每次进来我们都可以去修改Mode的值，这样我们可以让runloop每次都运行在不同的模式下。
  • 当我们不需要runloop的时候，直接将cancel置为YES即可

基于runloop的线程通信

首先明确一个概念，线程间的通信（不仅限于通信，几乎所有iOS事件都是如此），实际上是各种输入源，触发runloop去处理对应的事件，所以我们先来讲讲输入源：

输入源异步的发送消息给你的线程。事件来源取决于输入源的种类：

  • 基于端口的输入源和自定义输入源。基于端口的输入源监听程序相应的端口。自定义输入源则监听自定义的事件源。

至于run loop，它不关心输入源的是基于端口的输入源还是自定义的输入源。系统会实现两种输入源供你使用。两类输入源的区别在于：

  • 基于端口的输入源由内核自动发送，而自定义的则需要人工从其他线程发送。

当你创建输入源，你需要将其分配给RunLoop中的一个或多个模式。模式只会在特定事件影响监听的源。大多数情况下，RunLoop运行在默认模式下，但是你也可以使其运行在自定义模式。若某一源在当前模式下不被监听，那么任何其生成的消息只在RunLoop运行在其关联的模式下才会被传递。

基于端口的输入源:

在RunLoop中，被定义名为souce1。Cocoa和Core Foundation内置支持使用端口相关的对象和函数来创建的基于端口的源。例如，在Cocoa里面你从来不需要直接创建输入源。你只要简单的创建端口对象，并使用NSPort的方法把该端口添加到Run Loop。端口对象会自己处理创建和配置输入源。

在Core Foundation，你必须人工创建端口和它的RunLoop源.在两种情况下，你都可以使用端口相关的函数（CFMachPortRef，CFMessagePortRef，CFSocketRef）来创建合适的对象。

这里用Cocoa里的举个例子，Cocoa里用来线程间传值的是NSMachPort，它的父类是NSPort。
首先我们看下面：

1
2
3
4
NSPort *port1 = [[NSPort alloc]init];
NSPort *port2 = [[NSMachPort alloc]init];
NSPort *port3 = [NSPort port];
NSPort *port4 = [NSMachPort port];

我们打断点可以看到如下：
port图.png

  • 发现我们怎么创建，都返回给我们的是NSMachPort的实例，这应该是NSPort内部做了一个消息的转发，这就有点像是一个抽象类了，它本身只是定义一些公有的属性和方法，然后利用集成它的子类去实现（只是我个人猜测。。）

继续看我们写的一个利用NSMachPort来线程通信的实例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
(void)testDemo3
{
//声明两个端口 随便怎么写创建方法，返回的总是一个NSMachPort实例
NSMachPort *mainPort = [[NSMachPort alloc]init];
NSPort *threadPort = [NSMachPort port];

//设置线程的端口的代理回调为自己
threadPort.delegate = self;

//给主线程runloop加一个端口
[[NSRunLoop currentRunLoop]addPort:mainPort forMode:NSDefaultRunLoopMode];

dispatch_async(dispatch_get_global_queue(0, 0), ^{

  //添加一个Port
  [[NSRunLoop currentRunLoop]addPort:threadPort forMode:NSDefaultRunLoopMode];
  [[NSRunLoop currentRunLoop]runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
});

NSString *s1 = @"hello";

NSData *data = [s1 dataUsingEncoding:NSUTF8StringEncoding];

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
NSMutableArray *array = [NSMutableArray arrayWithArray:@[mainPort,data]];
//过2秒向threadPort发送一条消息，第一个参数：发送时间。msgid 消息标识。
//components，发送消息附带参数。reserved：为头部预留的字节数（从官方文档上看到的，猜测可能是类似请求头的东西...）
[threadPort sendBeforeDate:[NSDate date] msgid:1000 components:array from:mainPort reserved:0];

});

}

这个NSMachPort收到消息的回调，注意这个参数，可以先给一个id。如果用文档里的NSPortMessage会发现无法取值

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
(void)handlePortMessage:(id)message
{

NSLog(@"收到消息了，线程为：%@",[NSThread currentThread]);

//只能用KVC的方式取值
NSArray *array = [message valueForKeyPath:@"components"];

NSData *data = array[1];
NSString *s1 = [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
NSLog(@"%@",s1);

// NSMachPort *localPort = [message valueForKeyPath:@"localPort"];
// NSMachPort *remotePort = [message valueForKeyPath:@"remotePort"];

}

结果打印如下：

1
2
3
2016-11-23 16:50:20.604 TestRunloop3[1322:120162] 收到消息了，线程为：<NSThread: 0x60800026d700>{number = 3, name = (null)}
2016-11-23 16:50:26.551 TestRunloop3[1322:120162] hello

  • 1、我们跨越线程，确实从主线程往另一个线程发送了消息。

  • 2、这里要注意几个点：

    1、- (void)handlePortMessage:(id)message这里这个代理的参数，从.h里去复制过来的为NSPortMessage类型的一个对象，但是我们发现苹果只是在.h中@class进来，我们无法调用它的任何方法。所以我们用id声明，然后通过KVC去取它的属性。

    2、关于下面这个传值类型的问题：

    1
    2
    NSMutableArray *array = [NSMutableArray  
    arrayWithArray:@[mainPort,data]];

作者在这困惑了好一会。。之前我是往数组里添加的是String或者其他类型的对象，但是发现参数传过去之后，变成nil了。于是去百度查了半天，然后没有结果。。于是去翻官方文档，终于在方法描述里看到（其实很醒目。。然而作者英文水平实在有限。。）：

1
2
3
4
5
6
7
The components array consists of a series of instances of some subclass of NSData, 
and instances of some subclass of NSPort; 
since one subclass of NSPort does not necessarily know  how to transport an instance of another subclass of NSPort (or could do it even if it

knew about the other subclass), all of the instancesof NSPort in the components array and the
 'receivePort'argument MUST be of the same subclass of NSPort that receives this message.  If 
 multiple DO transports are being used in the same program, this requires some care.

从这段描述中我们可以看出，这个传参数组里面只能装两种类型的数据，一种是NSPort的子类，一种是NSData的子类。所以我们如果要用这种方式传值必须得先把数据转成NSData类型的才行。

Cocoa 执行 Selector 的源:

除了基于端口的源，Cocoa定义了自定义输入源，允许你在任何线程执行selector。它被称为source0,和基于端口的源一样，执行selector请求会在目标线程上序列化，减缓许多在线程上允许多个方法容易引起的同步问题。不像基于端口的源，一个selector执行完后会自动从run loop里面移除。

有方法如下

1
2
3
4
5
6
7
8
[self performSelectorOnMainThread:<#(nonnull SEL)#> withObject:<#(nullable id)#> waitUntilDone:<#(BOOL)#>]

[self performSelectorOnMainThread:<#(nonnull SEL)#> withObject:<#(nullable id)#> waitUntilDone:<#(BOOL)#> modes:<#(nullable NSArray<NSString *> *)#>]

[self performSelector:<#(nonnull SEL)#> onThread:<#(nonnull NSThread *)#> withObject:<#(nullable id)#> waitUntilDone:<#(BOOL)#>]

[self performSelector:<#(nonnull SEL)#> onThread:<#(nonnull NSThread *)#> withObject:<#(nullable id)#> waitUntilDone:<#(BOOL)#> modes:<#(nullable NSArray<NSString *> *)#>]

  • 这四个方法很类似，一个是在主线程去掉，一个可以指定一个线程。然后一个带Mode，一个不带。
  • 大概讲一下 waitUntilDone 这个参数，顾名思义，就是是否等到结束。
    1）如果这个值设为YES，那么就需要等到这个方法执行完，线程才能继续往下去执行。它会阻塞提交的线程。
    2）如果为NO的话，这个调用的方法会异步的实行，不会阻塞提交线程。

自定义输入源:

为了自定义输入源，必须使用 Core Foundation里面的 CGRunLoopSourceRef类型相关的函数来创建。你可以使用回调函数来配置自定义输入源。Corefondation 会在配置源的不同地方调用回调函数，处理输入时间，在源从 runloop 移除的时候清理它。
除了定义在事件到达时自定义输入源的行为，你也必须定义消息传递机制。源的这部分运行在单独的线程里面，并负责在数据等待处理的时候传递数据给源并源并通知它处理数据。消息传递机制的定义取决于你，但是最好不要过于复杂。
创建自定义的输入源包括定义以下内容：
1.输入源要处理的信息。
2.使感兴趣的客户端知道如何和输入源交互的调度例程。
3.处理其他任何客户端发送请求的例程。
4.使输入源失效的取消例程。

由于创建输入源来处理自定义消息，实际配置选是灵活配置的。调度
例程，处理例程和取消例程都是创建自定义输入源是最关键的例程。
二输入源其他的大部分行为都发生在这些例程的外部。比如，由于你决定数据传输到输入源的机制，还有输入源和其他线程的通信机制也
是由你决定。

下图中，程序的主线程维护了一个输入源的引用，输入源所需的自定义命令缓冲区和输入源所在的 runloop。当主线程有任务需要分发
给工作线程时候，**主线程会给命令缓冲区发送命令和必须的信息来通知工作线程开始执行任务。（因为主线程和输入源所在工作线程
都可以访问命令缓冲区，因此这些访问必须是同步的）**一旦命令
传送出去，主线程会通知输入源并且唤醒工作线程的 runloop。而一收到唤醒命令，runloop 会调用输入源的处理程序，由它来执行
命令缓冲区中响应的命令。

1
2
3
CFRunLoopRef _runLoopRef;
CFRunLoopSourceRef _source;
CFRunLoopSourceContext _source_context;

自定义输入源.png

还是一样，我们来写一个实例来讲讲自定义的输入源（注：自定义输入源，只有用CF来实现）：

1
2
3
CFRunLoopRef _runLoopRef;
CFRunLoopSourceRef _source;
CFRunLoopSourceContext _source_context;

首先我们声明3个成员变量，这是我们自定义输入源所需要的3个参数。具体我们举完例子之后再说。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
(void)testDemo4
{
dispatch_async(dispatch_get_global_queue(0, 0), ^{

  NSLog(@"starting thread.......");
  
  _runLoopRef = CFRunLoopGetCurrent();
  //初始化_source_context。
  bzero(&_source_context, sizeof(_source_context));
  //这里创建了一个基于事件的源，绑定了一个函数
  _source_context.perform = fire;
  //参数
  _source_context.info = "hello";
  //创建一个source
  _source = CFRunLoopSourceCreate(NULL, 0, &_source_context);
  //将source添加到当前RunLoop中去
  CFRunLoopAddSource(_runLoopRef, _source, kCFRunLoopDefaultMode);

  //开启runloop 第三个参数设置为YES，执行完一次事件后返回
  CFRunLoopRunInMode(kCFRunLoopDefaultMode, 9999999, YES);
  
  NSLog(@"end thread.......");
});
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
    
    if (CFRunLoopIsWaiting(_runLoopRef)) {
        NSLog(@"RunLoop 正在等待事件输入");
        //添加输入事件
        CFRunLoopSourceSignal(_source);
        //唤醒线程，线程唤醒后发现由事件需要处理，于是立即处理事件
        CFRunLoopWakeUp(_runLoopRef);
    }else {
        NSLog(@"RunLoop 正在处理事件");
        //添加输入事件，当前正在处理一个事件，当前事件处理完成后，立即处理当前新输入的事件
        CFRunLoopSourceSignal(_source);
    }
});

}

此输入源需要处理的后台事件

1
2
3
4
5
6
static void fire(void* info){

NSLog(@"我现在正在处理后台任务");

printf("%s",info);
}

输出结果如下：

1
2
3
4
5
6
2016-11-24 10:42:24.045 TestRunloop3[4683:238183] starting thread.......
2016-11-24 10:42:26.045 TestRunloop3[4683:238082] RunLoop 正在等待事件输入
2016-11-24 10:42:31.663 TestRunloop3[4683:238183] 我现在正在处理后台任务
hello
2016-11-24 10:42:31.663 TestRunloop3[4683:238183] end thread.......

例中可见我们创建一个自定义的输入源，绑定了一个函数，一个参数，并且用这个输入源，实现了线程间的通信。

大概讲一下：

1、CFRunLoopRef _runLoopRef;就不用说了，就是CF的runloop。

2、CFRunLoopSourceContext _source_context;注意到例中用了一个c函数bzero(&_source_context, sizeof(_source_context));来初始化。

其实它本质是一个结构体如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
>version
Version number of the structure. Must be 0.
info
An arbitrary pointer to program-defined data, which can be associated with the CFRunLoopSource
 at creation time. This pointer is passed to all the callbacks defined in the context.
retain
A retain callback for your program-defined info 
pointer. Can be NULL.
release
A release callback for your program-defined info 
pointer. Can be NULL.
copyDescription
A copy description callback for your program-
defined info pointer. Can be NULL.
equal
An equality test callback for your program-defined 
info pointer. Can be NULL.
hash
A hash calculation callback for your program-
defined info pointer. Can be NULL.
schedule
A scheduling callback for the run loop source. 
This callback is called when the source is added to a run loop mode. Can be NULL.
cancel
A cancel callback for the run loop source. This 
callback is called when the source is removed from a run loop mode. Can be NULL.
perform
A perform callback for the run loop source. This 
callback is called when the source has fired.

typedef struct {
CFIndex version;
void * info;
const void (retain)(const void info);
void (release)(const void info);
CFStringRef (copyDescription)(const void info);
Boolean (equal)(const void *info1, const void info2);
CFHashCode (hash)(const void info);
void (schedule)(void info, CFRunLoopRef rl, CFRunLoopMode mode);
void (cancel)(void info, CFRunLoopRef rl, CFRunLoopMode mode);
void (perform)(void *info);
} CFRunLoopSourceContext;

bzero(&_source_context, sizeof(_source_context));所以这个函数其实就是把所有内容先置为0。

CFRunLoopSourceRef _source;这个是自定义输入源中最重要的一个参数。它用来连接runloop与
CFRunLoopSourceContext中的一些配置项，注意我们自定义的输入源，必须由我们手动来触发。需要先
CFRunLoopSourceSignal(_source);在看当前runloop是否在休眠中，来看是否需要调用
CFRunLoopWakeUp(_runLoopRef);(一般都是要调用的)。

定时源:

  • 定时源在预设的时间点同步方式传递消息。定时器是线程通知自己做某事的一种方法。
  • 尽管定时器可以产生基于时间的通知，但它并不是实时机制。和输入源一样，定时器也和 runloop 的特定模式相关。如果定时器所在的模式当前未被 runloop 监视，那么定时器将不会开始知道 runloop 运行在响应的模式下。类似的。如果定时器在 runloop 处理某一事件期间开始，定时器会一直等待直到下次 runloop 开始响应的处理程序。如果 runloop 不运行了，那么定时器也永远不启动。
  • 配置定时源:
    Cocoa 中可以使用以下 NSTimer 类方法来创建并调配一个定时器:􏰂
1
2
3
4
[NSTimer scheduledTimerWithTimeInterval:<#(NSTimeInterval)#> target:<#(nonnull id)#> selector:<#(nonnull SEL)#> userInfo:<#(nullable id)#> repeats:<#(BOOL)#>

[NSTimer timerWithTimeInterval:<#(NSTimeInterval)#> target:<#(nonnull id)#> selector:<#(nonnull SEL)#> userInfo:<#(nullable id)#> repeats:<#(BOOL)#>]

当然还有Block ,invocation的形式，就不做赘述了。
第一种timer默认是把加到了NSDefaultRunLoopMode模式下。
第二种timer没有默认值，我们使用的使用必须调用
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];去给它指定一个mode。

Core Foundation 创建定时器

1
2
3
4
5
CFRunLoopRef runLoop = CFRunLoopGetCurrent();
CFRunLoopTimerContext context = {0, NULL, NULL, NULL, NULL};
CFRunLoopTimerRef timer = CFRunLoopTimerCreate(kCFAllocatorDefault, 0.1, 0.3, 0, 0,
&myCFTimerCallback, &context);

最后用一张runloop运行时的流程图来梳理一下我们这些源触发的顺序
RunLoop_1.png

如图所示，首先我要明确一个知识点：runloop跑一圈，只能执行一个事件。

timer和source0进入runloop中，都只是通知Observer我要处理，但是还是会有 678睡眠唤醒这一步。但是source1如果有，就会直接跳到第9步去执行。

我们前面也讲过第7步，这里再提一下。它是一直阻塞在这一行的，直到：

  • a.soruce1来了。

  • b.定时器启动。

  • c.runloop超时。

  • d.runloop被显示唤醒CFRunLoopWakeUp(runloop) (也就是source0来了)。

    这里可能大家会奇怪了，之前不是说source1有的话就直接跳到第9步去执行了么？但是仔细想想，如果runloop正处在睡眠状态下，这时候有个soruce1来了，是不是也需要唤醒runloop~

Run Loop的Observer

上图提到了Observer，顺带简单讲讲吧：
Core Foundation层的接口可以定义一个Run Loop的观察者在— Run Loop进入以下某个状态时得到通知：

  • Run loop的进入
  • Run loop处理一个Timer的时刻
  • Run loop处理一个Input Source的时刻
  • Run loop进入睡眠的时刻
  • Run loop被唤醒的时刻，但在唤醒它的事件被处理之前
  • Run loop的终止
  • Observer的创建以及添加到Run Loop中需要使用Core Foundation的接口：
    方法很简单如下：
1
2
3
4
// 创建observer
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
});

1
2
3
4
// 添加观察者：监听RunLoop的状态
CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);
// 释放Observer
CFRelease(observer);

方法就是创建一个observer，绑定一个runloop和模式，而block回调就是监听到runloop每种状态的时候会触发。

其中CFRunLoopActivity是一枚举值，与每种状态对应：

1
2
3
4
5
6
7
8
9
10
11
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 1 // 即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 2 // 即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 4 即将处理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 32 // 即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 64
// 刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), // 128 // 即将退出Loop
kCFRunLoopAllActivities = 0x0FFFFFFFU // 可以监听以上所有状态
};

RunLoop 与线程的关系

iOS 开发中能遇到两个线程对象: pthread_t 和 NSThread,过去苹果有份文档标明了 NSThread 只是 pthread_t 的封装，但那份文档已经失效了，现在它们也有可能都是直接包装自最底层的 mach thread。

苹果并没有提供这两个对象相互转换的接口，但不管怎么样，可以肯定的是 pthread_t 和 NSThread 是一一对应的。比如，你可以通过 pthread_main_thread_np() 或 [NSThread mainThread] 来获取主线程；也可以通过 pthread_self() 或 [NSThread currentThread] 来获取当前线程。CFRunLoop 是基于 pthread 来管理的。

苹果不允许直接创建 RunLoop，它只提供了两个自动获取的函数：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 这两个函数内部的逻辑大概是下面这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/// 全局的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 访问 loopsDic 时的锁
static CFSpinLock_t loopsLock;
 
/// 获取一个 pthread 对应的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
    OSSpinLockLock(&loopsLock);
    
    if (!loopsDic) {
        // 第一次进入时，初始化全局Dic，并先为主线程创建一个 RunLoop。
        loopsDic = CFDictionaryCreateMutable();
        CFRunLoopRef mainLoop = _CFRunLoopCreate();
        CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
    }
    
    /// 直接从 Dictionary 里获取。
    CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
    
    if (!loop) {
        /// 取不到时，创建一个
        loop = _CFRunLoopCreate();
        CFDictionarySetValue(loopsDic, thread, loop);
        /// 注册一个回调，当线程销毁时，顺便也销毁其对应的 RunLoop。
        _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
    }
    
    OSSpinLockUnLock(&loopsLock);
    return loop;
}
 
CFRunLoopRef CFRunLoopGetMain() {
    return _CFRunLoopGet(pthread_main_thread_np());
}
 
CFRunLoopRef CFRunLoopGetCurrent() {
    return _CFRunLoopGet(pthread_self());
}

从上面的代码可以看出，线程和 RunLoop 之间是一一对应的，其关系是保存在一个全局的 Dictionary 里。线程刚创建时并没有 RunLoop，如果你不主动获取，那它一直都不会有。RunLoop 的创建是发生在第一次获取时，RunLoop 的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop（主线程除外）。

RunLoop 对外的接口

在 CoreFoundation 里面关于 RunLoop 有5个类:

1
2
3
4
5
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef

其中 CFRunLoopModeRef 类并没有对外暴露，只是通过 CFRunLoopRef 的接口进行了封装。他们的关系如下:

一个 RunLoop 包含若干个 Mode，每个 Mode 又包含若干个 Source/Timer/Observer。每次调用 RunLoop 的主函数时，只能指定其中一个 Mode，这个Mode被称作 CurrentMode。如果需要切换 Mode，只能退出 Loop，再重新指定一个 Mode 进入。这样做主要是为了分隔开不同组的 Source/Timer/Observer，让其互不影响。

CFRunLoopSourceRef 是事件产生的地方。Source有两个版本：Source0 和 Source1。

Source0 只包含了一个回调（函数指针），它并不能主动触发事件。使用时，你需要先调用 CFRunLoopSourceSignal(source)，将这个 Source 标记为待处理，然后手动调用 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop，让其处理这个事件。
Source1 包含了一个 mach_port 和一个回调（函数指针），被用于通过内核和其他线程相互发送消息。这种 Source 能主动唤醒 RunLoop 的线程，其原理在下面会讲到。

CFRunLoopTimerRef 是基于时间的触发器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一个时间长度和一个回调（函数指针）。当其加入到 RunLoop 时，RunLoop会注册对应的时间点，当时间点到时，RunLoop会被唤醒以执行那个回调。

CFRunLoopObserverRef 是观察者，每个 Observer 都包含了一个回调（函数指针），当 RunLoop 的状态发生变化时，观察者就能通过回调接受到这个变化。可以观测的时间点有以下几个：

1
2
3
4
5
6
7
8
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
};

上面的 Source/Timer/Observer 被统称为 mode item，一个 item 可以被同时加入多个 mode。但一个 item 被重复加入同一个 mode 时是不会有效果的。如果一个 mode 中一个 item 都没有，则 RunLoop 会直接退出，不进入循环。

RunLoop 的 Mode

CFRunLoopMode 和 CFRunLoop 的结构大致如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct __CFRunLoopMode {
    CFStringRef _name;            // Mode Name, 例如 @"kCFRunLoopDefaultMode"
    CFMutableSetRef _sources0;    // Set
    CFMutableSetRef _sources1;    // Set
    CFMutableArrayRef _observers; // Array
    CFMutableArrayRef _timers;    // Array
    ...
};
 
struct __CFRunLoop {
    CFMutableSetRef _commonModes;     // Set
    CFMutableSetRef _commonModeItems; // Set<Source/Observer/Timer>
    CFRunLoopModeRef _currentMode;    // Current Runloop Mode
    CFMutableSetRef _modes;           // Set
    ...
};

这里有个概念叫 “CommonModes”：一个 Mode 可以将自己标记为”Common”属性（通过将其 ModeName 添加到 RunLoop 的 “commonModes” 中）。每当 RunLoop 的内容发生变化时，RunLoop 都会自动将 _commonModeItems 里的 Source/Observer/Timer 同步到具有 “Common” 标记的所有Mode里。

应用场景举例：主线程的 RunLoop 里有两个预置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。这两个 Mode 都已经被标记为”Common”属性。DefaultMode 是 App 平时所处的状态，TrackingRunLoopMode 是追踪 ScrollView 滑动时的状态。当你创建一个 Timer 并加到 DefaultMode 时，Timer 会得到重复回调，但此时滑动一个TableView时，RunLoop 会将 mode 切换为 TrackingRunLoopMode，这时 Timer 就不会被回调，并且也不会影响到滑动操作。

有时你需要一个 Timer，在两个 Mode 中都能得到回调，一种办法就是将这个 Timer 分别加入这两个 Mode。还有一种方式，就是将 Timer 加入到顶层的 RunLoop 的 “commonModeItems” 中。”commonModeItems” 被 RunLoop 自动更新到所有具有”Common”属性的 Mode 里去。

  • CFRunLoop对外暴露的管理 Mode 接口只有下面2个:
1
2
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);
  • Mode 暴露的管理 mode item 的接口有下面几个：
1
2
3
4
5
6
7
8
9
10
11
12
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 只能增加不能删除。

苹果公开提供的 Mode 有两个：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，你可以用这两个 Mode Name 来操作其对应的 Mode。

同时苹果还提供了一个操作 Common 标记的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你可以用这个字符串来操作 Common Items，或标记一个 Mode 为 “Common”。使用时注意区分这个字符串和其他 mode name。

苹果用 RunLoop 实现的功能

AutoreleasePool

App启动后，苹果在主线程 RunLoop 里注册了两个 Observer，其回调都是 _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()。

当一个硬件事件(触摸/锁屏/摇晃等)发生后，首先由 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 标记为待处理。

苹果注册了一个 Observer 监测 BeforeWaiting (Loop即将进入休眠) 事件，这个Observer的回调函数是 _UIGestureRecognizerUpdateObserver()，其内部会获取所有刚被标记为待处理的 GestureRecognizer，并执行GestureRecognizer的回调。

当有 UIGestureRecognizer 的变化(创建/销毁/状态改变)时，这个回调都会进行相应处理

界面更新

当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer 就被标记为待处理，并被提交到一个全局的容器去。

苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件，回调去执行一个很长的函数：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。

定时器

NSTimer 其实就是 CFRunLoopTimerRef，他们之间是 toll-free bridged 的。一个 NSTimer 注册到 RunLoop 后，RunLoop 会为其重复的时间点注册好事件。例如 10:00, 10:10, 10:20 这几个时间点。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 的东西

当调用 dispatch_async(dispatch_get_main_queue(), block) 时，libDispatch 会向主线程的 RunLoop 发送消息，RunLoop会被唤醒，并从消息中取得这个 block，并在回调 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里执行这个 block。但这个逻辑仅限于 dispatch 到主线程，dispatch 到其他线程仍然是由 libDispatch 处理的。

最后

至此 本次关于RunLoop的所有内容总结完成,主要是汇总下面的两篇文章,看那么长的文章其实很大程度锻炼耐心呀！

参考文章

基于runloop的线程保活、销毁与通信
深入理解RunLoop

更新于 2020-12-05

iOS基础# Runloop
Previous Post
RunTime的那些事儿
Next Post
block的那些事