RunLoop 学习及常见问题

2017-05-03 本文已影响361人花与少年_

什么是 RunLoop

通常在终端中输入命令，执行任务的线程执行完就退出了，等我们再次输入命令，终端再开始执行任务。但在我们的 app 中，要保持一直运行(除非app被挂起)，不断接受用户的输入，循环的接受、处理事件，类似于这样：

while(AppIsRunning){  //只要 app 处于运行状态，就要不断等待着处理事件
    id whoWakesMe = SleepForWakingUp();
    id event = GetEvent(whoWakesMe);
    HandleEvent(event);
}

RunLoop 来帮助线程管理一个或多个事件或消息，接受用户输入等事件源，在事件到达时，RunLoop 立刻唤醒线程来处理事件；没有事件需要处理时，RunLoop 帮助线程休眠，避免其占用资源，这里是帮助其休眠，而不是直接退出。
RunLoop 还决定了程序在何时应该处理那些事件，并且为被调用的对象维护一个消息队列，被调用方从这个消息队列中取出需要他处理的事件。

主线程的 RunLoop 默认开启，而子线程需要调用[NSRunLoop currentRunLoop]创建和获取 RunLoop，RunLoop 的销毁发生在线程结束时。

RunLoop 与线程的关系
每个线程创建的时候，都有一个 RunLoop 循环，与线程一一对应。

RunLoop 构成

RunLoop构成

如图可以看到 RunLoop 的大致构成，它与线程一一对应，而拥有多个CFRunLoopMode，mode 是一系列输入事件源、计时器、runLoop 观察者的集合。

RunLoop Mode

RunLoop 只能选择一个 Mode 启动，同时在“跑”的时候，总是在特定的唯一的 mode 下，每次运行 RunLoop 都要显式或隐式的指定运行 mode。这个 mode 包含了当前需要处理的 Source/Timer/Observer，所以 RunLoop 在时刻内，仅能处理与当前 mode 相关联的事件，只有和模式相关的源才会被监视，并允许他们传递事件消息。

为了保证其中的 Source/Timer/Observer 与其他 mode 的相隔离，切换 mode 时，只能先退出当前RunLoop，再以要切换的 mode 重新进入RunLoop。

开发中，通常会遇到这几种Mode：

kCFRunLoopDefaultMode：app的默认 Mode，通常主线程在这个 Mode 下运行。
UITrackingRunLoopMode：界面跟踪 Mode，ScrollView 的触摸滑动 mode (在iOS中，触摸滑动很流畅的原因是在滑动时，只处理此 mode 下的事件且不受其他mode影响)。
UIInitializationRunLoopMode：刚启动 app 进入的第一个 mode，起到过渡的作用，启动完成后不再使用。
GSEventReceiveRunLoopMode: Graphic 相关事件的 mode，通常用不到。
kCFRunLoopCommonModes：将 mode 标记为"common"属性，当 RunLoop 运行在标记为"common"属性的任一 mode 下，发生事件时，里面的 mode 都会被触发。

RunLoop Source

线程的异步事件源，数据源。有两种Source，可以用是否基于Mach Port(进程间通讯接口)区分：

source0：不基于Mach Port，处理app内部事件，用户自定义的thread发出。当我们使用 NSObject 中的 performSelector 系列方法时，都是source0 事件源。
source1：基于Mach Port，是由RunLoop和内核管理的。

RunLoop Timer

线程的同步事件源，在预设的时间点到了之后同步的发给线程处理此事件。

RunLoop Observer

Observer 可对 RunLoop 的状态变化进行观察，可观察的变化：

刚进入此 RunLoop 中
RunLoop 准备处理一个 Timer
RunLoop 准备处理一个 Input Source
RunLoop 准备进入睡眠
RunLoop 将被唤醒处理事件之前
RunLoop 准备退出

因为Observer可对这些事件进行观察追踪，所以也可被看作是一种事件源。

RunLoop处理的流程

RunLoop_1.png

第7步中，当线程进入休眠，发生下列事件，线程将被唤醒：

基于 Port 的事件发生
计时器到时
被代码显式唤醒

第9步中，处理唤醒时收到的消息，并且：

如果是用户定义的计时器到时，处理事件并重启 RunLoop
如果有input 事件源，传递这个消息
如果runloop显式被唤醒，且没有超时，重启RunLoop
之后，跳回第2步

