iOS NSRunloop详解

2017-01-13 15:16:37来源:http://www.jianshu.com/p/296f182c8faa作者:huber人点击

什么是Runloop


Runloop即运行循环。为什么你的APP放在那里不去动它,在某个时间点去操作它,它还会给你反馈。就是因为Runloop的存在。
总结一下,因为Runloop的存在,保证你的程序不会死。


主要负责什么?
使程序一直运行并接受用户输入
决定程序在何时处理一些Event
调用解耦(Message Queue)
节省CPU时间(没事的时候闲着,有事的时候处理)
谁依赖NSRunloop
NSTimer
UIEvent
autorelease
NSObject(NSDelaydPerforming)
NSObject(NSThreadPerformAddtion)
CADisplayLink
CATransition
CAAnimation
dispatch_get_main_queue()
AFNetworking(NSURLConnection)
...

主线程几乎所有的函数都从以下的6个之1的调起


__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__

构成元素



Snip20160907_437.png

因为NSRunloop是对CFRunloop的封装,所以这里只看CFRunLoop就可以了。


CFRunLoopTimer的封装

系统提供的NSTimer、CADisplayLink、performSelector等都是对CFRunLoopTimer的封装。


CFRunLoopSource

Source是RunLoop的数据源抽象类(用OC的话来讲就是protocol)。
RunLoop定义了两个版本的Source,分别是Source0和Source1。


Source0:处理APP内部事件、APP自己负责管理(触发),如UIEvent、CFSocket
Source1:由RunLoop和内核管理,Mach Port驱动,如CFMachPort、CFMessagePort
CFRunLoopObserver

观察者,向外部报告RunLoop当前状态的更改


typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), // 即将退出Loop
};

框架中很多机制都由CFRunLoopObserver触发,比如CAAnimation
举例:


self.navigationController pushViewController:<#(nonnull UIViewController *)#> animated:<#(BOOL)#>

当程序执行完这行代码时,我们可以看到经历push动画之后,到达了一个新的界面。
但其实并不是执行完这行代码就出现了Push的动画。
其实,执行这段代码时不会立刻就掉push动画,而是要RunLoop循环一圈收集所有的Animation操作,汇集起来一起去调。


CFRunLoopObserver与AutoreleasePool


对象的释放并不是在{}括号结束。而是稍微延迟了一点。
堆栈如下:


_wrapRunLoopAutoreleasePoolHandler
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__

UIKit通过RunLoopOberser在RunLoop两次Sleep间对AutoreleasePool进行Pop和Push,将这次Loop产生的Autorelease对象释放。
也就是RunLoop跑一圈没事了就睡,被唤醒了再跑下一圈,在两次sleep之间对自动释放池进行释放。


CFRunLoopMode


注意

RunLoop在同一段时间只能且必须在一种特定Mode下Run。
更换Mode时,需要停止当前Loop,然后重启新Mode。
Mode是iOS滑动顺畅的关键。


类型
NSDefaultRunLoopMode
默认状态(空闲状态),比如点击按钮都是这个状态
UITrackingRunLoopMode
滑动时的Mode。比如滑动UIScrollView时。
UIInitializationRunLoopMode
私有的,APP启动时。就是从iphone桌面点击APP的图标进入APP到第一个界面展示之前,在第一个界面显示出来后,UIInitializationRunLoopMode就被切换成了NSDefaultRunLoopMode。

NSRunLoopCommonModes
它是NSDefaultRunLoopMode和UITrackingRunLoopMode的集合。结构类似于一个数组。在这个mode下执行其实就是两个mode都能执行而已。
典型的应用场景这样:当前界面有开启一个NSTimer,并且滑动UIScrollView。正常开启NSTimer后,滑动UIScrollView时它是不滑动的。解决办法就是把这个timer加入到当前的RunLoop,并把RunLoop的mode设置为NSRunLoopCommonModes。这样就可以保证不管你是NSDefaultRunLoopMode里跑,还是UITrackingRunLoopMode里跑,这个timer都可以执行。


self.timer = [NSTimer scheduledTimerWithTimeInterval:0.0625
target:self
selector:@selector(progressChange)
userInfo:nil
repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];

当你开始滑动UIScrollView时,RunLoop的mode状态变化如下:


NSDefaultRunLoopMode -> UITrackingRunLoopMode -> NSDefaultRunLoopMode

开始滑动时,第一次mode的切换会把NSDefaultRunLoopMode停掉。然后开启新的UITrackingRunLoopMode。当滑动停止时,由UITrackingRunLoopMode切换回NSDefaultRunLoopMode,这时UITrackingRunLoopMode被停止,又切换回了老的NSDefaultRunLoopMode(这个老的NSDefaultRunLoopMode应该是重新开始的)。



RunLoop和GCD的关系


RunLoop和GCD的关系,准确来说是只要使用了dispatch_get_main_queue(),就与RunLoop有了关系。


