Runloop底层原理

·  阅读 965

1.runloop是什么?

runLoop是一个接收处理异步消息事件的循环,一个循环中:等待事件发生,然后将这个事件送到能处理它的地方.从源码也可以看出,本质上是一个do-while循环。


2.runloop的作用?

2.1.保持程序的持续运行

我们知道程序是从main函数开始运行的,入下所示。如果直接return 0运行会发现程序打开一瞬间就结束了,而UIApplicationMain会启动主线程的runloop,从而保证程序在没有任务执行时可以持续运行。

int main(int argc,char* argv[]) {   @autoreleasepool {        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));    }}


2.2.处理APP中的各种事件(触摸、定时器、performSelector等)

我们在vc中写入以下测试代码,断点调试查看堆栈信息,可以发现触发执行了runloop,并且回调了__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__,进而向上触发viewcontroller的touchbegan方法。


同理,我们可以再写一个定时器代码,用同样的方式可以发现也执行了runloop,并且回调了__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__。


在主线程下,几乎所有的都是从以下6个函数调起:

CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION

CFRunloop is calling out to an abserver callback function

用于向外部报告 RunLoop 当前状态的更改,框架中很多机制都由 RunLoopObserver 触发,如 CAAnimation

CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK

CFRunloop is calling out to a block

消息通知、非延迟的perform、dispatch调用、block回调、KVO

CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE

CFRunloop is servicing the main desipatch queue

主线程回调

CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION

CFRunloop is calling out to a timer callback function

延迟的perform, 延迟dispatch调用

CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION

CFRunloop is calling out to a source 0 perform function

处理App内部事件、App自己负责管理(触发),如UIEvent、CFSocket。普通函数调用,系统调用

CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION

CFRunloop is calling out to a source 1 perform function

由RunLoop和内核管理,Mach port驱动,如CFMachPort、CFMessagePort


2.3 节省cpu资源、提供程序的性能:该做事就做事,该休息就休息

我们在main函数里做如下实验,观察CPU的消耗情况可以发现,runloop启动休眠时是几乎不消耗CPU的,只有在需要它做事情的时候才会唤醒。而while循环一直在消耗CPU的性能。



3.runloop和线程的关系?

每一个RunLoop都与一个线程关联着。确切的说,是先有线程,再有RunLoop。

关于线程与RunLoop的关系,在RunLoop官方文档的第一节讲的很清楚。

我们不用,也最好不要显示的创建RunLoop,苹果提供了两个API,便于我们来获取RunLoop。

CFRunLoopGetMain()和CFRunLoopGetCurrent(),分别用于获取MainRunLoop和当前线程的RunLoop。

先来看一下,这两个函数的源码实现:


从以上源码,可以看出RunLoop 是通过_CFRunLoopGet0函数来获取的,并且以线程作为参数。

接下来,看一下_CFRunLoopGet0的实现


大致过程,获取某个线程的RunLoop,首先以 线程作为key,从全局字典中找,如果没找到,则新建一个,并以线程为key,RunLoop为Value 存到全局字典中(如果全局字典不存在,就先初始化全局字典,并新建一个MainRunLoop 保存到全局字典中)

所以我们可以得出结论,runloop与线程是一一对应的。

4. runloop对象和mode?

通过:

NSLog(@"%@", [NSRunLoop mainRunLoop]);可以对 RunLoop 内部一览无余。

RunLoop 想要跑起来,必须有 Mode 对象支持,而 Mode 里面必须有:(NSSet *)Source、 (NSArray *)Timer ,源和定时器,我们引用一张经典的图片


结合CFRunloop和CFRunLoopMode的结构体:



可以得出如下结论:每个 RunLoop 都包含若干个 Mode ,每个 Mode 又包含若干个 Source/Timer/Observer。

