RunLoop

时间过的真快，一年过去了总该写点什么了，也算是一年来知识的积淀。

作为有一定ios开发经验的程序员，应该具有一定的底层知识储备，了解和掌握苹果手机是怎么能够随时捕获uievent以及滑动，拖拽事件的对于提升你的能力很有必要。

首先呢我们知道任何一个任务都是在一个线程上面执行的，然而当线程执行完任务时，会怎样呢？还是通过代码测试才有说服力。

MyThread是继承自NSThread的线程

设置线程的名字 在子线程上执行的任务 子线程销毁 打印结果

从打印可以看出子线程执行完任务就销毁了

如果把子线程用全局变量保存一下，代码如下

全局变量持有子线程 打印结果

从打印可以看出子线程没有销毁，没有执行dealloc方法，那么我们就会认为子线程还在，当再次执行子线程上的任务的时候程序会crash掉

执行两次子线程的任务

现在我们把执行的任务换一换

子线程循环执行任务

我们会惊喜的发现子线程居然没有销毁

由此我们可以得出保持线程存活的条件就是有执行不完的任务

如果我们就在子线程上面执行这样的任务，那么这条线程是不会做别的事情的，所以为了能够让一个线程不停的执行各种任务，苹果就推出了RunLoop这个事件循环运行机制

RunLoop顾名思义简单理解就是在跑圈，不停的跑圈。对于上面的任务我们修改成这样

把子线程加入到运行循环里边 打印结果

从打印结果可以看出并没有执行---子线程任务结束这句话 同时子线程也没有销毁 程序没有崩溃 说明成勋运行到[runLoop run]的时候并没有往下继续执行。对于[NSMachPort port]的作用就是给当前RunLoop添加一个端口消息，以至于RunLoop能够接受别的事件类型，下面会讲到

首先正是有了RunLoop才保障了线程能够不销毁，等待消息的到来，进而处理消息

RunLoop内部逻辑大概这样的

do{

        1.接收消息

        2.如果没有消息内核会把当前线程挂起。不在往下执行

        3.休息直到接收到了消息，执行消息对应的任务

    } while(消息 != 退出);

那么我们如何创建一个RunLoop，苹果给我们提供了四个API [NSRunLoop currentRunLoop];//获取当前线程的RunLoop        [NSRunLoop mainRunLoop];  CFRunLoopGetMain();     CFRunLoopGetCurrent();来获取RunLoop。注意RunLoop只能使用这几个api生成，不能使用alloc生成

/// 获取一个 pthread 对应的 RunLoop。

CFRunLoopRef _CFRunLoopGet(pthread_t thread) {

    OSSpinLockLock(&loopsLock);

    if(!loopsDic) {

        // 第一次进入时，初始化全局Dic，并先为主线程创建一个 RunLoop。

        loopsDic = CFDictionaryCreateMutable();

        CFRunLoopRef mainLoop = _CFRunLoopCreate();

        CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);

    }

    /// 直接从 Dictionary 里获取。

    CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));

    if(!loop) {

        /// 取不到时，创建一个

        loop = _CFRunLoopCreate();

        CFDictionarySetValue(loopsDic, thread, loop);

        /// 注册一个回调，当线程销毁时，顺便也销毁其对应的 RunLoop。

        _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);

    }

    OSSpinLockUnLock(&loopsLock);

    returnloop;

}

从RunLoop生成过程可以看出，线程和RunLoop是一一对应的，其关系是保存到一个全局字典里。线程创建时并没有RunLoop，如果不主动获取，那它一只不会有，RunLoop的销毁是发生在线程结束时。主线成的RunLoop是一只存在的，任意一个子线程创建RunLoop时都会保证主线程RunLoop的存在

下面具体讲解RunLoop的使用，RunLoop的结构

RunLoop结构

RunLoop同一时间只能在一个mode下运行

mode有三种kCFRunLoopDefaultMode 一般情况下App都是运行在这个mode下的 UITrackingRunLoopMode 滑动事件运行在这个模式下  NSRunLoopCommonModes包含了前两种，在该模式下运行滑动事件和timer事件能够一起执行

source分为source0和source1。 source0可以简单理解为uievent，滑动等事件和performSelector等手动出发的事件。 source1处理系统内核的mach_msg事件（系统内部的端口事件）。诸如唤醒RunLoop或者让RunLoop进入休眠节省资源等。一般来说日常开发中我们需要关注的是source0，source1只需要了解。之所以说source0更重要是因为日常开发中，我们需要对常驻线程进行操作的事件大多都是source0

timer定时源就是NSTimer类，NSTimer定时器的触发正是基于RunLoop运行的，所以使用NSTimer之前必须注册到RunLoop，但是RunLoop为了节省资源并不会在非常准确的时间点调用定时器，如果一个任务执行时间较长，那么当错过一个时间点后只能等到下一个时间点执行，并不会延后执行

observer是一个观察者，随时监听外部（比如当前控制器）当前RunLoop的运行状态，运行状态有一下几种

RunLoop的运行状态

kCFRunLoopBeforeTimers在运行定时源消息之前的状态

kCFRunLoopBeforeSources在运行输入源source0 (cfsocket等)source1内核事件（cfmessage，cfmactport）之前的状态

kCFRunLoopBeforeWaiting循环挂起(线程休眠)之前的状态

kCFRunLoopAfterWaiting循环挂起之后的状态

// 创建observer

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

        NSLog(@"----监听到RunLoop状态发生改变---%zd", activity);

    });    // 添加观察者：监听RunLoop的状态    CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);

Source/Timer/Observer 被统称为 mode item，一个item可以被同时加入多个mode。但一个item被重复加入同一个mode时是不会有效果的 如果一个mode中一个item 都没有（只有Observer也不行），则 RunLoop 会直接退出，不进入循环。

RunLoop运行总是在某一个model下的，常见的计时器事件和滚动事件能够同时运行就是在不同的model之间切换（切换model的本质是调用不同的do{}while循环），当然如果使用NSRunLoopCommenModels也能达到同样的效果

[runLoop addPort:[NSMachPort port]      forMode:NSRunLoopCommenModels];对这句话的理解，我的理解就是[NSMachPort port]是一个端口消息（包括定时源 输入源）加上对端口消息的处理runloop才能在挂起的状态接受处理消息，继续循环，如果没有了[NSMachPort port]那个这个循环就不能够处理任何消息（只是一个简单的一次循环）出了循环就不会循环执行了

RunLoop是寄生于线程的消息循环机制，它能保证线程存活，而不是线性执行完任务就消亡。

RunLoop与线程是一一对应的，每个线程只有唯一与之对应的一个RunLoop。我们不能创建RunLoop，只能在当前线程当中获取线程对应的RunLoop

下面我们看看线程是如何挂起和激活的，如下图（不论你运行那个程序，打个断点总能看到这样的线程池结构）

程序运行时候刚开始开启的线程

可以看出Thread1.  Thread6. Thread7里面的函数调用栈是明显不一样的，Thread7是我们生成的子线程，Thread1是ui线程（主线程）所在队列是serial的就是串型队列 队列名字是com.apple.main-thread我们注意到Thread6线程当开启线程运行之后，系统又调用了mach_msg_trap是不是很熟悉这个函数，mach_msg_trap让当前线程挂起（当前线程的RunLoop挂起，循环停留在 if(__CFRunLoopServiceMachPort(dispatchPort, &msg,sizeof(msg_buffer), &livePort,0)) {

                gotohandle_msg;

            }这里，一只等待内核发送mach_msg消息激活循环

）对的，它就是在RunLoop中那个用来和内核打交道的mach_port（可以理解为进城通信端口，或者是微内核的实现ApI）端口中的成员，该函数的作用是让RunLoop挂起（线程挂起或者叫休眠），当有mach_msg消息到达时候，内核会处理mach_msg(可能是定时源 也可能是输入源)消息，让RunLoop(线程)激活，Thread6队列名字com.apple.uikit.eventfetch-thread顾名思义就是捕获uievent事件的，所以我的理解就是当前进程（应用程序）的这个线程（也可能是别的进程或者别的进程的线程）用来捕获uievent事件然后通过硬件驱动，把消息转发给内核，内核就会通知主线程的RunLoop处理uievent事件

RunLoop源码也是这样的在RunLoopRun函数里面，首先RunLoop是从这里进入

初始化RunLoop包括在那个model下是否有observer监听运行状态 开始进入RunLoop循环

在 staticint32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode)函数中dispatch_source_t timeout_timer =NULL;

    struct__timeout_context *timeout_context = (struct__timeout_context *)malloc(sizeof(*timeout_context));

    if (seconds <= 0.0) { // instant timeout

        seconds =0.0;

        timeout_context->termTSR =0ULL;

    }elseif(seconds <= TIMER_INTERVAL_LIMIT) {

dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, DISPATCH_QUEUE_OVERCOMMIT);

timeout_timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER,0,0, queue);

        dispatch_retain(timeout_timer);

timeout_context->ds = timeout_timer;

timeout_context->rl = (CFRunLoopRef)CFRetain(rl);

timeout_context->termTSR = startTSR + __CFTimeIntervalToTSR(seconds);

dispatch_set_context(timeout_timer, timeout_context);// source gets ownership of context

dispatch_source_set_event_handler_f(timeout_timer, __CFRunLoopTimeout);

        dispatch_source_set_cancel_handler_f(timeout_timer, __CFRunLoopTimeoutCancel);

        uint64_t ns_at = (uint64_t)((__CFTSRToTimeInterval(startTSR) + seconds) *1000000000ULL);

        dispatch_source_set_timer(timeout_timer, dispatch_time(1, ns_at), DISPATCH_TIME_FOREVER,1000ULL);

        dispatch_resume(timeout_timer);

    }else { // infinite timeout

        seconds =9999999999.0;

        timeout_context->termTSR = UINT64_MAX;

    }对于定时源NSTimer系统设置的RunLoop循环到时时间是9999999999.0基本上可以达到现实的需求

挂起RunLoop

__CFPortSet waitSet = rlm->_portSet;  __CFRunLoopUnsetIgnoreWakeUps(rl)

挂起RunLoop(线程休眠)当然挂起工作是由mach_port_t这个端口来做的

RunLoop挂起等待内核发送mach_msg唤醒RunLoop

__CFRunLoopSetIgnoreWakeUps(rl);唤醒RunLoop

唤醒RunLoop处理事件

CFRUNLOOP_WAKEUP_FOR_TIMER();

            if(!__CFRunLoopDoTimers(rl, rlm, mach_absolute_time())) {

                // Re-arm the next timer, because we apparently fired early

                __CFArmNextTimerInMode(rlm, rl);

            }处理natimer事件

CFRUNLOOP_WAKEUP_FOR_SOURCE();

            // Despite the name, this works for windows handles as well

            CFRunLoopSourceRef rls = __CFRunLoopModeFindSourceForMachPort(rl, rlm, livePort);处理source事件，通过livePort端口找到具体的source事件

判断RunLoop是否处理事件完成

到此完美结束，对于RunLoop认识的还是比较浅的，RunLoop的核心是mach_port这个东东，它是和内核紧密相关的，想要更深层次了解的可以观看孙源大神的这个视频，url地址：

RunLoop运行循环

zhuweigea (LaoZhu) · GitHub