因为GCD中dispatch到main queue的block被分发到main RunLoop执行。


RunLoop的挂起和唤醒


我写了个demo,运行,然后点击debug栏的暂停,查看堆栈,如下:



Snip20160907_438.png

指定用于唤醒的mach_port接口
调用mach_msg监听唤醒端口,被唤醒前,系统内核将这个线程挂起,停留在mach_msg_trap状态
由另一个线程(或另一个进程中的某个线程)向内核发送这个端口的msg后,trap状态被唤醒,RunLoop继续开始干活。

RunLoop迭代执行顺序


伪代码:


SetupThisRunLoopRunTimeoutTimer();  //by GCD timer
do{
__CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
__CFRunLoopDoObservers(kCFRunLoopBeforeSources);
__CFRunLoopDoBlocks();
__CFRunLoopDoSource0();
CheckIfExistMessagesInMainDispatchQueue(); //GCD
__CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);
var wakeUpPort = SleepAndWaitForWakingUpPorts();
//mach_msg_trap
//Zzz...
//Received mach_msg , wake up
__CFRunLoopDoObservers(kCFRunLoopAfterWaiting);
//Handle msgs
if(wakeUpPort == timerPort){
__CFRunLoopDoTimers();
}else if(wakeUpPort == mainDispatchQueuePort) {
//GCD
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE_()
}else {
__CFRunLoopDoSource1();
}
__CFRunLoopDOBlocks();
}while(!stop && !timeout);

代码解读


//首先do..while循环不能是一个死循环,所以在这里设置一个过期时间
//这件事是GCD干的,用来检测do..while循环跑了多久
SetupThisRunLoopRunTimeoutTimer();
//开始跑循环
do{
//告诉observer我要跑timer了
__CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
//告诉observer我要跑source了
__CFRunLoopDoObservers(kCFRunLoopBeforeSources);
__CFRunLoopDoBlocks();
//程序跑到这里会查询Source0有什么消息
__CFRunLoopDoSource0();
//询问GCD你有没有存在主线程的东西需要我帮你调
CheckIfExistMessagesInMainDispatchQueue(); //GCD
//告诉observer我要睡了,RunLoop进入到挂起状态
__CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);
//进入trap状态,程序跑到这里就卡在这不动了,等待被某个Port唤醒
var wakeUpPort = SleepAndWaitForWakingUpPorts();
//被唤醒后,告诉observer我被唤醒了
__CFRunLoopDoObservers(kCFRunLoopAfterWaiting);
//假如是被timer唤醒的
if(wakeUpPort == timerPort){
//就去循环遍历和timer有关的回调
__CFRunLoopDoTimers();
}else if(wakeUpPort == mainDispatchQueuePort) {
//如果是主线程的GCD把我唤醒的,那RunLoop就知道GCD要让它做事了,然后就取调GCD的这些事件
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE_()
}else {
//如果都不是,就是Source1,Source1是基于Port事件的,比如网络某个端口来数据了,就会把RunLoop唤醒,去对来的数据进行处理
__CFRunLoopDoSource1();
}
__CFRunLoopDoBlocks();
}while(!stop && !timeout);
//判断条件:有没有被外部干掉 && 到了过期时间
//如果过期时间不手动进行设置的话,默认值是一个很大的值,可能是Int_Max

AFNetworking是如何玩转RunLoop的


+ (void)networkRequestThreadEntryPoint:(id)_unuserd object {
@autoreleasepool {
[[NSThread currentThread] setName:@"AFNetworking"];
//为了不让runloop run起来没事干导致消失
//所以给runloop加了一个NSMachPort,给它一个mode去监听
//实际上port什么也没干,就是让runloop一直在等,目的就是让runloop一直活着
//这是一个创建常驻服务线程的好方法
NSRunloop *runloop = [NSRunLoop currentRunLoop];
[runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runloop run];
}
}
+ (NSThread *)networkRequestThread {
static NSThread *_networkReuqestThread = nil;
static dispatch_once_t oncePredicate;
dispatch_once(&oncePredicate, ^{
_networkRequestThread =
[[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
[_networkRequestThread start];
});
return _networkRequestThread;
}

一个TableView延迟加载图片的新思路


以前是怎么解决的?
通过UITableView的代理方法,判断如果处于滑动状态就不去设置cell上的图片,如果没有处于滑动状态就取设置cell上的图片。


而现在通过Runloop就有一个十分简便的方法。


//在cell里面把设置图片的事情在NSDefaultRunloopMode里面去做。
//当主线程的tableview不再滑动的时候就会去设置图片
UIImage *dowloadImage = ...;
[self.iconImageView performSelector:@selector(setImage:) withObject:dowloadImage afterDelay:0 inModes:@[NSDefaultRunloopMode]];

这样去设置图片就简便了很多,不用再去判断tableview的代理方法。代码也会很清爽。




最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台