更新于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中Source0和Source1的区别
Source0
并不能主动触发事件。使用时,你需要先调用CFRunLoopSourceSignal
,将这个Source标记为待处理,然后手动调用CFRunLoopWakeUp
来唤醒RunLoop,让其处理这个事件。
Source1
能主动触发事件。其中它有一个mach_port_t
,mach_port是用于内核向线程发送消息的。
使用Source0
的情况:
- 触摸事件处理;
- 调用
performSelector:onThread:withObject:waitUntilDone:
方法;
使用Source1
的情况:
- 基于端口的线程间通信(A线程通过端口发送消息到B线程,这个消息是
Source1
的; - 系统事件的捕捉,先触发是
Source1
,接着分发到Source0
去处理。
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实现线程保活的。代码如下:
1 | + (NSThread *)networkRequestThread { |
接着自己控制线程的生命周期
1 | @interface TestThreadViewController () |
执行结果:
RunLoop与NSURLConnection
NSURLConnection
目前来说应该很少会被问到了,其底层会使用CFSocket
去发送和接收请求,在发送和接收的一些事件发生后通知原来线程的Runloop
去回调事件。
这道题可以说是在RunLoop的范畴,但是它更像是AFNetworking2.x为什么使用线程保活的解答,只是内部使用RunLoop技术去解决问题。
首先需要在子线程去开始连接,请求发送后,所在的子线程需要保活以保证正常接收到 NSURLConnectionDelegate回调方法。如果每来一个请求就开一条线程,并且保活线程,这样开销太大了。所以只需要保活一条固定的线程,在这个线程里发起请求、接收回调。
这里要注意一点:虽然使用了一条固定的线程,但是网络请求并不是单线程的,网络请求会放在一个并发队列里,是多线程的。请求返回后通知常驻线程,再通过常驻线程通知主线程。
涉及到RunLoop的相关API
以下代码的输出结果
1 | - (void)viewDidLoad { |
结果:1 3
NSObject的performSelecter:afterDelay:
或者performSelector:onThread:
这样类似的方法被调用时,都依赖于RunLoop。子线程默认不启用RunLoop的,所以不会执行Selector
中传入的方法。除非说API内部启用了RunLoop。比如调用performSelector:onThread:withObject:waitUntilDone:
方法,waitUntilDone:
传YES的时候,内部会自己启动RunLoop。
解决方法:
1 | dispatch_async(queue, ^{ |
RunLoop的运行过程/内部实现
将下面这张图深深地刻在自己的骨子里
RunLoop的休眠实现
当RunLoop一旦休眠意味着CPU不会分配任何资源,那线程也进入休眠。RunLoop休眠内部是调用了mach_msg()
函数。操作系统中有内核层面的API和应用层面的API。mach_msg()
可以理解为是应用层面的API,告诉内核休眠该线程休眠。一旦接受到系统事件,也会转化成内核API,告诉内核需要唤醒该线程,那么又可以执行应用层API了。所以RunLoop的休眠可以看成是用户状态到内核状态的切换,而唤醒RunLoop就是内核状态到用户状态的切换。