每次 RunLoop 启动时,只能指定其中一个 Mode,这个 Mode 被称作CurrentMode,如果需要切换 Mode,只能退出 Loop,再重新指定一个 Mode 进入,这样做主要是为了分隔开不同组的 Source/Timer/Observer,让其互不影响(可以通过切换 Mode,完成不同的 timer/source/observer。


系统默认注册了5个Mode:

NSDefaultRunLoopMode:App 的默认 Mode,通常主线程是在这个 Mode 下运行(默认情况下运行)

UITrackingRunLoopMode:界面跟踪 Mode,用于 ScrollView 追踪触摸滑动,保证界面滑动时不受其他 Mode 影响(操作 UI 界面的情况下运行)

UIInitializationRunLoopMode:在刚启动 App 时进入的第一个 Mode,启动完成后就不再使用

GSEventReceiveRunLoopMode:接受系统事件的内部 Mode,通常用不到(绘图服务)

NSRunLoopCommonModes:这是一个占位用的 Mode,不是一种真正的 Mode (RunLoop无法启动该模式,设置这种模式下,默认和操作 UI 界面时线程都可以运行,但无法改变 RunLoop 同时只能在一种模式下运行的本质)

下面主要区别 NSDefaultRunLoopMode 和 UITrackingRunLoopMode 以及 NSRunLoopCommonModes。请看以下代码:

- (void)viewDidLoad {   

[super viewDidLoad];

NSTimer *timer = [NSTimer timerWithTimeInterval:2.0 target:self selector:@selector(run) userInfo:nil repeats:YES];
// 在默认模式下添加的 timer 当我们拖拽 textView 的时候,不会运行 run 方法    [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];

// 在 UI 跟踪模式下添加 timer 当我们拖拽 textView 的时候,run 方法才会运行    [[NSRunLoop currentRunLoop] addTimer:timer forMode:UITrackingRunLoopMode];

// timer 可以运行在两种模式下,相当于上面两句代码写在一起   

[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];}

- (void)run{

    NSLog(@"--------run");

}

[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];

[self performSelectorOnMainThread:@selector(run) withObject:nil waitUntilDone:YES modes:@[UITrackingRunLoopMode]];

[self performSelectorOnMainThread:@selector(run) withObject:nil waitUntilDone:YES modes:@[NSRunLoopCommonModes]];


CFRunLoopTimerRef

CFRunLoopTimerRef 是基于事件的触发器

CFRunLoopTimerRef 基本上就是 NSTimer,它受 RunLoop的Mode 影响

创建 Timer 有两种方式,下面的这种方式必须手动添加到 RunLoop 中去才会被调用

// 这种方式创建的timer 必须手动添加到RunLoop中去才会被调用

NSTimer *timer = [NSTimer timerWithTimeInterval:2.0 target:self selector:@selector(time) userInfo:nil repeats:YES];

[[NSRunLoop currentRunLoop] addTimer:timerforMode:NSDefaultRunLoopMode];

// 同时让RunLoop跑起来

[[NSRunLoop currentRunLoop] run];

而通过 scheduledTimer 创建 Timer 一开始就会自动被添加到当前线程并且以NSDefaultRunLoopMode 模式运行起来,代码如下:

[NSTimer scheduledTimerWithTimeInterval:2.0 target:self selector:@selector(run) userInfo:nil repeats:YES];

/* 注意:调用了 scheduledTimer 返回的定时器,已经自动被添加到当前runLoop 中,而且是 NSDefaultRunLoopMode ,想让上述方法起作用,必须先让添加了上述 timer的RunLoop 对象 run 起来,通过scheduledTimerWithTimeInterval 创建的 timer 可以通过以下方法修改 mode*/

[[NSRunLoop currentRunLoop] addTimer:timer2 forMode:UITrackingRunLoopMode];

注意: GCD的定时器不受RunLoop的Mode影响

CADisplayLink *display = [CADisplayLink displayLinkWithTarget:self selector:@selector(run)];/* 注意:CADisplayLink ,也是在 Runloop 下运行的,有一个方法可以将CADisplayLink 对象添加到一个 Runloop 对象中去*/[display addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];

CFRunLoopSourceRef

CFRunLoopSourceRef 其实是事件源(输入源)

按照官方文档,Source的分类

Port-Based Sources:基于端口的:跟其他线程进行交互的,Mac内核发过来一些消息

Custom Input Sources:自定义输入源

Cocoa Perform Selector Sources(self performSelector:...)

按照函数调用栈,Source的分类

Source0:非基于Port的(触摸事件、按钮点击事件)

Source1:基于Port的,通过内核和其他线程通信,接收分发系统事件

(触摸硬件,通过 Source1 接收和分发系统事件到 Source0 处理)

为了搞清楚,Source 是如何通过函数调用栈来传递事件的,我们做如下实验:


我们可以看到,从程序启动 start 开始,函数调用栈在监听到事件点击后,会一路往下,一直到 -buttonClick: 方法,中间会经过 CFRunLoopSource0 ,这说明我们的按钮点击事件是属于 Source0 的。

而 Source1 是基于 Port 的,就是说,Source1 是和硬件交互的,触摸首先在屏幕上被包装成一个 event 事件,再通过 Source1 进行分发到 Source0,最后通过 Source0 进行处理。


我们可以自定义一个source(只能自定义source0,source1由系统内核触发):


CFRunLoopObserverRef

CFRunLoopObserverRef 是观察者,能够监听 RunLoop 的状态改变,主要监听以下几个时间节点:

/* Run Loop Observer Activities */

typedefCF_OPTIONS(CFOptionFlags, CFRunLoopActivity)

{   

kCFRunLoopEntry = (1UL <<0),// 1 即将进入 Loop   

kCFRunLoopBeforeTimers = (1UL <<1),// 2 即将处理 Timer    kCFRunLoopBeforeSources = (1UL <<2),// 4 即将处理 Source    kCFRunLoopBeforeWaiting = (1UL <<5),// 32 即将进入休眠   

kCFRunLoopAfterWaiting = (1UL <<6),// 64 刚从休眠中唤醒   

kCFRunLoopExit = (1UL <<7),// 128 即将退出 Loop   

kCFRunLoopAllActivities =0x0FFFFFFFU// 监听所有事件

};

// 1.创建观察者 监听 RunLoop

// 参1: 有个默认值 CFAllocatorRef :CFAllocatorGetDefault()
// 参2: CFOptionFlags activities 监听RunLoop的活动 枚举 见上面

// 参3: 重复监听 Boolean repeats YES

// 参4: CFIndex order 传0

CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities,YES,0, ^(CFRunLoopObserverRef observer,CFRunLoopActivity activity) {

// 该方法可以在添加timer之前做一些事情,  在添加source之前做一些事情NSLog(@"%zd", activity);});

// 2.添加观察者,监听当前的RunLoop对象CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);

// CF层面的东西 凡是带有create、copy、retain等字眼的函数在CF中要进行内存管理CFRelease(observer);

通过打印可以观察的 RunLoop 的状态



5.runloop源码分析

以timer为例,我们来看一下timer加入到某一个runloopMode的items的源码:


加入完,再看一下runloopRun的源码:


执行CFRunloopRun前 先通知observer进入runloop:kCFRunLoopEntry,结束后通知observer退出runloop:kCFRunLoopExit。下面CFRunLoopRun的源码 删了很多,只留下了简单的流程,跟上面runloop的流程图片一样:


再看一下具体__CFRunLoopDoBlocks执行代码:可以看到是从mode的items里面循环取出每一个add进去的item(mode里的items由前面通过addTimer加入,当然也可以addObserver、addSource,这里是拿timer举例):如果满足执行条件doit,就去触发__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__回调。


所以我们可以得出结论,无论是timer或者observer或者source,都需要先add进runloop的items,才能在runloop run的时候执行。

分类:
iOS
标签:
分类:
iOS
标签: