时间过的真快，一年过去了总该写点什么了，也算是一年来知识的积淀。
作为有一定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同一时间只能在一个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的运行状态，运行状态有一下几种
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是从这里进入
在 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基本上可以达到现实的需求
__CFPortSet waitSet = rlm->_portSet; __CFRunLoopUnsetIgnoreWakeUps(rl)
挂起RunLoop(线程休眠)当然挂起工作是由mach_port_t这个端口来做的
__CFRunLoopSetIgnoreWakeUps(rl);唤醒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的核心是mach_port这个东东，它是和内核紧密相关的，想要更深层次了解的可以观看孙源大神的这个视频，url地址：
