前言

最近离职了,可以尽情熬夜写点总结，不用担心第二天上班爽并蛋疼着，这篇的主角 RunLoop 一座大山，涵盖的知识面挺广的，希望此篇文章能获得同道中人关注一波，点个喜欢❤️，更期待提出一些不知或者有误的地方。闲话不扯，放下手中的饮料和🚬步入正题。

初识 RunLoop - 运行循环

RunLoop 既运行循环机制，在应用级别考虑，应用程序中所有的任务处理（用户交互事件、网络请求回调数据接收等）都是在线程中执行，一般来讲一个线程一次只能执行一个任务，执行完线程销毁（OC 中子线程异步销毁，主线程除外），但是问题来了如何让线程保活呢？并且如何让线程在没有处理消息时休眠以避免资源占用、在有消息到来时立刻被唤醒呢？RunLoop 就是解决这些问题的，它所做的一切都是基于线程，可以说是为线程而生。

RunLoop 的作用：

保证程序不退出保活线程，它就是一个死循环："接受事件 -> ...等待 -> 处理"
负责监听管理事件，触摸事件（用户交互事件）、时钟事件（Timer）、网络事件（网络请求回调接收等）以及系统事件内核事件；
如果没有事件则进入睡眠状态

RunLoop - 具体是什么？

在计算机系统软件体系结构采用一种层的结构，有一句名言

"Any problem in computer science can be solved by another layer of indirection."
"计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决"

此句名言的出处不知，但这句几乎概况了计算机系统软件体系结构的设计要点，每个层之间需要通信，其通信协议我们一般称为 接口（Interface）。在OSX/iOS 系统中也是如此，位于最上层的应用程序，我们使用的是应用程序编程接口（Application Programming Interface），而且 Objective-C是重度面向对象的语言，那么 RunLoop 作为线程基础架构的一部分，其可想而知必然是一个对象，这个对象管理着线程中需要处理的任务，管理着线程的这种运行循环。

OSX/iOS 系统中，提供的两个 RunLoop 对象：

CFRunLoopRef 是在 CoreFoundation 框架内的，它提供了纯 C 函数的 API，且其是开源的，开源下载地址(CoreFoundation 源码)。
NSRunLoop 是基于 CFRunLoopRef 的封装，提供了面向对象的 API，并不开源。

分析 CoreFoundation 库内的 RunLoop 源码分析

CoreFoundation 源码中 CFRunLoop 关于 RunLoop 的有五个类：
- CFRunLoopRef
- CFRunLoopSourceRef
- CFRunLoopTimerRef
- CFRunLoopObserverRef
- CFRunLoopModeRef
这五大类是如何通过C语言封装成的呢 ?

typedef struct __CFRunLoop * CFRunLoopRef;

typedef struct __CFRunLoopSource * CFRunLoopSourceRef;

typedef struct __CFRunLoopObserver * CFRunLoopObserverRef;

typedef struct __CFRunLoopTimer * CFRunLoopTimerRef;

由 CFRunLoop.h文件查看到如上源码

typedef struct __CFRunLoopMode *CFRunLoopModeRef;

由 CFRunLoopModeRef 类于CFRunLoop.c 第 521 行可找到，下面具体分析其各种的源码结构

RunLoop

CFRunLoop.c 文件中第 636 行：

struct __CFRunLoop {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;      /* locked for accessing mode list */
    __CFPort _wakeUpPort;       // used for CFRunLoopWakeUp  内核向该端口发送消息可以唤醒runloop
    Boolean _unused;
    volatile _per_run_data *_perRunData;          // reset for runs of the run loop
    pthread_t _pthread;      //RunLoop对应的线程
    uint32_t _winthread;
    CFMutableSetRef _commonModes;     //存储的是字符串，记录所有标记为common的mode
    CFMutableSetRef _commonModeItems;    //等同NSMutableSet 存储所有commonMode的item(source、timer、observer)
    CFRunLoopModeRef _currentMode;     //当前运行的mode
    CFMutableSetRef _modes;    //存储的是CFRunLoopModeRef
    struct _block_item *_blocks_head;   //doblocks的时候用到
    struct _block_item *_blocks_tail;
    CFTypeRef _counterpart;
};

由源码可知，一个RunLoop对象，主要包含了对应的一个线程，若干个 Mode，若干个 commonMode，还有一个当前运行的 Mode（_currentMode）。
我们并不能去创建这个 CFRunLoopRef（为什么呢？），而是通过如下方法去获取当前线程的 RunLoop：

// CFRunLoop.h 中73行 源码
CF_EXPORT CFRunLoopRef CFRunLoopGetCurrent(void); // 获取当前线程runloop
CF_EXPORT CFRunLoopRef CFRunLoopGetMain(void);  // 获取主线程 runloop

具体使用姿势：

    // 获取当前runloop
    CFRunLoopRef runloop = CFRunLoopGetCurrent();

RunLoopMode - 运行模式

CFRunLoop.c 文件中第 523 行：

struct __CFRunLoopMode {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;  /* must have the run loop locked before locking this */
    CFStringRef _name;   //mode名称
    Boolean _stopped;    //mode是否被终止
    char _padding[3];
    //几种事件
    CFMutableSetRef _sources0;  //sources0
    CFMutableSetRef _sources1;  //sources1
    CFMutableArrayRef _observers; //通知
    CFMutableArrayRef _timers;    //定时器
    CFMutableDictionaryRef _portToV1SourceMap; //字典  key是mach_port_t，value是CFRunLoopSourceRef
    __CFPortSet _portSet; //保存所有需要监听的port，比如_wakeUpPort，_timerPort都保存在这个数组中
    CFIndex _observerMask;
#if USE_DISPATCH_SOURCE_FOR_TIMERS
    dispatch_source_t _timerSource;
    dispatch_queue_t _queue;
    Boolean _timerFired; // set to true by the source when a timer has fired
    Boolean _dispatchTimerArmed;
#endif
#if USE_MK_TIMER_TOO
    mach_port_t _timerPort;
    Boolean _mkTimerArmed;
#endif
#if DEPLOYMENT_TARGET_WINDOWS
    DWORD _msgQMask;
    void (*_msgPump)(void);
#endif
    uint64_t _timerSoftDeadline; /* TSR */
    uint64_t _timerHardDeadline; /* TSR */
};

一个 CFRunLoopMode 对象有一个 name ，若干 source0、source1、timer、observer和若干port，所有事件都是由 Mode 在管理，而一个线程下的 RunLoop 管理着若干个 Mode (ModeItems)。在一个线程中 runloop 保活线程并且在指定 Mode下使其接受处理事件，又在每次 runloop 循环中(之前讲的死循环概念)进行 Mode间的切换。
Cocoa框架和Core Foundation框架中定义了五种 Mode (Guides and Sample Code )
- Default 默认Mode，APP运行起来之后，主线程的RunLoop默认在该Mode下运行
  - NSDefaultRunLoopMode Cocoa 框架
  - kCFRunLoopDefaultMode Core Foundation 框架
- Event tracking 追踪触摸的手势，所有 UI 交互事件都运行在这个Mode下
- UITrackingRunLoopMode(Cocoa)
- Common modes 共有型 Model 含有上面两种Mode模式的意义
  - NSRunLoopCommonModes(Cocoa)
  - kCFRunLoopCommonModes (Core Foundation)
