iOS 开发之RunLoop

概念

RunLoop 就像她的名字一样，就是跑环，就是一个死循环。是一个可以随时休眠，随时唤醒的死循环。

那么一个手机App为什么会一直运行？而且在接受到用户点击的时候，会做出反应？这些都离不开RunLoop。

iOS App启动的时候，就会自动启动一个RunLoop。一直在循环监听着用户的各种操作，并作出反应。每个线程都有一个RunLoop，但是，只有主线程的RunLoop是默认开启的。可以这样理解：

1. RunLoop 是iOS消息机制的处理模式

NSRunLoop的主要作用：控制NSrunLoop里面的线程的执行和休眠，在有事做的时候，使当前的RunLoop控制线程工作，没事做的时候让当前的NS RunLoop控制线程休息。

2.NSRunLoop就是一只在循环检测，从线程start到线程的end，检测inputSource(点击，双击等操作)同步事件，检测timeSource(计时器)同步操作。检测到输入源会执行处理函数，首先会产生通知，corefunction向线程添加runloop observers来监听事件，意在监听事件发生时来做处理。

iOS main函数中的RunLoop

int main(int argc, char * argv[]) {

    @autoreleasepool {

        //一旦程序启动会开启一个RunLoop 一直循环监听用户的点击事件 触摸事件 定时器事件等 并且一直不会返回。
　　　　　　保证程序一直运行，直到程序结束。这个默认的RunLoop就是跟主线程相关的。

        int rs =  UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

        return rs;

    }

}

iOS中RunLoop对象。

iOS中有两套API来访问和使用RunLoop

一套是 Foundation -> NSRunLoop oc封装的

一套是 Core Foundtion ->CFRunLoopRef C语言调用

但是这两套API 是等价的，NSRunLoop就是基于CFRunLoopRef的一层OC包装。所以要研究NSRunLoop还是要研究CFRunLoopRef 。

RunLoop和线程的关系

1. 每条线程都有唯一的一个与之对应的RunLoop对象

2. 主线程的RunLoop已经自动创建好了，自线程的RunLoop需要自动创建

3. RunLoop在第一次获取时创建，在线程结束的时销毁。

RunLoop中的相关类

1.CFRunLoopRef

2.CFRunLoopModeRef RunLoop模式

3.CFRunLoopSourceRef 事件源输入源

4.CFRunLoopTimerRef

5.CFRunLoopObserverRef

CFRunLoopModeRef 代表RunLoop的运行模式系统提供了5中运行模式：

default模式：几乎包括所有输入源(除NSConnection) NSDefaultRunLoopMode模式

connection模式：处理NSConnection事件，属于系统内部，用户基本不用

UITrackingRunLoopMode: 界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响。

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

NSRunLoopCommonModes: 包含了多种模式：default, modal, 和tracking modes。

一个RunLoop包含若干个Mode 每个Model又包含若干个Source／Timer／Observer

每次RunLoop启动时，只能指定其中一个Mode，这个mode被称作currentMode

如果需要切换Mode 只能tuichuLoop，再重新指定一个Mode进入。

CFRunLoopTimerRef

CFRunLoopTimerRef 就是基于时间的触发器

基本上说的就是NSTimer，他会收到RunLoop的mode的影响

GCD的定时器不会受到RunLoop的Mode的影响。

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {

    //这种方式启动的定时器 会自动加入到系统创建的RunLoop中

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

    //使用这种方法创建的定时器 必须添加到定时器中 否则不会有作用

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

    /*

     如果是NSDefaultRunLoopMode 这样虽然定时器会工作，但是当拖动UITextView 的时候定时器就不在工作了，因为RunLoop有四种模式，它会在这四种模式中来回切换，当UITextView拖动时，RunLoop会进入UITrackingRunLoopMode模式，这时，就不再执行其他模式中的timer事件。当不再拖动时，会再次进入NSDefaultRunLoopMode模式，进行定时器事件。

     如果换成 UITrackingRunLoopMode 模式，只有在UI拖动时，才会执行定时器事件。

     那么如果你需要在UI拖动时不影响定时器事件的执行，我们可以使用NSRunLoopCommonModes 这其实不是一种模式，而是一种模式集合，包括UITrackingRunLoopMode 和 NSDefaultRunLoopMode。

     NSTimer 计时不准确就是因为RunLoop在各种模式中自动切换进行的原因。GCD的计时是比较准确的

     */

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

}

- (void)show {

    NSLog(@"show -----");

}

GCD Timer

- (void)GCDTimer {

    //第一步 创建队列

    dispatch_queue_t queue = dispatch_get_global_queue(, );

    //第二步 创建一个GCD定时器

    /*

     第一个参数 表明创建的是一个定时器

     第四个参数 表示事件运行在哪个线程中

     */

    dispatch_source_t sourceTimer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, ,, queue);

    self.timer = sourceTimer;

    //设置时间间隔

    /*

     第一个参数 定时器

     第二个参事 定时器 开始时间

     第三个参数 从现在开始间隔时间

     第四个参数 精准度 GCD 的单位是纳秒

     */

    dispatch_source_set_timer(sourceTimer, DISPATCH_TIME_NOW, 2.0 *NSEC_PER_SEC, *NSEC_PER_SEC);

    //设置事件

    dispatch_source_set_event_handler(sourceTimer, ^{

       //要执行的任务

        NSLog(@"GCDTimer");

    });

    //启动定时器

    dispatch_resume(sourceTimer);

}

CFRunLoopSourceRef (事件源输入源)

分类

Source0: 不是基于端口的用户主动触发的事件。

Source1: 基于端口的通过内核和其他线程相互发送消息

RunLoop 的消息类型

根据上图我们可以将消息分为二种类型，第一种类型又可以细分为三种，此三种共同点就是它们都是异步执行的

port ->source1

监听程序的Mach ports，Mach ports是一个比较底层的东西，可以简单的理解为：内核通过port这种方式将信息发送，而mach则监听内核发来的port信息，然后将其整理，打包发给runloop。

Customer：->source0

很明显，由开发人员自己发送。不仅仅是发送，过程的话相当复杂，苹果也提供了一个CFRunLoopSource来帮助处理。由于很少用到，可以简单说下核心，但是对帮助我们理解runloop却很有帮助：
1.定义输入源（数据结构）
2.将输入源添加到runloop，那么这样就有了接受者，即为R1
3.协调输入源的客户端（单独线程），专门监听消息，然后将消息打包成runloop能够处理的样式，即第一步定义的输入源。它类似Mach的功能
4.谁来发送消息的问题？上面的machport是由内核发送的。自定义的当然要我们自己发送了。。。首先必须是另一个线程来发送（当然如果只是测试的话可以和第三步在同一个线程），先发送消息给输入源，然后唤醒R1，因为R1一般处于休眠状态，然后R1根据输入源来做相应的处理

Selector Sources

NSObject类提供了很多方法供我们使用，这些方法是添加到runloop的，所以如果没有开启runloop的话，不会运行（不过有个坑，请看下面介绍）。

/// 主线程

performSelectorOnMainThread:withObject:waitUntilDone:

performSelectorOnMainThread:withObject:waitUntilDone:modes:

/// 指定线程

performSelector:onThread:withObject:waitUntilDone:

performSelector:onThread:withObject:waitUntilDone:modes:

/// 针对当前线程

performSelector:withObject:afterDelay:

performSelector:withObject:afterDelay:inModes:

/// 取消，在当前线程，和上面两个方法对应

cancelPreviousPerformRequestsWithTarget:

cancelPreviousPerformRequestsWithTarget:selector:object:

下面提供的方法是在指定的线程运行aSelector，一般情况下aSelector会添加到指定线程的runloop。但，如果调用线程和指定线程为同一线程，且wait参数设为YES，那么aSelector会直接在指定线程运行，不再添加到runloop。

performSelectorOnMainThread:withObject:waitUntilDone:

performSelectorOnMainThread:withObject:waitUntilDone:modes:

performSelector:onThread:withObject:waitUntilDone:

performSelector:onThread:withObject:waitUntilDone:modes:

其实这也很好理解，假设这种情况也添加到指定线程的runloop，我们可以这样反向理解：1,当前线程runloop还没有开启，那么aSelector就不会被执行，然而你却一直在等待，造成线程卡死。2，当前线程runloop已经开启，那么调用performSelector这个方法的位置肯定是处于runloop的callout方法里面，在这里等待runloop再callout从而调用aSelector方法完成，显然也是死等待，线程卡死。。。

还有一些performSelector方法，是不会添加到runloop的，而是直接执行，可以按照上面的特殊情况进行理解。方法列举如下：

- (id)performSelector:(SEL)aSelector;

- (id)performSelector:(SEL)aSelector withObject:(id)object;

- (id)performSelector:(SEL)aSelector withObject:(id)object1 withObject:(id)object2;

看到这里，是否感觉有些乱？？？只要记住没有延迟或者等待的都不会添加到runloop，有延迟或者等待的还有排除上面提到的特殊情况

CFRunLoopObservers 观察者

首先它并不属于事件源(不会影响runloop的生命周期)，它比较特殊，用于观察runloop自身的一些状态的，有以下几种：

1.进入RunLoop kCFRunLoopEntry

2.RunLoop即将执行定时器 kCFRunLoopBeforeTimers

3.RunLoop即将执行输入源 kCFRunLoopBeforeSources

4.RunLoop即将休眠 kCFRunLoopBeforeWaiting

5.RunLoop被唤醒在处理完唤醒它的事件之前 kCFRunLoopAfterWaiting

6.退出 kCFRunLoopExit

//给RunLoop添加一个监听者

- (void)observer {

    //创建监听者

    /**

     param1: 给observer分配存储空间

     param2: 需要监听的状态类型:kCFRunLoopAllActivities监听所有状态

     param3: 是否每次都需要监听，如果NO则一次之后就被销毁，不再监听，类似定时器的是否重复

     param4: 监听的优先级，一般传0

     param5: 监听到的状态改变之后的回调

     return: 观察对象

     */

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

        switch (activity) {

            case kCFRunLoopEntry:

                NSLog(@"RunLoop进入");

                break;

            case kCFRunLoopBeforeTimers:

                NSLog(@"即将处理timer");

                break;

            case kCFRunLoopBeforeSources:

                NSLog(@"即将处理input Sources");

                break;

            case kCFRunLoopBeforeWaiting:

                NSLog(@"即将睡眠");

                break;

            case kCFRunLoopAfterWaiting:

                NSLog(@"从睡眠中唤醒，处理完唤醒源之前");

                break;

            case kCFRunLoopExit:

                NSLog(@"退出");

                break;

            default:

                break;

        }

    });

    /*

     *第一个参数 RunLoop

     *第二个参数 监听者

     *第三个参数 要监听RunLoop在哪种运行模式下的状态

     */

    [NSTimer scheduledTimerWithTimeInterval: target:self selector:@selector(doFireTimer) userInfo:nil repeats:NO];

    CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);

}

- (void)doFireTimer {

    NSLog(@"---fire---");

}

巴特西

iOS 开发之RunLoop

概念

iOS main函数中的RunLoop

RunLoop和线程的关系

RunLoop中的相关类

CFRunLoopTimerRef

CFRunLoopSourceRef (事件源输入源)

Selector Sources

CFRunLoopObservers 观察者

最新文章

热门文章

巴特西

iOS 开发之RunLoop

概念

iOS main函数中的RunLoop

RunLoop和线程的关系

RunLoop中的相关类

CFRunLoopTimerRef

CFRunLoopSourceRef (事件源 输入源)

Selector Sources

CFRunLoopObservers 观察者

最新文章

热门文章

CFRunLoopSourceRef (事件源输入源)