RunLoop介绍

从字面上来看，RunLoop是循环执行、跑圈的意思，实质上，RunLoop是一种寄生于线程的消息循环机制，它能保证线程的存活，而不是线程执行完任务后就消亡。

特性：

• RunLoop与线程是一一对应的，每个线程只有唯一与之对应的一个RunLoop。我们不能创建RunLoop，只能在当前线程中获取线程对应的RunLoop（主线程RunLoop除外）

• 子线程默认没有RunLoop，需要我们主动去开启，但是主线程是自动开启RunLoop的，这能保证应用程序的执行运行，接收并处理各种事件

• RunLoop想要正常启用需要运行在添加了事件源的Mode下，否则会自动退出，一个RunLoop可以拥有多个Mode，Mode可以拥有多个Source/Timer/Observer

• RunLoop有三种启动方式：run, runUntilDate:,runMode:beforeDate:，第一种无条件永远运行RunLoop并且无法停止，线程永远存在；第二种会在指定时间到达后退出RunLoop，同样无法主动停止RunLoop；前两种都是在 NSDafaultRunLoopMode 模式下运行。第三种可以选定运行模式，并且在时间到达后或者触发了非Timer的事件后退出

iOS 中的RunLoop

在iOS系统中，提供了两种RunLoop：NSRunLoop和CFRunLoopRef。

CFRunLoopRef 是在 CoreFoundation 框架内，它提供了纯 C 函数的 API，所有的 API 都是线程安全的。

NSRunLoop 是基于 CFRunLoopRef 的封装，提供了面向对象的 API， 但是这些 API 不是线程安全的。

我们不能够直接创建RunLoop，系统为我们提供了获取的方法

[NSRunLoop currentRunLoop]; //获取当前线程的RunLoop
[NSRunLoop mainRunLoop]; //获取主线程的RunLoop
CFRunLoopGetMain(); //获取当前线程的RunLoop
CFRunLoopGetCurrent(); //获取主线程的RunLoop

RunLoop应用举例

保证线程的存活

抛开主线程使用RunLoop一直执行外，我们知道，子线程都是一次性的，即执行完任务后就不可用了（系统也并没有提供再次赋予线程任务的功能），即使我们使用对象持有它，但是当我们再次想要 start 的时候，程序则会抛出异常，就像下面的例子。

首先，我们创建一个线程对象，使用 self 持有该线程。

- (void)viewDidLoad {
    [super viewDidLoad];
    self.testThread = [[NSThread alloc] initWithTarget:self selector:@selector(runTask) object:nil];
    self.testThread.name = @"测试线程";
    [self.testThread start];
}
-(void)runTask{
     NSLog(@"%@:执行任务",[NSThread currentThread]);
}

结果

运行之后，我们发现，任务线程很happy的跑完，一切正常。

但是，如果我们尝试再次使用该线程运行任务时。

结果

是的，程序抛出了异常，理由是attempt to start the again，尝试再次开启线程。

既然子线程是一次性的，那么我们在遇到很多耗时的任务，每次都去开启线程不就可以了么？当然这是可以的，但是开启线程是相当耗费资源的，并发的开启多个异步线程显然是不太理想的。

Event Loop模式

我们进入NSThread里，拉到最后看一下，最后面有NSObject的拓展。

- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(nullable id)arg waitUntilDone:(BOOL)wait modes:(nullable NSArray<NSString *> *)array;
- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(nullable id)arg waitUntilDone:(BOOL)wait;
    // equivalent to the first method with kCFRunLoopCommonModes

- (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(nullable id)arg waitUntilDone:(BOOL)wait modes:(nullable NSArray<NSString *> *)array API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
- (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(nullable id)arg waitUntilDone:(BOOL)wait API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
    // equivalent to the first method with kCFRunLoopCommonModes
- (void)performSelectorInBackground:(SEL)aSelector withObject:(nullable id)arg API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));

这些方法的意思是，当前对象指定在某个线程上完成某个任务，常用的就是performSelectorOnMainThread 回到主线程更新UI。这种方式称为 Event Loop ，即线程一直处于等待接收执行任务消息状态，一旦有消息，再去执行对应的任务，这和直接被赋予某一种任务是不同的，后者一旦执行完任务后就进入死亡状态，不可再用，前者则一直处于等待状态，有任务就去执行，没任务就进入休眠，不占用系统多余的资源。

可以说RunLoop实现的本质就是 do while 循环，当然其中的逻辑并不是那么简单，有兴趣的可以看下这一篇RunLoop入门学习补充资料。

尝试RunLoop

既然上面提到RunLoop可以让线程一直存活，接下来我们尝试手动开启一下RunLoop。

- (void)viewDidLoad {
    [super viewDidLoad];
    self.testThread = [[NSThread alloc] initWithTarget:self selector:@selector(runTask) object:nil];
    self.testThread.name = @"测试线程";
    [self.testThread start];
}