- Connection 系统内核模式，系统调用事件发生会切换到相应模式下，开发者无法操作
  - GSEventReceiveRunLoopMode(Cocoa)
- Modal 项目初始化模式，只会走一次
  - UIInitializationRunLoopMode(Cocoa)

RunLoop Source - 事件源

CFRunLoop.c文件中第 943 行：

struct __CFRunLoopSource {
    CFRuntimeBase _base;
    uint32_t _bits; //用于标记Signaled状态，source0只有在被标记为Signaled状态，才会被处理
    pthread_mutex_t _lock;
    CFIndex _order;         /* immutable */
    CFMutableBagRef _runLoops;
    union {
        CFRunLoopSourceContext version0;     /* immutable, except invalidation */
        CFRunLoopSourceContext1 version1;    /* immutable, except invalidation */
    } _context;
};

事件源顾名思义事件的产生地，由上源码会发现 Source 分为两种：
- Source0 非基于Port的
  - 只包含了一个回调（函数指针），它并不能主动触发事件。使用时，你需要先调用 CFRunLoopSourceSignal(source)，将这个 Source 标记为待处理 signal 状态，然后手动调 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop，让其处理这个事件。
- 其作用范围是应用程序中事件，由App自己管理的UIEvent、CFSocket都是source0。以下是source0的结构体：

typedef struct {
    CFIndex version;
    void *  info;
    const void *(*retain)(const void *info);
    void    (*release)(const void *info);
    CFStringRef (*copyDescription)(const void *info);
    Boolean (*equal)(const void *info1, const void *info2);
    CFHashCode  (*hash)(const void *info);
    void    (*schedule)(void *info, CFRunLoopRef rl, CFStringRef mode);
    void    (*cancel)(void *info, CFRunLoopRef rl, CFStringRef mode);
    void    (*perform)(void *info);
} CFRunLoopSourceContext;

Source1
- 包含了一个 mach_port 和一个回调（函数指针），被用于通过内核和其他线程相互发送消息。可以接收内核消息并触发回调，这种 Source 能主动唤醒 RunLoop 的线程。
- 其作用范围是由RunLoop和内核管理，source1带有mach_port_t，可以接收内核消息并触发回调，以下是source1的结构体:

typedef struct {
    CFIndex version;
    void *  info;
    const void *(*retain)(const void *info);
    void    (*release)(const void *info);
    CFStringRef (*copyDescription)(const void *info);
    Boolean (*equal)(const void *info1, const void *info2);
    CFHashCode  (*hash)(const void *info);
#if (TARGET_OS_MAC && !(TARGET_OS_EMBEDDED || TARGET_OS_IPHONE)) || (TARGET_OS_EMBEDDED || TARGET_OS_IPHONE)
    mach_port_t (*getPort)(void *info);
    void *  (*perform)(void *msg, CFIndex size, CFAllocatorRef allocator, void *info);
#else
    void *  (*getPort)(void *info);
    void    (*perform)(void *info);
#endif
} CFRunLoopSourceContext1;

CFRunLoopObserver - 观察者

CFRunLoop.c文件中第 981 行：

struct __CFRunLoopObserver {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;
    CFRunLoopRef _runLoop;
    CFIndex _rlCount;
    CFOptionFlags _activities;      /* immutable */
    CFIndex _order;         /* immutable */
    CFRunLoopObserverCallBack _callout; /* immutable 监听到对应状态的回调函数 (函数指针) */
    CFRunLoopObserverContext _context;  /* immutable, except invalidation  定义一个监听者的上下文*/
};

Observer 是 mode 下数组保存，其都包含了一个回调（函数指针），当 RunLoop 的状态发生变化时，观察者就能通过回调接受到这个变化。回调函数CFRunLoopObserverCallBack
CFRunLoopObserver 可以观察的状态有如下6种:

// 位运算枚举
/* Run Loop Observer Activities */
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry = (1UL << 0), //即将进入run loop
    kCFRunLoopBeforeTimers = (1UL << 1), //即将处理timer
    kCFRunLoopBeforeSources = (1UL << 2),//即将处理source
    kCFRunLoopBeforeWaiting = (1UL << 5),//即将进入休眠
    kCFRunLoopAfterWaiting = (1UL << 6),//被唤醒但是还没开始处理事件
    kCFRunLoopExit = (1UL << 7),//run loop已经退出
    kCFRunLoopAllActivities = 0x0FFFFFFFU
};

CFRunLoopTimer

CFRunLoop.c文件中第 1049 行：

struct __CFRunLoopTimer {
    CFRuntimeBase _base;
    uint16_t _bits;  //标记fire状态
    pthread_mutex_t _lock;
    CFRunLoopRef _runLoop;        //添加该timer的runloop
    CFMutableSetRef _rlModes;     //存放所有 包含该timer的 mode的 modeName，意味着一个timer可能会在多个mode中存在
    CFAbsoluteTime _nextFireDate;
    CFTimeInterval _interval;     //理想时间间隔  /* immutable */
    CFTimeInterval _tolerance;    //时间偏差      /* mutable */
    uint64_t _fireTSR;          /* TSR units */
    CFIndex _order;         /* immutable */
    CFRunLoopTimerCallBack _callout;    /* immutable */
    CFRunLoopTimerContext _context; /* immutable, except invalidation */
};

是基于时间的触发器，它和 NSTimer 是 toll-free bridged 的，可以相互转换的。其包含一个时间长度和一个回调（函数指针）。当其加入到 RunLoop 时，可以在设定的时间点 RunLoop 会被唤醒并执行回调。

RunLoop 的层次结构及原理

Runloop 整体层次结构

每条线程对应一个唯一的 RunLoop 对象，我们并不能去手动创建，只能调用方法函数获取当前线程的 RunLoop 对象，第一次获取的时候 RunLoop 对象，其完成创建。(主线程除外，主线程其自动创建)
一个 RunLoop 包含若干个 Mode， RunLoop 运行循环启动后，只能在一个特定的 Mode 下去处理当前 Mode 中的事件响应，这个Mode被称作 CurrentMode。其他Mode中的事件会被暂停，然后根据不同的事件切换到不同类型 Mode，从而处理相应事件，切换频率很快很快，这个切换动作是在同一个运行循环中完成的。
一个 Mode 下，有若干个source0、source1、timer、observer (统称为 mode item)和若干port，也就是说所有的事件都是由 Mode 管理着。

由上五大类源码分析对 Runloop 整体结构层次梳理如下图：

RunLoop 整体结构.png

RunLoop - 运行循环原理步骤解析

RunLoop每次循环的执行步骤大概如下

通知observers 已经进入RunLoop
通知observes 即将开始处理timer source
通知observes 即将开始处理input sources（不包括port-based source）
开始处理input source（不包括port-based source）
如果有port-based source待处理，则开始处理port-based source，跳转到第 9 步
通知observes线程即将进入休眠
让线程进入休眠状态，直到有以下事件发生：
- 收到内核发送过来的消息
- 定时器事件需要执行
- RunLoop的超时时间到了
- 外部手动唤醒RunLoop
通知observes 线程被唤醒
处理待处理的事件：
- 如果自定义的timer被fire，那么执行该timer事件并重新开始循环，跳转到第2步
- 如果input source被fire，则处理该事件
- 如果RunLoop被手动唤醒，并且没有超时，那么重新开始循环，跳转到第2步
通知observes RunLoop已经退出

RunLoop内部实现逻辑..png

RunLoop - 运行循环步骤源码解析

CFRunLoopGetCurrent 和 CFRunLoopGetMain - 获取线程的 RunLoop 对象，苹果不允许我们创建 RunLoop，只能通过函数获取当前线程的 RunLoop 对象。
- CFRunLoopGetCurrent

//取当前所在线程的 RunLoop
CFRunLoopRef CFRunLoopGetCurrent(void) {
    CHECK_FOR_FORK();
    CFRunLoopRef rl = (CFRunLoopRef)_CFGetTSD(__CFTSDKeyRunLoop);
    if (rl) return rl;
    //传入当前线程
    return _CFRunLoopGet0(pthread_self());
}

CFRunLoopGetCurrent 函数内部调用了_CFRunLoopGet0()，传入的参数是当前线程。CFRunLoopGetCurrent 函数必须要在线程内部调用，才能获取当前线程的RunLoop。

CFRunLoopGetMain

//取主线程的RunLoop
CFRunLoopRef CFRunLoopGetMain(void) {
    CHECK_FOR_FORK();
    static CFRunLoopRef __main = NULL; // no retain needed
    //传入主线程
    if (!__main) __main = _CFRunLoopGet0(pthread_main_thread_np()); // no CAS needed
    return __main;
}

CFRunLoopGetMain 函数内部也调用了_CFRunLoopGet0()，传入的参数是主线程。CFRunLoopGetMain()不管在主线程还是子线程中调用，都是得到主线程的RunLoop。

CFRunLoopGet0

// 全局的 dictionary, key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef __CFRunLoops = NULL;
static CFSpinLock_t loopsLock = CFSpinLockInit;
 
// t==0 is a synonym for "main thread" that always works
//根据线程取RunLoop
CF_EXPORT CFRunLoopRef _CFRunLoopGet0(pthread_t t) {
    if (pthread_equal(t, kNilPthreadT)) {
        t = pthread_main_thread_np();
    }
    __CFSpinLock(&loopsLock);
    //如果存储RunLoop的字典不存在
    if (!__CFRunLoops) {
        __CFSpinUnlock(&loopsLock);
        //创建一个临时字典dict
        CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks);
        //创建主线程的RunLoop
        CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np());
        //把主线程的RunLoop保存到dict中，key是线程，value是RunLoop
        CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop);
        //此处NULL和__CFRunLoops指针都指向NULL，匹配，所以将dict写到__CFRunLoops
        if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) {
            //释放dict
            CFRelease(dict);
        }
        //释放mainrunloop
        CFRelease(mainLoop);
        __CFSpinLock(&loopsLock);
    }
    //以上说明，第一次进来的时候，不管是getMainRunloop还是get子线程的runloop，主线程的runloop总是会被创建
    //从字典__CFRunLoops中获取传入线程t的runloop
    CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
    __CFSpinUnlock(&loopsLock);
    //如果没有获取到
    if (!loop) {
        //根据线程t创建一个runloop
        CFRunLoopRef newLoop = __CFRunLoopCreate(t);
        __CFSpinLock(&loopsLock);
        loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
        if (!loop) {
            //把newLoop存入字典__CFRunLoops，key是线程t
            CFDictionarySetValue(__CFRunLoops, pthreadPointer(t), newLoop);
            loop = newLoop;
        }
        // don't release run loops inside the loopsLock, because CFRunLoopDeallocate may end up taking it
        __CFSpinUnlock(&loopsLock);
        CFRelease(newLoop);
    }
    //如果传入线程就是当前线程
    if (pthread_equal(t, pthread_self())) {
        _CFSetTSD(__CFTSDKeyRunLoop, (void *)loop, NULL);
        if (0 == _CFGetTSD(__CFTSDKeyRunLoopCntr)) {
            //注册一个回调，当线程销毁时，销毁对应的RunLoop
            _CFSetTSD(__CFTSDKeyRunLoopCntr, (void *)(PTHREAD_DESTRUCTOR_ITERATIONS-1), (void (*)(void *))__CFFinalizeRunLoop);
        }
    }
    return loop;
}

这个函数才是真正的 RunLoop 对象创建，源码中分析得到以下几点：
1. 线程和 RunLoop 是一一对应的，对应关系保存在一个以key-value的方式全局的 dictionary 中。
2. RunLoop 创建过程类似懒加载，只有在第一次获取的时候才创建，所以一个线程只有唯一以其对应的 RunLoop 对象。
3. 主线程的 RunLoop 会在初始化全局字典时创建，子线程的RunLoop会在第一次获取的时候创建，如果不获取的话就一直不会被创建
4. RunLoop 会在线程销毁时而销毁

CFRunLoopAddCommonMode - 创建 RunLoop 对象下的 mode

void CFRunLoopAddCommonMode(CFRunLoopRef rl, CFStringRef modeName) {
    CHECK_FOR_FORK();
    if (__CFRunLoopIsDeallocating(rl)) return;
    __CFRunLoopLock(rl);
    //看rl中是否已经有这个mode，如果有就什么都不做
    if (!CFSetContainsValue(rl->_commonModes, modeName)) {
        CFSetRef set = rl->_commonModeItems ? CFSetCreateCopy(kCFAllocatorSystemDefault, rl->_commonModeItems) : NULL;
        //把modeName添加到RunLoop的_commonModes中
        CFSetAddValue(rl->_commonModes, modeName);
        if (NULL != set) {
            CFTypeRef context[2] = {rl, modeName};
            /* add all common-modes items to new mode */
            //这里调用CFRunLoopAddSource/CFRunLoopAddObserver/CFRunLoopAddTimer的时候会调用
            //__CFRunLoopFindMode(rl, modeName, true)，CFRunLoopMode对象在这个时候被创建
            CFSetApplyFunction(set, (__CFRunLoopAddItemsToCommonMode), (void *)context);
            CFRelease(set);
        }
    } else {
    }
    __CFRunLoopUnlock(rl);
}

苹果不允许我们直接创建一个 CFRunLoopMode 对象，通过调用CFRunLoopAddCommonMode 函数传入一个字符串向 RunLoop 中添加 Mode，传入的字符串即为Mode的名字，Mode对象在 RunLoop 内部创建的。

modeName 不能重复，modeName 是mode的唯一标识符
RunLoop 的_commonModes 数组存放所有被标记为 common 的 mode 的名称
添加 commonMode 会把 commonModeItems 数组中的所有 source同步到新添加的mode中
CFRunLoopMode 对象在CFRunLoopAddItemsToCommonMode 函数中调用CFRunLoopFindMode时被创建
CFRunLoopAddSource - 添加 Run Loop 中 mode 下（modeItem）以Source 分析

