博客链接RunLoop面试题分析

更新于2019-07-29 完善AFNetworking常驻线程的作用

在重拾RunLoop原理中RunLoop的源码进行了分析，本该做一个总结方便以后查看，但是RunLoop中的知识点相对来说比较多，总结的东西就比较多。在面试中，又经常爱问一些RunLoop的知识点，接着就以我之前能回忆起来的面试题来对RunLoop做一个总结。

RunLoop的作用

RunLoop就是一种循环，它将运行的程序包裹起来。当没有事件时，RunLoop会进入休眠状态，有事件发生时，RunLoop会去找对应的Handler处理事件。RunLoop可以让线程在需要做事的时候忙起来，不需要的话就让线程休眠，一种让线程能随时处理事件但并不退出的机制。

RunLoop与线程之间的关系

RunLoop和线程之间是一一对应的，它们之间的关系保存在一个全局字典以及线程私有数据中；
在线程创建的时候，是没有对应的RunLoop，它的创建是在第一次获取的时候，它的销毁则发生在线程销毁的时候；

NSTimer在列表滑动时失效的原因和解决方法

NSTimer默认运行在RunLoop的kCFRunLoopDefaultMode下，在列表滑动的时候，RunLoop会切换UITrackingRunLoopMode，因为RunLoop只能运行在一种模式下，所以NSTimer不会执行回调。

使用[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];将timer添加到CommonModes中。它可以让timer运行在所有被标记为Common属性的Mode中，kCFRunLoopDefaultMode和UITrackingRunLoopMode默认都已经被标为”Common”属性的。

NSTimer不精准的理由

NSTimer定时器的触发是基于RunLoop运行的，所以使用NSTimer之前必须注册到RunLoop，但是RunLoop为了节省资源并不会在非常准确的时间点调用定时器。当RunLoop在处理比较复杂的任务时，可能会错过一个时间点，那么定时器只能等到下一个时间点执行，并不会延后执行。

NSTimer不精准的解决方法

使用GCDTimer作为定时器，它是基于硬件时间的，相对来说更精准一点；
开辟子线程中进行NSTimer的操作，再在主线程中修改UI界面显示操作结果，这么做相对于将NSTimer添加在主线程RunLoop来说是会提高精确度，但是如果说子线程的RunLoop也比较繁忙的话，那一样会带来误差；

RunLoop的mode和Common mode

Mode是RunLoop的运行模式，每个RunLoop需要运行在一个特定的Mode中。如果需要切换Mode，只能退出Loop，再重新指定一个Mode进入。不同组的source0/source1/observer/timer可以相互隔离，互不影响，从而提高执行效率。

常用的RunLoop的Mode

kCFRunLoopDefaultMode：App的默认Mode，通常主线程是在这个Mode下运行；
UITrackingRunLoopMode：界面跟踪Mode，用于滚动视图追踪触摸滑动，保证界面滑动时不受其他 Mode影响；
kCFRunLoopCommonModes：这是一个占位用的Mode，并不是一种真正的Mode；

Common mode并不是一个具体的Mode，它只是用来将Mode标记为Common属性。当source0/source1/observer/timer被添加到Common mode下的时候，意味着他们可以运行在所有被标记为Common属性的Mode中。

kCFRunLoopDefaultMode和UITrackingRunLoopMode默认就被标记了Common属性。

RunLoop响应用户操作

以按钮点击触发事件为例，点击屏幕的时候，首先系统内部捕获到这个点击事件，这是在Source1中处理的，Source1会包装成事件丢到事件队列中，交给Source0处理。

RunLoop与UI刷新

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

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

RunLoop与AutoreleasePool

在程序启动之后，主线程会创建一个Runloop，也会创建两个Observer，回调工作都是在_wrapRunLoopWithAutoreleasePoolHandler函数中。

第一个Observer监听的是Entry（即将进入Loop），回调是在_objc_autoreleasePoolPush()中创建自动释放池的，优先级是最高的，保证创建释放池是在所有回调之前。

第二个Observer监听有两个事件：BeforeWaiting（进入休眠）时调用_objc_autoreleasePoolPop和_objc_autoreleasePoolPush释放旧的释放池以及创建新的释放池；Exit（退出Loop）调用_objc_autoreleasePoolPop来释放自动释放池。这个优先级是最低的，保证释放池发生在所有回调之后调用。

实现线程保活/控制线程生命周期

首先需要知道线程一般执行完任务后，就会被销毁；
为什么说使用了Runloop就可以实现线程保活。添加runloop并运行起来，实际上是添加了一个循环，这样这个线程的程序一直卡在这个循环上，这样相当于线程的任务一直没有执行完，所以线程一直不会销毁；
如何销毁这个线程？停止runloop，可以使用CFRunLoopStop函数。

在AFNetworking2.x中便是利用runloop实现线程保活的。代码如下：

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

接着自己控制线程的生命周期

@interface TestThreadViewController ()