RunLoop应用举例

在漫长长长长的理论说明后，让我们看看实际开发中，有哪些地方会用到 RunLoop 呢？

解决 NSTimer "不准"的问题

我们有时候会发现 NSTimer "不太准"，明明时间已经到了，该执行的回调却未发生，这是因为我们常常将 NSTimer 默认设置为default mode，如果这时屏幕滚动，mode切换为TrackingMode，时间到了，但是 TrackingMode 无法处理 defaultMode下的回调，造成"不准"。
在 SVProgressHUD 中，我们可以设置转圈的提示框自动消失，可开启一个定时器，在到了设定的时间点后消失，如下

strongSelf.fadeOutTimer = [NSTimer timerWithTimeInterval:duration target:strongSelf selector:@selector(dismiss) userInfo:nil repeats:NO];
[[NSRunLoop mainRunLoop] addTimer:strongSelf.fadeOutTimer forMode:NSRunLoopCommonModes];

strongSelf 即为提示框，将它消失的定时器添加在 RunLoop 的common 模式下，不管时间点到了的那一时刻 RunLoop 运行在哪个mode下，都会处理消失的回调，"准点消失"。

用 dispatch_after 定时，就准了吗
我发现有很多博客写，NSTimer 造成定时不准的问题可以通过 GCD 中的 dispatch_after 来解决，但是 dispatch_after 并不是说在指定时间后执行处理，而只是在指定时间将操作追加到 Dispatch Queue 中。如果指定时间到了，需要加入的队列正在进行耗时操作，定时操作并不能立即执行，也会造成不准。
验证如下：

    //获取主队列
    dispatch_queue_t mainQueue = dispatch_get_main_queue();
    //定时时间
    int64_t delay = 5 * NSEC_PER_SEC;
    //定时时间，即从现在到定时的时间
    dispatch_time_t delayTime = dispatch_time(DISPATCH_TIME_NOW, delay);

    NSLog(@"开始计时: %@", [NSDate date]);

    dispatch_after(delayTime, mainQueue, ^{
        NSLog(@"时间到: %@", [NSDate date]);
    });

    //在这里设置一些复杂操作，比方来10000次网络请求

可以看到虽然我们只设置延迟5秒进行，但事实上，在10秒才进行了延迟操作。但是日常的开发中，碰到这么这么复杂的情况应该是比较少的，所以 dispatch_after 也可以一用~~~
GCD 中除了主要的 Dispatch Queue 之外，还对 BSD 系内核惯有功能 kqueue 进行包装，可处理内核中发生的各种事件及方法。
其中的 DISPATCH_SOURCE_TYPE_TIMER 可作为定时器，帮助我们延迟调用：


    //获取主队列
    dispatch_queue_t mainQueue = dispatch_get_main_queue();
    //新生成一个定时器，且此定时器不能为局部变量，否则方法执行完就被销毁了，还怎么做定时后的回调呢？
    self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, mainQueue);
    //定时时间
    int64_t delay = 5 * NSEC_PER_SEC; 
    //一定容差范围时间
    int64_t leeway = 0.1 * NSEC_PER_SEC; 
    //定时时间，即从现在到定时的时间
    dispatch_time_t delayTime = dispatch_time(DISPATCH_TIME_NOW, delay);

    //设置定时器
    //下一次回调为DISPATCH_TIMER_FOREVER，表示不需要重复
    dispatch_source_set_timer(self.timer, delayTime,DISPATCH_TIMER_FOREVER, leeway);

    //设置时间到了后的回调
    __weak typeof(self) weakSelf = self;
    dispatch_source_set_event_handler(self.timer, ^{
        typeof(self) strongSelf = weakSelf;
        NSLog(@"计时结束: %@", [NSDate date]);
        dispatch_source_cancel(strongSelf.timer);
    });

    //启动定时器
    dispatch_resume(self.timer);

保证线程的持续运行

在 AFNetworking 2.3 中，需要一个自定义线程接受 connection 回调，一开始初始化线程时，没有需要执行的操作，线程会退出(RunLoop中没有source/timer/observer 会立即退出)。为其添加一个MachPort，为了保证线程的存活。

