阅读 1400

RunLoop面试题分析

博客链接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中,kCFRunLoopDefaultModeUITrackingRunLoopMode默认都已经被标为”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中。

kCFRunLoopDefaultModeUITrackingRunLoopMode默认就被标记了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与UI刷新

RunLoop与AutoreleasePool

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

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

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

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

  1. 首先需要知道线程一般执行完任务后,就会被销毁;
  2. 为什么说使用了Runloop就可以实现线程保活。添加runloop并运行起来,实际上是添加了一个循环,这样这个线程的程序一直卡在这个循环上,这样相当于线程的任务一直没有执行完,所以线程一直不会销毁;
  3. 如何销毁这个线程? 停止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控制线程生命周期

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_run

RunLoop的休眠实现

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