//添加source事件
void CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef rls, CFStringRef modeName) {    /* DOES CALLOUT */
    CHECK_FOR_FORK();
    if (__CFRunLoopIsDeallocating(rl)) return;
    if (!__CFIsValid(rls)) return;
    Boolean doVer0Callout = false;
    __CFRunLoopLock(rl);
    //如果是kCFRunLoopCommonModes
    if (modeName == kCFRunLoopCommonModes) {
        //如果runloop的_commonModes存在，则copy一个新的复制给set
        CFSetRef set = rl->_commonModes ? CFSetCreateCopy(kCFAllocatorSystemDefault, rl->_commonModes) : NULL;
       //如果runl _commonModeItems为空
        if (NULL == rl->_commonModeItems) {
            //先初始化
            rl->_commonModeItems = CFSetCreateMutable(kCFAllocatorSystemDefault, 0, &kCFTypeSetCallBacks);
        }
        //把传入的CFRunLoopSourceRef加入_commonModeItems
        CFSetAddValue(rl->_commonModeItems, rls);
        //如果刚才set copy到的数组里有数据
        if (NULL != set) {
            CFTypeRef context[2] = {rl, rls};
            /* add new item to all common-modes */
            //则把set里的所有mode都执行一遍__CFRunLoopAddItemToCommonModes函数
            CFSetApplyFunction(set, (__CFRunLoopAddItemToCommonModes), (void *)context);
            CFRelease(set);
        }
        //以上分支的逻辑就是，如果你往kCFRunLoopCommonModes里面添加一个source，那么所有_commonModes里的mode都会添加这个source
    } else {
        //根据modeName查找mode
        CFRunLoopModeRef rlm = __CFRunLoopFindMode(rl, modeName, true);
        //如果_sources0不存在，则初始化_sources0，_sources0和_portToV1SourceMap
        if (NULL != rlm && NULL == rlm->_sources0) {
            rlm->_sources0 = CFSetCreateMutable(kCFAllocatorSystemDefault, 0, &kCFTypeSetCallBacks);
            rlm->_sources1 = CFSetCreateMutable(kCFAllocatorSystemDefault, 0, &kCFTypeSetCallBacks);
            rlm->_portToV1SourceMap = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, NULL);
        }
        //如果_sources0和_sources1中都不包含传入的source
        if (NULL != rlm && !CFSetContainsValue(rlm->_sources0, rls) && !CFSetContainsValue(rlm->_sources1, rls)) {
            //如果version是0，则加到_sources0
            if (0 == rls->_context.version0.version) {
                CFSetAddValue(rlm->_sources0, rls);
                //如果version是1，则加到_sources1
            } else if (1 == rls->_context.version0.version) {
                CFSetAddValue(rlm->_sources1, rls);
                __CFPort src_port = rls->_context.version1.getPort(rls->_context.version1.info);
                if (CFPORT_NULL != src_port) {
                    //此处只有在加到source1的时候才会把souce和一个mach_port_t对应起来
                    //可以理解为，source1可以通过内核向其端口发送消息来主动唤醒runloop
                    CFDictionarySetValue(rlm->_portToV1SourceMap, (const void *)(uintptr_t)src_port, rls);
                    __CFPortSetInsert(src_port, rlm->_portSet);
                }
            }
            __CFRunLoopSourceLock(rls);
            //把runloop加入到source的_runLoops中
            if (NULL == rls->_runLoops) {
                rls->_runLoops = CFBagCreateMutable(kCFAllocatorSystemDefault, 0, &kCFTypeBagCallBacks); // sources retain run loops!
            }
            CFBagAddValue(rls->_runLoops, rl);
            __CFRunLoopSourceUnlock(rls);
            if (0 == rls->_context.version0.version) {
                if (NULL != rls->_context.version0.schedule) {
                    doVer0Callout = true;
                }
            }
        }
        if (NULL != rlm) {
            __CFRunLoopModeUnlock(rlm);
        }
    }
    __CFRunLoopUnlock(rl);
    if (doVer0Callout) {
        // although it looses some protection for the source, we have no choice but
        // to do this after unlocking the run loop and mode locks, to avoid deadlocks
        // where the source wants to take a lock which is already held in another
        // thread which is itself waiting for a run loop/mode lock
        rls->_context.version0.schedule(rls->_context.version0.info, rl, modeName); /* CALLOUT */
    }
}

添加 mode 中所管理的各种事件 - Observer/Source/Timer，此分析以Source 事件为例

若modeName传入kCFRunLoopCommonModes，则该source会被保存到RunLoop的_commonModeItems中，且被添加到所有commonMode中
若modeName传入的不是kCFRunLoopCommonModes，则会先查找该Mode，如果没有，会创建一个
同一个 source 在一个 mode 中只能被添加一次
CFRunLoopRun - 启动 RunLoop - 源码2628行

//默认运行runloop的kCFRunLoopDefaultMode
void CFRunLoopRun(void) {   /* DOES CALLOUT */
    int32_t result;
    do {
        //默认在kCFRunLoopDefaultMode下运行runloop
        result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
        CHECK_FOR_FORK();
    } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
}

启动线程的 RunLoop

RunLoop 启动，实际上就是一个 do - while 循环
CFRunLoopRun 函数中调用了 CFRunLoopRunSpecific 函数，其中两个参数一个 RunLoop 对象是当前 RunLoop对象，另一个是 modeName 参数传入 kCFRunLoopDefaultMode
CFRunLoopRunInMode - 指定 mode 启动 RunLoop - 源码 2636 行

SInt32 CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) {     /* DOES CALLOUT */
    CHECK_FOR_FORK();
    return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}

指定特定 mode 启动 RunLoop

在 CFRunLoopRunInMode 函数中也调用了 CFRunLoopRunSpecific 函数，runloop 参数传入当前 RunLoop对象，modeName 参数传入 CFRunLoopRunInMode 传入的 modeName。
从启动 RunLoop 这两个函数可以发现，虽然 RunLoop 有很多个mode，但是RunLoop在run的时候必须只能指定其中一个 mode，运行起来之后，被指定的 mode 即为 currentMode。
CFRunLoopRunSpecific - 启动后具体如何 Run 的看此函数 - 源码 2601 行

/*
 * 指定mode运行runloop
 * @param rl 当前运行的runloop
 * @param modeName 需要运行的mode的name
 * @param seconds  runloop的超时时间
 * @param returnAfterSourceHandled 是否处理完事件就返回
 */
SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) {     /* DOES CALLOUT */
    CHECK_FOR_FORK();
    if (__CFRunLoopIsDeallocating(rl)) return kCFRunLoopRunFinished;
    __CFRunLoopLock(rl);
    //根据modeName找到本次运行的mode
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(rl, modeName, false);
    //如果没找到 || mode中没有注册任何事件，则就此停止，不进入循环
    if (NULL == currentMode || __CFRunLoopModeIsEmpty(rl, currentMode, rl->_currentMode)) {
        Boolean did = false;
        if (currentMode) __CFRunLoopModeUnlock(currentMode);
        __CFRunLoopUnlock(rl);
        return did ? kCFRunLoopRunHandledSource : kCFRunLoopRunFinished;
    }
    volatile _per_run_data *previousPerRun = __CFRunLoopPushPerRunData(rl);
    //取上一次运行的mode
    CFRunLoopModeRef previousMode = rl->_currentMode;
    //如果本次mode和上次的mode一致
    rl->_currentMode = currentMode;
    //初始化一个result为kCFRunLoopRunFinished
    int32_t result = kCFRunLoopRunFinished;
    
    // 1.通知observer即将进入runloop
    if (currentMode->_observerMask & kCFRunLoopEntry ) __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
    result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
    //10.通知observer已退出runloop
    if (currentMode->_observerMask & kCFRunLoopExit ) __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
    
    __CFRunLoopModeUnlock(currentMode);
    __CFRunLoopPopPerRunData(rl, previousPerRun);
    rl->_currentMode = previousMode;
    __CFRunLoopUnlock(rl);
    return result;
}

