博客链接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就是内核状态到用户状态的切换。