@property (nonatomic, strong) TestThread *thread;

@end

@implementation TestThreadViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    self.view.backgroundColor = UIColor.whiteColor;
    
    __weak __typeof(self) weakSelf = self;
    
    // 这里有个问题要注意: 线程内部会对target造成一个强引用
    // 使用Block形式的API
    self.thread = [[TestThread alloc] initWithBlock:^{
        NSLog(@"%s -----beigin-----", __func__);
        
        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        // 添加一个Source1
        [runLoop addPort:[NSPort port] forMode:NSDefaultRunLoopMode];
        // 调用runloop run, 则runloop就不能被停止，其内部是在不断调用runMode:beforeDate:
        // 不能调用[runLoop run];
        
        while (weakSelf) {
            [runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
        }
        
        NSLog(@"%s -----end-----", __func__);
    }];
    
    [self.thread start];
    
    UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];
    button.frame = CGRectMake(100, 100, 30, 20);
    button.backgroundColor = UIColor.redColor;
    [self.view addSubview:button];
    [button addTarget:self action:@selector(_didButtonPressed:) forControlEvents:UIControlEventTouchUpInside];
}

- (void)dealloc {
    NSLog(@"%@ dealloc", self.class);
    
    // 下面的代码就是说在子线程中执行threadStop方法
    // 这里要注意waitUntilDone的用法
    // 如果传入NO，该方法会直接返回执行后续的代码，这样会出现问题
    // 如果传入YES，代表必须等到子线程执行完threadStop方法才能执行后面的代码
    [self performSelector:@selector(threadStop)
                 onThread:self.thread
               withObject:nil
            waitUntilDone:YES];
}

- (void)_didButtonPressed:(id)sender {
    NSLog(@"开始销毁页面");
    [self dismissViewControllerAnimated:YES completion:nil];
}

#pragma mark - 线程保活

- (void)threadPerformingTasks {
    NSLog(@"%@ %s", [NSThread currentThread], __func__);
}

- (void)threadStop {
    CFRunLoopStop(CFRunLoopGetCurrent());
    NSLog(@"%s", __func__);
}

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    NSLog(@"触发点击事件");
    [self performSelector:@selector(threadPerformingTasks)
                 onThread:self.thread
               withObject:nil
            waitUntilDone:NO];
}

@end

执行结果：

RunLoop与NSURLConnection

NSURLConnection目前来说应该很少会被问到了，其底层会使用CFSocket去发送和接收请求，在发送和接收的一些事件发生后通知原来线程的Runloop去回调事件。

这道题可以说是在RunLoop的范畴，但是它更像是AFNetworking2.x为什么使用线程保活的解答，只是内部使用RunLoop技术去解决问题。

首先需要在子线程去开始连接，请求发送后，所在的子线程需要保活以保证正常接收到 NSURLConnectionDelegate回调方法。如果每来一个请求就开一条线程，并且保活线程，这样开销太大了。所以只需要保活一条固定的线程，在这个线程里发起请求、接收回调。

这里要注意一点：虽然使用了一条固定的线程，但是网络请求并不是单线程的，网络请求会放在一个并发队列里，是多线程的。请求返回后通知常驻线程，再通过常驻线程通知主线程。

涉及到RunLoop的相关API

以下代码的输出结果

- (void)viewDidLoad {
    [super viewDidLoad];
    NSInteger number = 1;
    NSLog(@"%zd", number);
    
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    dispatch_async(queue, ^{
        [self performSelector:@selector(printString) withObject:nil afterDelay:0];
    });
    
    number = 3;
    NSLog(@"%zd", number);
}

- (void)printString {
    NSLog(@"sdasdas");
}

结果：1 3

NSObject的performSelecter:afterDelay:或者performSelector:onThread:这样类似的方法被调用时，都依赖于RunLoop。子线程默认不启用RunLoop的，所以不会执行Selector中传入的方法。除非说API内部启用了RunLoop。比如调用performSelector:onThread:withObject:waitUntilDone:方法，waitUntilDone:传YES的时候，内部会自己启动RunLoop。

解决方法：

dispatch_async(queue, ^{
    [self performSelector:@selector(printString) withObject:nil afterDelay:0];
    
    NSRunLoop *runloop = [NSRunLoop currentRunLoop];
    [runloop run];
});

RunLoop的运行过程/内部实现

将下面这张图深深地刻在自己的骨子里

RunLoop的休眠实现

当RunLoop一旦休眠意味着CPU不会分配任何资源，那线程也进入休眠。RunLoop休眠内部是调用了mach_msg()函数。操作系统中有内核层面的API和应用层面的API。mach_msg()可以理解为是应用层面的API，告诉内核休眠该线程休眠。一旦接受到系统事件，也会转化成内核API，告诉内核需要唤醒该线程，那么又可以执行应用层API了。所以RunLoop的休眠可以看成是用户状态到内核状态的切换，而唤醒RunLoop就是内核状态到用户状态的切换。