启动 RunLoop后具体如何 Run 起来的，通过 CFRunLoopRunSpecific 函数

传入的 mode 必须是一个存在的 mode 来运行 RunLoop，无则 run 失败
指定运行的 mode 中必须包含 modeItem，至少一个 modeItem，无则 RunLoop 不运行或者退出
在进入 run loop 之前通知observer，状态为 kCFRunLoopEntry
进入 run loop 之后调用了 __CFRunLoopRun 函数获取对应 RunLoop 状态
在退出run loop之后通知observer，状态为kCFRunLoopExit
__CFRunLoopRun - RunLoop 运行核心函数运行循环的整体步骤 - 源码中第 2308 行

/*
*  运行run loop
*  @param rl              运行的RunLoop对象
*  @param rlm             运行的mode
*  @param seconds         run loop超时时间
*  @param stopAfterHandle true:run loop处理完事件就退出  false:一直运行直到超时或者被手动终止
*  @param previousMode    上一次运行的mode
*  @return 返回4种状态
*/
static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode) {
    //获取系统启动后的CPU运行时间，用于控制超时时间
    uint64_t startTSR = mach_absolute_time();
    
    //如果RunLoop或者mode是stop状态，则直接return，不进入循环
    if (__CFRunLoopIsStopped(rl)) {
        __CFRunLoopUnsetStopped(rl);
        return kCFRunLoopRunStopped;
    } else if (rlm->_stopped) {
        rlm->_stopped = false;
        return kCFRunLoopRunStopped;
    }
    
    //mach端口，在内核中，消息在端口之间传递。 初始为0
    mach_port_name_t dispatchPort = MACH_PORT_NULL;
    //判断是否为主线程
    Boolean libdispatchQSafe = pthread_main_np() && ((HANDLE_DISPATCH_ON_BASE_INVOCATION_ONLY && NULL == previousMode) || (!HANDLE_DISPATCH_ON_BASE_INVOCATION_ONLY && 0 == _CFGetTSD(__CFTSDKeyIsInGCDMainQ)));
    //如果在主线程 && runloop是主线程的runloop && 该mode是commonMode，则给mach端口赋值为主线程收发消息的端口
    if (libdispatchQSafe && (CFRunLoopGetMain() == rl) && CFSetContainsValue(rl->_commonModes, rlm->_name)) dispatchPort = _dispatch_get_main_queue_port_4CF();
    
#if USE_DISPATCH_SOURCE_FOR_TIMERS
    mach_port_name_t modeQueuePort = MACH_PORT_NULL;
    if (rlm->_queue) {
        //mode赋值为dispatch端口_dispatch_runloop_root_queue_perform_4CF
        modeQueuePort = _dispatch_runloop_root_queue_get_port_4CF(rlm->_queue);
        if (!modeQueuePort) {
            CRASH("Unable to get port for run loop mode queue (%d)", -1);
        }
    }
#endif
    
    //GCD管理的定时器，用于实现runloop超时机制
    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;
    }
    //seconds为超时时间，超时时执行__CFRunLoopTimeout函数
    else if (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;
    }
    
    //标志位默认为true
    Boolean didDispatchPortLastTime = true;
    //记录最后runloop状态，用于return
    int32_t retVal = 0;
    do {
        //初始化一个存放内核消息的缓冲池
        uint8_t msg_buffer[3 * 1024];
#if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
        mach_msg_header_t *msg = NULL;
        mach_port_t livePort = MACH_PORT_NULL;
#elif DEPLOYMENT_TARGET_WINDOWS
        HANDLE livePort = NULL;
        Boolean windowsMessageReceived = false;
#endif
        //取所有需要监听的port
        __CFPortSet waitSet = rlm->_portSet;
        
        //设置RunLoop为可以被唤醒状态
        __CFRunLoopUnsetIgnoreWakeUps(rl);
        
        //2.通知observer，即将触发timer回调，处理timer事件
        if (rlm->_observerMask & kCFRunLoopBeforeTimers) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);
        //3.通知observer，即将触发Source0回调
        if (rlm->_observerMask & kCFRunLoopBeforeSources) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);
        
        //执行加入当前runloop的block
        __CFRunLoopDoBlocks(rl, rlm);
        
        //4.处理source0事件
        //有事件处理返回true，没有事件返回false
        Boolean sourceHandledThisLoop = __CFRunLoopDoSources0(rl, rlm, stopAfterHandle);
        if (sourceHandledThisLoop) {
            //执行加入当前runloop的block
            __CFRunLoopDoBlocks(rl, rlm);
        }
        
        //如果没有Sources0事件处理 并且 没有超时，poll为false
        //如果有Sources0事件处理 或者 超时，poll都为true
        Boolean poll = sourceHandledThisLoop || (0ULL == timeout_context->termTSR);
        
        //第一次do..whil循环不会走该分支，因为didDispatchPortLastTime初始化是true
        if (MACH_PORT_NULL != dispatchPort && !didDispatchPortLastTime) {
#if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
            //从缓冲区读取消息
            msg = (mach_msg_header_t *)msg_buffer;
            //5.接收dispatchPort端口的消息，（接收source1事件）
            if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0)) {
                //如果接收到了消息的话，前往第9步开始处理msg
                goto handle_msg;
            }
#elif DEPLOYMENT_TARGET_WINDOWS
            if (__CFRunLoopWaitForMultipleObjects(NULL, &dispatchPort, 0, 0, &livePort, NULL)) {
                goto handle_msg;
            }
#endif
        }
        
        didDispatchPortLastTime = false;
        
        //6.通知观察者RunLoop即将进入休眠
        if (!poll && (rlm->_observerMask & kCFRunLoopBeforeWaiting)) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);
        //设置RunLoop为休眠状态
        __CFRunLoopSetSleeping(rl);
        // do not do any user callouts after this point (after notifying of sleeping)
        
        // Must push the local-to-this-activation ports in on every loop
        // iteration, as this mode could be run re-entrantly and we don't
        // want these ports to get serviced.
        
        __CFPortSetInsert(dispatchPort, waitSet);
        
        __CFRunLoopModeUnlock(rlm);
        __CFRunLoopUnlock(rl);
        
#if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
#if USE_DISPATCH_SOURCE_FOR_TIMERS
        //这里有个内循环，用于接收等待端口的消息
        //进入此循环后，线程进入休眠，直到收到新消息才跳出该循环，继续执行run loop
        do {
            if (kCFUseCollectableAllocator) {
                objc_clear_stack(0);
                memset(msg_buffer, 0, sizeof(msg_buffer));
            }
            msg = (mach_msg_header_t *)msg_buffer;
            //7.接收waitSet端口的消息
            __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY);
            //收到消息之后，livePort的值为msg->msgh_local_port，
            if (modeQueuePort != MACH_PORT_NULL && livePort == modeQueuePort) {
                // Drain the internal queue. If one of the callout blocks sets the timerFired flag, break out and service the timer.
                while (_dispatch_runloop_root_queue_perform_4CF(rlm->_queue));
                if (rlm->_timerFired) {
                    // Leave livePort as the queue port, and service timers below
                    rlm->_timerFired = false;
                    break;
                } else {
                    if (msg && msg != (mach_msg_header_t *)msg_buffer) free(msg);
                }
            } else {
                // Go ahead and leave the inner loop.
                break;
            }
        } while (1);