+ (NSThread *)networkRequestThread {
    static NSThread *_networkRequestThread = nil;
    static dispatch_once_t oncePredicate;
    dispatch_once(&oncePredicate, ^{
        //初始化线程时，调用networkRequestThreadEntryPoint方法
        _networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
        [_networkRequestThread start];
    });
    return _networkRequestThread;
}

+ (void)networkRequestThreadEntryPoint:(id)__unused object {
    @autoreleasepool {
        [[NSThread currentThread] setName:@"AFNetworking"];
        //为线程创建RunLoop
        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        //为RunLoop添加事件，保证其持续运行
        [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode]; 
        [runLoop run];
    }
}

解决TableView加载图片时，滑动很卡

TableView 需要加载大量图片时，滑动后，界面会卡，这是因为此时RunLoop 运行在 UITrackingRunLoopMode 下，图片加载在当前mode下，cpu 又要处理加载图片事件，又要处理滑动事件，造成卡顿。
可以显式地将图片的加载设置在 NSDefaultRunLoopMode 下，滑动时的 UITrackingRunLoopMode 并不会去加载图片，解决卡顿问题。

[self.imageView performSelector:@selector(setImage:) withObject:downloadImage afterDelay:0 inModes:@[NSDefaultRunLoopMode]];

自动释放池到底在何时释放？

我们知道，手动指定 autoreleasepool 中的对象，会在作用域结束时释放掉。而设置为 autorelease 的对象是在出了作用域之后，被自动添加到最近创建的自动释放池中。那么这个自动释放池迟早有被撑满需要释放的时刻，这个自动释放池具体是什么时候被释放呢？

在Cocoa框架中，相当于程序主循环的NSRunLoop或者在其他程序可运行的地方，对 NSAutoreleasePool 对象进行生成、持有和废弃处理。
---引自《Objective-C 高级编程》
而它能够释放的原因是系统在每个 runloop 迭代中都加入了自动释放池 Push 和 Pop

下面我们举例讨论下：

@property (nonatomic,weak)NSString * weakStr;

- (void)viewDidLoad {
        [super viewDidLoad];
        NSString *string = [NSString stringWithFormat:@"这个string要设置的很长长长长长长长长长长长长长长长长"];
        //因为苹果引用Tagged Pointer专门存储小的对象，直接存储其值，而不是存储地址
        //如果string很短，用Tagged Pointer存储，无法验证其自动释放，地址被收回的过程
        weakStr = string;

        NSLog(@"viewDidLoad:%@",weakStr);
        NSLog(@"currentRunLoop:%@",[[NSRunLoop currentRunLoop] currentMode]);
}

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
    NSLog(@"viewWillAppear:%@",weakStr);
    NSLog(@"currentRunLoop:%@",[[NSRunLoop currentRunLoop] currentMode]);
}
- (void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];
    NSLog(@"viewDidAppear:%@",weakStr);
    NSLog(@"currentRunLoop:%@",[[NSRunLoop currentRunLoop] currentMode]);
}

输出如图：

在mode改变,RunLoop一次循环结束后,autorelease对象被销毁

观察 weakStr 设置方法何时被调用

在viewWillAppear调用结束后，左边的堆栈中出现了一次AutoreleasePoolPage pop操作

我们在viewDidLoad方法中，用stringWithFormat类方法生成一个字符串，这种方法生成的字符串默认被添加进 autoreleasepool 中。
viewDidLoad 和 viewWillAppear 还在app初始化的 UIInitializationRunLoopMode 下，而 viewDidAppear 已经进入了默认mode下了。期间，autoreleasepool 出现了一次销毁，其中的对象也就被销毁了。
所以说，在没有手加Autorelease Pool的情况下，Autorelease对象是在当前的runloop迭代结束时释放的，而它能够释放的原因是系统在每个runloop迭代中都加入了自动释放池Push和Pop。

关于RunLoop的一道题
NSRunLoop 的描述正确的是( )
A. RunLoop 决定程序在何时应该处理哪些 Event
B. Cocoa 中的 NSRunLoop 类并不是线程安全的
C. RunLoop 可以使程序一直运行接受用户输入
D. RunLoop 起到了调用解耦的作用
我怎么觉得 ABCD 四个选项都对嘞……

参考文章：
RunLoops 官方文档
 深入理解RunLoop
黑幕背后的Autorelease
Objective-C Autorelease Pool 的实现原理
 RunLoop个人小结