-(void)runTask{
    NSLog(@"当前线程：%@",[NSThread currentThread]);
    // 获取当前线程的 runLoop
    NSRunLoop* runLoop = [NSRunLoop currentRunLoop];
    // 为当前的 runLoop 添加 model
    [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
    // 运行 runLoop
    [runLoop run];
    // 测试是否执行到这里
    NSLog(@"任务结束");
}

结果

结果我们发现，当runLoop执行run后，NSLog(@"任务结束");并没有执行，这说明runLoop开始‘跑圈‘了，因为线程任务一直没有完成，因此我们的testThread不会被标记为死亡状态。

接下来，我们利用 Event Loop 模式和这个 testThread 来执行其他一些任务。

-(void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event{
    [self performSelector:@selector(runTask2) onThread:self.testThread withObject:nil waitUntilDone:NO];
}

-(void)runTask2{
    NSLog(@"当前线程：%@",[NSThread currentThread]);
    NSLog(@"%s 完成",__PRETTY_FUNCTION__);
}

结果

我们发现，runTask2 运行的线程是我们的 testThread，我们的runLoop起作用了，并且我们可以一直利用这个 子线程 去完成一些耗时操作。

AFNetworking

AFURLConnectionOperation 这个类是基于 NSURLConnection 构建的，其希望能在后台线程接收 Delegate 回调。为此 AFNetworking 单独创建了一个线程，并在这个线程中启动了一个 RunLoop。

+ (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;
}

RunLoop 启动前内部必须要有至少一个 Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先创建了一个新的 NSMachPort 添加进去了。通常情况下，调用者需要持有这个 NSMachPort (mach_port) 并在外部线程通过这个 port 发送消息到 loop 内；但此处添加 port 只是为了让 RunLoop 不至于退出，并没有用于实际的发送消息。

- (void)start {
    [self.lock lock];
    if ([self isCancelled]) {
        [self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    } else if ([self isReady]) {
        self.state = AFOperationExecutingState;
        [self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    }
    [self.lock unlock];
}

当需要这个后台线程执行任务时，AFNetworking 通过调用 [NSObject performSelector:onThread:..] 将这个任务扔到了后台线程的 RunLoop 中。

NSTimer

NSTimer定时器的基于RunLoop运行的，所以使用NSTimer之前必须注册到RunLoop。同时我们也应该知道Timer并不是严格的按照设定的时间点来触发的，RunLoop为了节省资源并不会在非常准确的时间点调用定时器，如果一个任务执行时间较长，那么当错过一个时间点后只能等到下一个时间点执行，并不会延后执行。（NSTimer提供了一个tolerance属性用于设置宽容度，如果确实想要使用NSTimer并且希望尽可能的准确，则可以设置此属性）

scheduedTimerWith方法创建的NSTimer就不需要添加到RunLoop中就可以运行。事实上，这一系列方法是自行创建一个定时器并自动添加到当前线程RunLoop的NSDefaultRunLoopMode中

由于我们将NSTimer运行在了NSDefaultRunLoopMode模式下，因此在某些情境下，NSTimer会失效，如Scrollview拖拽事件下，这是由于Scrollview拖拽事件会使得主线程的RunLoop自动切换成UITrackingRunLoopMode模式（RunLoop每次只能运行在一个Mode下），导致NSTimer无法正常运行，当拖拽事件结束后，NSTimer可以继续运行。如果需要一直响应，可以将Timer同时添加到两种Mode下。

常用的Mode

1、kCFRunLoopDefaultMode（CFRunLoop）/NSDefaultRunLoopMode（NSRunLoop）// 默认模式，在RunLoop没有指定Mode的时候，默认就跑在DefaultMode下
 
2、(CFStringRef)UITrackingRunLoopMode(CFRunLoop)/UITrackingRunLoopMode(NSRunLoop) // 一般作用于ScrollView滚动的时候的模式，保证滑动的时候不受其他事件影响。
 
3、kCFRunLoopCommonModes（CFRunLoop）/NSRunLoopCommonModes（NSRunLoop）// 这个并不是某种具体的Mode，而是一种模式组合，在主线程中默认包含了NSDefaultRunLoopMode和 UITrackingRunLoopMode。子线程中只包含NSDefaultRunLoopMode

补充说明

Source是什么？

source就是【输入源事件】，分为source0和source1这两种

1、source0：诸如UIEvent（触摸，滑动等），performSelector这种需要手动触发的操作。
2、source1：处理系统内核的mach_msg事件（系统内部的端口事件）。诸如唤醒RunLoop或者让RunLoop进入休眠节省资源等

Timer是什么？

Timer即为【定时源事件】。通俗来讲就是我们很熟悉的NSTimer，其实NSTimer定时器的触发正是基于RunLoop运行的，所以使用NSTimer之前必须注册到RunLoop。

Observer是什么？

它相当于消息循环中的一个监听器，随时通知外部当前RunLoop的运行状态。

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

参考文档及更多资料

1、iOS RunLoop入门小结
2、iOS刨根问底-深入理解RunLoop
3、深入理解RunLoop
4、iOS-RunLoop充满灵性的死循环
5、RunLoop 总结：RunLoop的应用场景（一）
6、[iOS]浅谈NSRunloop工作原理和相关应用

关于autoreleasepool

1、自动释放池什么时候创建，什么时候销毁？
2、iOS中autoreleasepool的理解和使用
3、黑幕背后的Autorelease
4、关于iOS子线程上的autorelease对象释放问题?