#else
        if (kCFUseCollectableAllocator) {
            objc_clear_stack(0);
            memset(msg_buffer, 0, sizeof(msg_buffer));
        }
        msg = (mach_msg_header_t *)msg_buffer;
        __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY);
#endif
        
        
#elif DEPLOYMENT_TARGET_WINDOWS
        // Here, use the app-supplied message queue mask. They will set this if they are interested in having this run loop receive windows messages.
        __CFRunLoopWaitForMultipleObjects(waitSet, NULL, poll ? 0 : TIMEOUT_INFINITY, rlm->_msgQMask, &livePort, &windowsMessageReceived);
#endif
        
        __CFRunLoopLock(rl);
        __CFRunLoopModeLock(rlm);
        
        // Must remove the local-to-this-activation ports in on every loop
        // iteration, as this mode could be run re-entrantly and we don't
        // want these ports to get serviced. Also, we don't want them left
        // in there if this function returns.
        
        __CFPortSetRemove(dispatchPort, waitSet);
        
 
        __CFRunLoopSetIgnoreWakeUps(rl);
        
        // user callouts now OK again
        //取消runloop的休眠状态
        __CFRunLoopUnsetSleeping(rl);
        //8.通知观察者runloop被唤醒
        if (!poll && (rlm->_observerMask & kCFRunLoopAfterWaiting)) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);
      
        //9.处理收到的消息
    handle_msg:;
        __CFRunLoopSetIgnoreWakeUps(rl);
        
#if DEPLOYMENT_TARGET_WINDOWS
        if (windowsMessageReceived) {
            // These Win32 APIs cause a callout, so make sure we're unlocked first and relocked after
            __CFRunLoopModeUnlock(rlm);
            __CFRunLoopUnlock(rl);
            
            if (rlm->_msgPump) {
                rlm->_msgPump();
            } else {
                MSG msg;
                if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE | PM_NOYIELD)) {
                    TranslateMessage(&msg);
                    DispatchMessage(&msg);
                }
            }
            
            __CFRunLoopLock(rl);
            __CFRunLoopModeLock(rlm);
            sourceHandledThisLoop = true;
            
            // To prevent starvation of sources other than the message queue, we check again to see if any other sources need to be serviced
            // Use 0 for the mask so windows messages are ignored this time. Also use 0 for the timeout, because we're just checking to see if the things are signalled right now -- we will wait on them again later.
            // NOTE: Ignore the dispatch source (it's not in the wait set anymore) and also don't run the observers here since we are polling.
            __CFRunLoopSetSleeping(rl);
            __CFRunLoopModeUnlock(rlm);
            __CFRunLoopUnlock(rl);
            
            __CFRunLoopWaitForMultipleObjects(waitSet, NULL, 0, 0, &livePort, NULL);
            
            __CFRunLoopLock(rl);
            __CFRunLoopModeLock(rlm);
            __CFRunLoopUnsetSleeping(rl);
            // If we have a new live port then it will be handled below as normal
        }
        
        
#endif
        if (MACH_PORT_NULL == livePort) {
            CFRUNLOOP_WAKEUP_FOR_NOTHING();
            // handle nothing
            //通过CFRunloopWake唤醒
        } else if (livePort == rl->_wakeUpPort) {
            CFRUNLOOP_WAKEUP_FOR_WAKEUP();
            //什么都不干，跳回2重新循环
            // do nothing on Mac OS
#if DEPLOYMENT_TARGET_WINDOWS
            // Always reset the wake up port, or risk spinning forever
            ResetEvent(rl->_wakeUpPort);
#endif
        }
#if USE_DISPATCH_SOURCE_FOR_TIMERS
        //如果是定时器事件
        else if (modeQueuePort != MACH_PORT_NULL && livePort == modeQueuePort) {
            CFRUNLOOP_WAKEUP_FOR_TIMER();
            //9.1 处理timer事件
            if (!__CFRunLoopDoTimers(rl, rlm, mach_absolute_time())) {
                // Re-arm the next timer, because we apparently fired early
                __CFArmNextTimerInMode(rlm, rl);
            }
        }
#endif
#if USE_MK_TIMER_TOO
        //如果是定时器事件
        else if (rlm->_timerPort != MACH_PORT_NULL && livePort == rlm->_timerPort) {
            CFRUNLOOP_WAKEUP_FOR_TIMER();
            // On Windows, we have observed an issue where the timer port is set before the time which we requested it to be set. For example, we set the fire time to be TSR 167646765860, but it is actually observed firing at TSR 167646764145, which is 1715 ticks early. The result is that, when __CFRunLoopDoTimers checks to see if any of the run loop timers should be firing, it appears to be 'too early' for the next timer, and no timers are handled.
            // In this case, the timer port has been automatically reset (since it was returned from MsgWaitForMultipleObjectsEx), and if we do not re-arm it, then no timers will ever be serviced again unless something adjusts the timer list (e.g. adding or removing timers). The fix for the issue is to reset the timer here if CFRunLoopDoTimers did not handle a timer itself. 9308754
           //9.1处理timer事件
            if (!__CFRunLoopDoTimers(rl, rlm, mach_absolute_time())) {
                // Re-arm the next timer
                __CFArmNextTimerInMode(rlm, rl);
            }
        }
#endif
        //如果是dispatch到main queue的block
        else if (livePort == dispatchPort) {
            CFRUNLOOP_WAKEUP_FOR_DISPATCH();
            __CFRunLoopModeUnlock(rlm);
            __CFRunLoopUnlock(rl);
            _CFSetTSD(__CFTSDKeyIsInGCDMainQ, (void *)6, NULL);
#if DEPLOYMENT_TARGET_WINDOWS
            void *msg = 0;
#endif
            //9.2执行block
            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
            _CFSetTSD(__CFTSDKeyIsInGCDMainQ, (void *)0, NULL);
            __CFRunLoopLock(rl);
            __CFRunLoopModeLock(rlm);
            sourceHandledThisLoop = true;
            didDispatchPortLastTime = true;
        } else {
            CFRUNLOOP_WAKEUP_FOR_SOURCE();
            // Despite the name, this works for windows handles as well
            CFRunLoopSourceRef rls = __CFRunLoopModeFindSourceForMachPort(rl, rlm, livePort);
            // 有source1事件待处理
            if (rls) {
#if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
                mach_msg_header_t *reply = NULL;
                //9.2 处理source1事件
                sourceHandledThisLoop = __CFRunLoopDoSource1(rl, rlm, rls, msg, msg->msgh_size, &reply) || sourceHandledThisLoop;
                if (NULL != reply) {
                    (void)mach_msg(reply, MACH_SEND_MSG, reply->msgh_size, 0, MACH_PORT_NULL, 0, MACH_PORT_NULL);
                    CFAllocatorDeallocate(kCFAllocatorSystemDefault, reply);
                }
#elif DEPLOYMENT_TARGET_WINDOWS
                sourceHandledThisLoop = __CFRunLoopDoSource1(rl, rlm, rls) || sourceHandledThisLoop;
#endif
            }
        }
#if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
        if (msg && msg != (mach_msg_header_t *)msg_buffer) free(msg);
#endif
        
        __CFRunLoopDoBlocks(rl, rlm);
        
        if (sourceHandledThisLoop && stopAfterHandle) {
            //进入run loop时传入的参数，处理完事件就返回
            retVal = kCFRunLoopRunHandledSource;
        }else if (timeout_context->termTSR < mach_absolute_time()) {
            //run loop超时
            retVal = kCFRunLoopRunTimedOut;
        }else if (__CFRunLoopIsStopped(rl)) {
            //run loop被手动终止
            __CFRunLoopUnsetStopped(rl);
            retVal = kCFRunLoopRunStopped;
        }else if (rlm->_stopped) {
            //mode被终止
            rlm->_stopped = false;
            retVal = kCFRunLoopRunStopped;
        }else if (__CFRunLoopModeIsEmpty(rl, rlm, previousMode)) {
            //mode中没有要处理的事件
            retVal = kCFRunLoopRunFinished;
        }
        //除了上面这几种情况，都继续循环
    } while (0 == retVal);
    
    if (timeout_timer) {
        dispatch_source_cancel(timeout_timer);
        dispatch_release(timeout_timer);
    } else {
        free(timeout_context);
    }
    
    return retVal;
}

线程启动 runloop 运行循环核心逻辑 - “接收事件 - 等待休眠 - 唤醒 - 接收事件”，（多次尝试艹简书这里有bug，不能分 . ）
1. 此函数包含了运行循环原理解析的 2 ~ 9 步。
2. 当我们调用 GCD 计时器无需考虑 runloop，源码中可以看出苹果已经封装处理好了，而 NSTimer 需处理。
3. 运行循环原理步骤第 7 步，线程从"休眠 - 唤醒 "过程调用了 __CFRunLoopServiceMachPort 函数。

__CFRunLoopServiceMachPort - 第7步线程从"休眠 - 唤醒 "过程调用的函数 - 源码 2196 行

/**
 *  接收指定内核端口的消息
 *
 *  @param port        接收消息的端口
 *  @param buffer      消息缓冲区
 *  @param buffer_size 消息缓冲区大小
 *  @param livePort    暂且理解为活动的端口，接收消息成功时候值为msg->msgh_local_port，超时时为MACH_PORT_NULL
 *  @param timeout     超时时间，单位是ms，如果超时，则RunLoop进入休眠状态
 *
 *  @return 接收消息成功时返回true 其他情况返回false
 */
static Boolean __CFRunLoopServiceMachPort(mach_port_name_t port, mach_msg_header_t **buffer, size_t buffer_size, mach_port_t *livePort, mach_msg_timeout_t timeout) {
    Boolean originalBuffer = true;
    kern_return_t ret = KERN_SUCCESS;
    for (;;) {      /* In that sleep of death what nightmares may come ... */
        mach_msg_header_t *msg = (mach_msg_header_t *)*buffer;
        msg->msgh_bits = 0;  //消息头的标志位
        msg->msgh_local_port = port;  //源(发出的消息)或者目标(接收的消息)
        msg->msgh_remote_port = MACH_PORT_NULL; //目标(发出的消息)或者源(接收的消息)
        msg->msgh_size = buffer_size;  //消息缓冲区大小，单位是字节
        msg->msgh_id = 0;  //唯一id
       
        if (TIMEOUT_INFINITY == timeout) { CFRUNLOOP_SLEEP(); } else { CFRUNLOOP_POLL(); }
        
        //通过mach_msg发送或者接收的消息都是指针，
        //如果直接发送或者接收消息体，会频繁进行内存复制，损耗性能
        //所以XNU使用了单一内核的方式来解决该问题，所有内核组件都共享同一个地址空间，因此传递消息时候只需要传递消息的指针
        ret = mach_msg(msg,
                       MACH_RCV_MSG|MACH_RCV_LARGE|((TIMEOUT_INFINITY != timeout) ? MACH_RCV_TIMEOUT : 0)|MACH_RCV_TRAILER_TYPE(MACH_MSG_TRAILER_FORMAT_0)|MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_AV),
                       0,
                       msg->msgh_size,
                       port,
                       timeout,
                       MACH_PORT_NULL);
        CFRUNLOOP_WAKEUP(ret);
        
        //接收/发送消息成功，给livePort赋值为msgh_local_port
        if (MACH_MSG_SUCCESS == ret) {
            *livePort = msg ? msg->msgh_local_port : MACH_PORT_NULL;
            return true;
        }
        
        //MACH_RCV_TIMEOUT
        //超出timeout时间没有收到消息，返回MACH_RCV_TIMED_OUT
        //此时释放缓冲区，把livePort赋值为MACH_PORT_NULL
        if (MACH_RCV_TIMED_OUT == ret) {
            if (!originalBuffer) free(msg);
            *buffer = NULL;
            *livePort = MACH_PORT_NULL;
            return false;
        }
        
        //MACH_RCV_LARGE
        //如果接收缓冲区太小，则将过大的消息放在队列中，并且出错返回MACH_RCV_TOO_LARGE，
        //这种情况下，只返回消息头，调用者可以分配更多的内存
        if (MACH_RCV_TOO_LARGE != ret) break;
        //此处给buffer分配更大内存
        buffer_size = round_msg(msg->msgh_size + MAX_TRAILER_SIZE);
        if (originalBuffer) *buffer = NULL;
        originalBuffer = false;
        *buffer = realloc(*buffer, buffer_size);
    }
    HALT;
    return false;
}

Runloop - 运行循环原理概念性小结

无法直接创建 RunLoop 对象。每个线程，包括主线程都有唯一对应的一个RunLoop对象，相应函数获取线程下的 RunLoop 对象。
只有子线程的RunLoop需要手动启动，主线程的RunLoop在App启动时就已经运行了
RunLoop可以被手动唤醒。你可以在增加一个input source之后唤醒RunLoop以确保input source可以被立即执行，而不用等到RunLoop被其他事件唤醒。

RunLoop - 运行循环相应代码示例理解

场景一

新建工程在 Main.storyboard中添加一个 UITextView 控件；并在 VC 中添加一个 NSTimer的 timer 事件。

// demo 部分代码
- (void)viewDidLoad {
    [super viewDidLoad];
    
    NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerMethod) userInfo:nil repeats:YES];
    [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
}

- (void)timerMethod
{
    static int num = 0;
    NSLog(@"num%d%@",num++,[NSThread currentThread]);
}

运行demo分析：
一开始是执行 timer 的 timerMethod 方法，但当手指滑动 UITextView 时候会发现 timerMethod 方法不执行了，只要手指滑动事件一停止则 timer 事件timerMethod 方法继续执行。

主线程从程序一启动就默认已经开启了一个 RunLoop 循环，这也是主线程是一个常驻线程的原因，
这里 demo 主线程中存在一个 UITextView 的滑动事件（UI 交互事件）和一个 NSTimer 的 timer 事件，
RunLoop 运行循环默认是在 NSDefaultRunLoopModemode模式下处理事件，当滑动 UITextView 时候 RunLoop 则切换到 UITrackingRunLoopModemode 模式下处理 UI交互事件（用户体验至上 UI 交互事件永远是第一位，优先切换到这个到这个模式下），一旦 UI 交互事件停止则又切换到 default mode 模式下处理相应事件。

问题解决：
若要使得 NSTimer 的 timer 事件一直执行则将NSDefaultRunLoopMode替换为 NSRunLoopCommonModes：

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

场景二

针对场景一例子如果在 timer 事件 timerMethod 方法中添加一个耗时操作

- (void)viewDidLoad {
    [super viewDidLoad];
    
    NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerMethod) userInfo:nil repeats:YES];
    [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
}

- (void)timerMethod
{
    [NSThread sleepForTimeInterval:1.0];
    static int num = 0;
    NSLog(@"num%d%@",num++,[NSThread currentThread]);
}

运行 demo 分析：
在NSRunLoopCommonModes下线程是既处理了NSDefaultRunLoopMode的事件又处理UITrackingRunLoopMode，并且 timer 事件中还有一个耗时操作，因而当我们拖拽 UITextView 时候会卡顿

问题解决：
将 timer 耗时操作事件放到一个子线程处理，并且需要启动 RunLoop 运行循环保活子线程。

#import "ViewController.h"

@interface ViewController ()
@property (nonatomic, strong) NSTimer *time;
@property (nonatomic, assign) BOOL threadKilled;

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    NSThread *thread = [[NSThread alloc] initWithBlock: ^{  // 子线程特点：异步销毁
        NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerMethod) userInfo:nil repeats:YES];
        [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

        while (!_threadKilled) {
            
            [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.1]]; // 循环0.1 秒
        }
        // 开启子线程的runloop 循环后下面代码并不会走，原因就是上面运行循环已经是一个死循环
        NSLog(@"线程销毁%@",[NSThread currentThread]);
    }];

   [thread start];
}

- (void)timerMethod
{
    [NSThread sleepForTimeInterval:1.0];
    static int num = 0;
    NSLog(@"num%d%@",num++,[NSThread currentThread]);
}

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    // 点击销毁销毁子线程
    self.threadKilled = YES;
    NSLog(@"点击屏幕啦");
}

主线程的 RunLoop 无需我们添加代码启动，但是子线程的特点是异步销毁的，要保活一个子线程必须启动其 RunLoop 循环
- 子线程特点异步销毁，这里让控制器 VC 去强保活这个线程对象也是无效的。
- 多线程中线程常驻，并不是线程的 thread 对象常驻，因为它仅仅只是一个 OC 对象，并不是真的执行任务的线程，更不能代表线程，真正的多线程(线程池)管理是由 CPU调度(进程调度) 决定的， OC 对象没有销毁但是其实线程池中也许已经没有这个线程了。线程池概念链接和 CPU调度策略链接
线程之间处理任务独立的互不干扰，其各自的 RunLoop 也是独立的，在上面 mode 下处理事件也是互不干扰，自行切换。
子线程中 mode 模式类型 NSRunLoopCommonModes 和 NSDefaultRunLoopMode都有效，但是 UITrackingRunLoopMode mode 类型是无效的，子线程不能处理UI交互事件。
我们并不希望这个子线程永远销毁不了(可以自定义一个 thread 断点delloc方法测试)，通过一个外部 BOOL变量和 - (void)runUntilDate:(NSDate *)limitDate;方法去控制线程内事件循环
- (void)run; 启动处理事件循环，如果没有事件则立刻返回。注意：主线程上调用这个方法会导致无法返回后面所有方法不执行（进入无限循环，虽然不会阻塞主线程），因为主线程一般总是会有事件处理。
- (void)runUntilDate:(NSDate *)limitDate; 等同 run 方法，增加了超时参数limitDate，间隔 limitDate 时间循环避免进入无限循环。使用在UI线程（亦即主线程）上，可以达到暂停的效果。

RunLoop - API 详解及运用

.
.
.

Summarizes

备注

一个 Mode 可以将自己标记为”Common”属性（通过将其 ModeName 添加到 RunLoop 的 “commonModes” 中）。
RunLoop 会自动将 _commonModeItems 加入到具有 “Common” 标记的所有Mode里。应用场景举例：

主线程的 RunLoop 里有两个预置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。这两个 Mode 都已经被标记为”Common”属性。DefaultMode 是 App 平时所处的状态，TrackingRunLoopMode 是追踪 ScrollView 滑动时的状态。当你创建一个 Timer 并加到 DefaultMode 时，Timer 会得到重复回调，但此时滑动一个TableView时，RunLoop 会将 mode 切换为 TrackingRunLoopMode，这时 Timer 就不会被回调，并且也不会影响到滑动操作。
有时你需要一个 Timer，在两个 Mode 中都能得到回调，一种办法就是将这个 Timer 分别加入这两个 Mode。还有一种方式，就是将 Timer 加入到顶层的 RunLoop 的 “commonModeItems” 中。”commonModeItems” 被 RunLoop 自动更新到所有具有”Common”属性的 Mode 里去。有时你需要一个 Timer，在两个 Mode 中都能得到回调，一种办法就是将这个 Timer 分别加入这两个 Mode。还有一种方式，就是将 Timer 加入到顶层的 RunLoop 的 “commonModeItems” 中。”commonModeItems” 被 RunLoop 自动更新到所有具有”Common”属性的 Mode 里去。

iOS - RunLoop 底层源码详解及具体运用

iOS - RunLoop 底层源码详解及具体运用

前言

初识 RunLoop - 运行循环

RunLoop 的作用：

RunLoop - 具体是什么？

OSX/iOS 系统中，提供的两个 RunLoop 对象：

分析 CoreFoundation 库内的 RunLoop 源码分析

RunLoop

RunLoopMode - 运行模式

RunLoop Source - 事件源

CFRunLoopObserver - 观察者

CFRunLoopTimer

RunLoop 的层次结构及原理

Runloop 整体层次结构

RunLoop - 运行循环原理步骤解析

RunLoop - 运行循环步骤源码解析

Runloop - 运行循环原理概念性小结

RunLoop - 运行循环相应代码示例理解

场景一

场景二

RunLoop - API 详解及运用

Summarizes

备注

推荐阅读更多精彩内容

iOS - RunLoop 底层源码详解及具体运用

前言

初识 RunLoop - 运行循环

RunLoop 的作用：

RunLoop - 具体是什么？

OSX/iOS 系统中，提供的 两个 RunLoop 对象：

分析 CoreFoundation 库内的 RunLoop 源码分析

RunLoop

RunLoopMode - 运行模式

RunLoop Source - 事件源

CFRunLoopObserver - 观察者

CFRunLoopTimer

RunLoop 的层次结构及原理

Runloop 整体层次结构

RunLoop - 运行循环原理步骤解析

RunLoop - 运行循环步骤源码解析

Runloop - 运行循环原理概念性小结

RunLoop - 运行循环相应代码示例理解

场景 一

场景二

RunLoop - API 详解及运用

Summarizes

备注

推荐阅读更多精彩内容

OSX/iOS 系统中，提供的两个 RunLoop 对象：

场景一