iOS底层学习 - 深刻RunLoop

RunLoop这个名词对于iOS开发来讲应该是一个听腻了的词汇，并且只知其一不知其二，本篇章就来再深刻复习一下RunLoop

RunLoop简介

什么是RunLoop

通常来说，一个线程一次只能执行一个任务，执行完成后线程就会退出。若是咱们须要一个机制，让线程能随时处理事件但并不退出，这种模型一般被称做 Event Loop。 Event Loop 在不少系统和框架里都有实现，好比 Node.js 的事件处理，好比 Windows 程序的消息循环，再好比 OSX/iOS 里的 RunLoop。

实现这种模型的关键点在于：管理事件/消息，让线程在没有处理消息时休眠以免资源占用、在有消息到来时马上被唤醒。

RunLoop做用

1. 保持程序持续运行：程序一启动就会开一个主线程，主线程一开起来就会跑一个主线程对应的RunLoop,RunLoop保证主线程不会被销毁，也就保证了程序的持续运行
2. 处理App中的各类事件（好比：触摸事件，定时器事件，Selector事件等）
3. 节省CPU资源，提升程序性能：程序运行起来时，当什么操做都没有作的时候，RunLoop就告诉CPU，如今没有事情作，我要去休息，这时CPU就会将其资源释放出来去作其余的事情，当有事情作的时候RunLoop就会立马起来去作事情

咱们先经过API内一张图片来简单看一下RunLoop内部运行原理

为何使用RunLoop

了解了RunLoop的做用，那么在苹果系统中，为何使用RunLoop呢？主要有一下几点

1. 使程序一直运行，并接受用户输入
2. 决定程序在什么时候处理应该处理哪些Event
3. 调用解耦（Message Queue）: 好比一次滑屏事件，可能会触发多条消息，因此必须有一个相似Message Queue的模块去处理来解耦，造成一个队列来依次处理，这样用户的调用方和处理方实现了彻底解耦
4. 节省CPU的时间和效率

RunLoop底层原理

咱们仍是查看源码来进行探究

RunLoop代码层级

1. NSRunloop：最上层的NSRunloop层其实是对C语言实现的CFRunloop的一个封装，实际上它没干什么事，好比CFRunloop有一个过时时间是double类型，NSRunloop把它变味了NSDate类型；
2. CFRunloop：这是真正干事的一层，源代码是开源的，而且是跨平台的；
3. 系统层：底层实现用到了GCD，mach kernel是苹果的内核，好比runloop的睡眠和唤醒就是用mach kernel来实现的。

RunLoop入口

在OC代码中，Runloop是由系统默认开启的，就再main函数中，会开启主线程和RunLoop。若是没有Runloop，那么main函数执行完毕后，程序就退出了，这说明在UIApplicationMain函数中，开启了一个和主线程相关的RunLoop，致使UIApplicationMain不会返回，一直在运行中，也就保证了程序的持续运行。

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

接着咱们查看源码,发现CFRunLoopRun的底层实现结构也很是简单，就是一个do...while循环，咱们能够把RunLoop当作一个死循环。若是没有RunLoop，UIApplicationMain函数执行完毕以后将直接返回，也就没有程序持续运行一说了。

void CFRunLoopRun(void) {    /* DOES CALLOUT */
    int32_t result;
    do {
        result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
        CHECK_FOR_FORK();
    } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
}
复制代码

RunLoop与线程的关系

首先，iOS 开发中能遇到两个线程对象: pthread_t 和 NSThread。过去苹果有份文档标明了 NSThread只是 pthread_t 的封装，但那份文档已经失效了，如今它们也有可能都是直接包装自最底层的 mach thread。苹果并无提供这两个对象相互转换的接口，但无论怎么样，能够确定的是 pthread_t 和 NSThread 是一一对应的。好比，你能够经过 pthread_main_thread_np() 或 [NSThread mainThread] 来获取主线程；也能够经过 pthread_self() 或 [NSThread currentThread] 来获取当前线程。CFRunLoop 是基于 pthread 来管理的。

苹果不容许直接建立 RunLoop，它只提供了两个自动获取的函数：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 这两个函数内部的逻辑大概是下面这样:

✅// 得到当前线程的RunLoop对象，内部调用_CFRunLoopGet0函数
CFRunLoopRef CFRunLoopGetCurrent(void) {
    CHECK_FOR_FORK();
    CFRunLoopRef rl = (CFRunLoopRef)_CFGetTSD(__CFTSDKeyRunLoop);
    if (rl) return rl;
    return _CFRunLoopGet0(pthread_self());
}

✅// 查看_CFRunLoopGet0方法
CF_EXPORT CFRunLoopRef _CFRunLoopGet0(pthread_t t) {
    ✅// 若是为空则t设置为主线程
    if (pthread_equal(t, kNilPthreadT)) {
    t = pthread_main_thread_np();
    }
    __CFLock(&loopsLock);
    ✅// 若是不存在runloop，则建立
    if (!__CFRunLoops) {
        __CFUnlock(&loopsLock);
    CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks);
    ✅// 根据传入的主线程获取主线程对应的RunLoop
    CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np());
    ✅// 保存主线程 将主线程-key和RunLoop-Value保存到字典中
    CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop);
    if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) {
        CFRelease(dict);
    }
    CFRelease(mainLoop);
        __CFLock(&loopsLock);
    }
    
    ✅// 从字典里面拿，将线程做为key从字典里获取一个loop
    CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
    __CFUnlock(&loopsLock);
    
    ✅// 若是loop为空，则建立一个新的loop，因此runloop会在第一次获取的时候建立
    if (!loop) {  
    CFRunLoopRef newLoop = __CFRunLoopCreate(t);
        __CFLock(&loopsLock);
    loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
    
    ✅// 建立好以后，以线程为key runloop为value，一对一存储在字典中，下次获取的时候，则直接返回字典内的runloop
    if (!loop) { 
        CFDictionarySetValue(__CFRunLoops, pthreadPointer(t), newLoop);
        loop = newLoop;
    }
        // do not release run loops inside the loopsLock, because CFRunLoopDeallocate may end up taking it
        __CFUnlock(&loopsLock);
    ✅//线程结束是销毁loop
    CFRelease(newLoop);
    }
    ✅// 若是传入线程和当前线程相同
    if (pthread_equal(t, pthread_self())) {
        ✅// 注册一个回调，当线程销毁时，顺便也销毁对应的RunLoop
        _CFSetTSD(__CFTSDKeyRunLoop, (void *)loop, NULL);
        if (0 == _CFGetTSD(__CFTSDKeyRunLoopCntr)) {
            _CFSetTSD(__CFTSDKeyRunLoopCntr, (void *)(PTHREAD_DESTRUCTOR_ITERATIONS-1), (void (*)(void *))__CFFinalizeRunLoop);
        }
    }
    return loop;
}
复制代码

经过源码分析能够看出，线程和RunLoop之间是一一对应的，其关系是保存在一个Dictionary字典里。因此咱们建立子线程RunLoop时，只需在子线程中获取当前线程的RunLoop对象便可[NSRunLoop currentRunLoop];。若是不获取，那子线程就不会建立与之相关联的RunLoop，而且只能在一个线程的内部获取其RunLoop。

当经过调用[NSRunLoop currentRunLoop];方法获取RunLoop时，会先看一下字典里有没有子线程对应的RunLoop，若是有则直接返回RunLoop，若是没有则会建立一个，并将与之对应的子线程存入字典中。当线程结束时，RunLoop会被销毁。

总结一下Runloop与线程的关系

1. 每条线程都有惟一的一个与之对应的RunLoop对象
2. RunLoop保存在一个全局的Dictionary里，线程做为key,RunLoop做为value
3. 主线程的RunLoop已经自动建立好了，子线程的RunLoop须要主动建立
4. RunLoop在第一次获取时建立，在线程结束时销毁

RunLoop底层结构

CFRunLoopRef

经过源码咱们找到__CFRunLoop结构体

typedef struct __CFRunLoop * CFRunLoopRef;

struct __CFRunLoop
{
    // CoreFoundation 中的 runtime 基础信息
    CFRuntimeBase _base;
    // 针对获取 mode 列表操做的锁
    pthread_mutex_t _lock; /* locked for accessing mode list */
    // 唤醒端口
    __CFPort _wakeUpPort;  // used for CFRunLoopWakeUp
    // 是否使用过
    Boolean _unused;
    // runloop 运行会重置的一个数据结构
    volatile _per_run_data *_perRunData; // reset for runs of the run loop
    // runloop 所对应线程
    pthread_t _pthread;
    uint32_t _winthread;
    // 存放 common mode 的集合
    CFMutableSetRef _commonModes;
    // 存放 common mode item 的集合
    CFMutableSetRef _commonModeItems;
    // runloop 当前所在 mode
    CFRunLoopModeRef _currentMode;
    // 存放 mode 的集合
    CFMutableSetRef _modes;
    
    // runloop 内部 block 链表表头指针
    struct _block_item *_blocks_head;
    // runloop 内部 block 链表表尾指针
    struct _block_item *_blocks_tail;
    // 运行时间点
    CFAbsoluteTime _runTime;
    // 休眠时间点
    CFAbsoluteTime _sleepTime;
    CFTypeRef _counterpart;
};

// 每次 RunLoop 运行后会重置
typedef struct _per_run_data
{
    uint32_t a;
    uint32_t b;
    uint32_t stopped;   // runloop 是否中止
    uint32_t ignoreWakeUps; // runloop 是否已唤醒
} _per_run_data;

// 链表节点
struct _block_item
{
    // 指向下一个 _block_item
    struct _block_item *_next;
    // 要么是 string 类型，要么是集合类型，也就是说一个 block 可能对应单个或多个 mode
    CFTypeRef _mode; // CFString or CFSet
    // 存放的真正要执行的 block
    void (^_block)(void);
};

};
复制代码

经过查看RunLoop的底层结构，咱们发现了RunLoop也是一个结构体对象，其中有几个主要的变量：

• CFRunLoopModeRef _currentMode:runloop 当前所在 mode
• CFMutableSetRef _modes:存放 mode 的集合

经过上述变量，咱们能够知道:

• RunLoop能够有多个mode对象
• Runloop在同一时间只能且必须在某一种特定的Mode下面Run，更换Mode时，必需要中止当前的Loop，而后重启新的Loop，重启的意思是退出当前的while循环，而后从新设置一个新的while

CFRunLoopModeRef

CFRunLoopModeRef 实际上是指向__CFRunLoopMode结构体的指针，__CFRunLoopMode结构体源码以下

typedef struct __CFRunLoopMode *CFRunLoopModeRef;

struct __CFRunLoopMode
{
    // CoreFoundation 中的 runtime 基础信息
    CFRuntimeBase _base;
    // 互斥锁，加锁前须要 runloop 先加锁
    pthread_mutex_t _lock; /* must have the run loop locked before locking this */
    // mode 的名称
    CFStringRef _name;
    // mode 是否中止
    Boolean _stopped;
    char _padding[3];
    // source0
    CFMutableSetRef _sources0;
    // source1
    CFMutableSetRef _sources1;
    // observers
    CFMutableArrayRef _observers;
    // timers
    CFMutableArrayRef _timers;
    CFMutableDictionaryRef _portToV1SourceMap;
    // port 的集合
    __CFPortSet _portSet;
    // observer 的 mask
    CFIndex _observerMask;
    // 若是定义了 GCD 定时器
#if USE_DISPATCH_SOURCE_FOR_TIMERS
    // GCD 定时器
    dispatch_source_t _timerSource;
    // 队列
    dispatch_queue_t _queue;
    // 当 GCD 定时器触发时设置为 true
    Boolean _timerFired; // set to true by the source when a timer has fired
    Boolean _dispatchTimerArmed;
#endif
// 若是使用 MK_TIMER
#if USE_MK_TIMER_TOO
    // MK_TIMER 的 port
    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 */
};

复制代码

咱们发现，一个CFRunLoopModeRef也包含不少变量，主要有_sources0,_sources0两个集合和_observers,_timers两个数组。

这说明一个mode能够包含多种items模式

CFRunLoopSourceRef

CFRunLoopSourceRef是事件源（输入源）。经过源码能够发现，其分为source0和source1两个。

• source0：处理App内部事件，App本身负责管理（触发），如UIEvent，CFSocket等；
• source1：由Runloop和内核管理，mach port驱动，如CFMachPort（轻量级的进程间通讯的方式，NSPort就是对它的封装，还有Runloop的睡眠和唤醒就是经过它来作的），CFMessagePort；

typedef struct __CFRunLoopSource * CFRunLoopSourceRef;

struct __CFRunLoopSource
{
    // CoreFoundation 中的 runtime 基础信息
    CFRuntimeBase _base;
    uint32_t _bits;
    // 互斥锁
    pthread_mutex_t _lock;
    // source 的优先级，值为小，优先级越高
    CFIndex _order; /* immutable */
    // runloop 集合
    CFMutableBagRef _runLoops;
    // 一个联合体，说明 source 要么为 source0，要么为 source1
    union {
        CFRunLoopSourceContext version0;  /* immutable, except invalidation */
        CFRunLoopSourceContext1 version1; /* immutable, except invalidation */
    } _context;
};

typedef struct {
    CFIndex version;
    // source 的信息
    void *  info;
    const void *(*retain)(const void *info);
    void    (*release)(const void *info);
    CFStringRef (*copyDescription)(const void *info);
    // 判断 source 相等的函数
    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);
    // source 要执行的任务块
    void    (*perform)(void *info);
} CFRunLoopSourceContext;

复制代码

CFRunLoopObserverRef

CFRunLoopObserverRef是观察者，每一个Observer都包含了一个回调(函数指针)，当RunLoop的状态发生变化时，观察者就能经过回调接受到这个变化。主要是用来向外界报告Runloop当前的状态的更改。

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry = (1UL << 0),// 即将进入Loop
    kCFRunLoopBeforeTimers = (1UL << 1),// 即将处理Timer
    kCFRunLoopBeforeSources = (1UL << 2),// 即将处理Source
    kCFRunLoopBeforeWaiting = (1UL << 5),// 即将进入休眠
    kCFRunLoopAfterWaiting = (1UL << 6),// 刚从休眠中唤醒
    kCFRunLoopExit = (1UL << 7),// 即将退出Loop
    kCFRunLoopAllActivities = 0x0FFFFFFFU // 全部事件
};
复制代码

typedef struct __CFRunLoopObserver * CFRunLoopObserverRef;

struct __CFRunLoopObserver
{
    // CoreFoundation 中的 runtime 基础信息
    CFRuntimeBase _base;
    // 互斥锁
    pthread_mutex_t _lock;
    // observer 对应的 runloop
    CFRunLoopRef _runLoop;
    // observer 观察了多少个 runloop
    CFIndex _rlCount;
    CFOptionFlags _activities;          /* immutable */
    // observer 优先级
    CFIndex _order;                     /* immutable */
    // observer 回调函数
    CFRunLoopObserverCallBack _callout; /* immutable */
    // observer 上下文
    CFRunLoopObserverContext _context;  /* immutable, except invalidation */
};

typedef struct {
    CFIndex	version;
    void *	info;
    const void *(*retain)(const void *info);
    void	(*release)(const void *info);
    CFStringRef	(*copyDescription)(const void *info);
} CFRunLoopObserverContext;

typedef void (*CFRunLoopObserverCallBack)(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info);

复制代码

CFRunLoopTimerRef

CFRunLoopTimerRef 是基于时间的触发器，它和NSTimer是toll-free bridged的，能够混用。其包含一个时间长度和一个回调(函数指针)。

当其加入到RunLoop时，RunLoop会注册对应的时间点，当时间点到时，RunLoop会被唤醒以执行那个回调。

总结一下关于RunLoop的结构

1. RunLoop本质也是一个结构体对象
2. RunloopMode是指的一个事件循环必须在某种模式下跑，系统会预约义几个模式。一个Runloop有多个Mode；
3. CFRunloopSource，CFRunloopTimer，CFRunloopObserver这些元素是在Mode里面的，Mode与这些元素的对应关系也是1对多的。可是必须至少有一个Source或者Timer，由于若是Mode为空，RunLoop运行到空模式不会进行空转，就会马上退出。
4. CFRunloopSource分为source0(处理用户事件)和source1(处理内核事件)
5. CFRunloopObserver是监听和通知Runloop状态

   

RunLoop的Mode

RunLoop 有五种运行模式，其中常见的有1.2两种。

1. kCFRunLoopDefaultMode：App的默认Mode，一般主线程是在这个Mode下运行
2. UITrackingRunLoopMode：界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其余 Mode 影响
3. UIInitializationRunLoopMode: 在刚启动 App 时第进入的第一个 Mode，启动完成后就再也不使用，会切换到kCFRunLoopDefaultMode
4. GSEventReceiveRunLoopMode: 接受系统事件的内部 Mode，一般用不到
5. kCFRunLoopCommonModes: 这是一个占位用的Mode，做为标记kCFRunLoopDefaultMode和UITrackingRunLoopMode用，并非一种真正的Mode 
复制代码

Mode间的切换

咱们平时在开发中必定遇到过，当咱们使用NSTimer每一段时间执行一些事情时滑动UIScrollView，NSTimer就会暂停，当咱们中止滑动之后，NSTimer又会从新恢复的状况，这是因为RunloopMode必须在同一个模式下跑。

主线程的 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 里去。

一个 Mode 能够将本身标记为”Common”属性（经过将其 ModeName 添加到 RunLoop 的 “commonModes” 中）。每当 RunLoop 的内容发生变化时，RunLoop 都会自动将 _commonModeItems 里的 Source/Observer/Timer 同步到具备 “Common” 标记的全部Mode里。

RunLoop启动逻辑

咱们知道在main函数启动时，会有Runloop的用DefaultMode默认启动和使用指定Mode进行启动，相关的源码以下，能够发现，其核心逻辑都是调用了CFRunLoopRunSpecific函数

/// 用DefaultMode启动
void CFRunLoopRun(void) {   /* DOES CALLOUT */
    int32_t result;
    do {
        result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
        CHECK_FOR_FORK();
    } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
}
/// 用指定的Mode启动，并容许设置RunLoop的超时时间
SInt32 CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) {     /* DOES CALLOUT */
    CHECK_FOR_FORK();
    return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}
复制代码

CFRunLoopRunSpecific

接着咱们查看CFRunLoopRunSpecific函数，根据其代码，主要总结为如下几个步骤：

• 从 runloop 中查找给定的 mode
• 将查找到的 mode 赋值到 runloop 的 _curentMode，也就是说在这 runloop 完成了 mode 的切换
• 调用核心函数 __CFRunLoopRun
• 若是注册了 observer，则通知runloop的开启，运行，结束等状态

SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled)
{ /* DOES CALLOUT */
    CHECK_FOR_FORK();
    // 若是 runloop 正在回收中，直接返回 kCFRunLoopRunFinished ，表示 runloop 已经完成
    if (__CFRunLoopIsDeallocating(rl))
        return kCFRunLoopRunFinished;
    // 对 runloop 加锁
    __CFRunLoopLock(rl);
    ✅// 从 runloop 中查找给定的 mode
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(rl, modeName, false);
    ✅// 若是找不到 mode，且当前 runloop 的 currentMode 也为空，进入 if 逻辑
    // __CFRunLoopModeIsEmpty 函数结果为空的话，说明 runloop 已经处理完全部任务
    if (NULL == currentMode || __CFRunLoopModeIsEmpty(rl, currentMode, rl->_currentMode))
    {
        Boolean did = false;
        // 若是 currentMode 不为空
        if (currentMode)
            // 对 currentMode 解锁
            __CFRunLoopModeUnlock(currentMode);
        // 对 runloop 解锁
        __CFRunLoopUnlock(rl);
        return did ? kCFRunLoopRunHandledSource : kCFRunLoopRunFinished;
    }
    // 暂时取出 runloop 的 per_run_data
    volatile _per_run_data *previousPerRun = __CFRunLoopPushPerRunData(rl);
    ✅// 取出 runloop 的当前 mode
    CFRunLoopModeRef previousMode = rl->_currentMode;
    ✅// 将查找到的 mode 赋值到 runloop 的 _curentMode，也就是说在这 runloop 完成了 mode 的切换
    rl->_currentMode = currentMode;
    ✅// 初始化返回结果 result
    int32_t result = kCFRunLoopRunFinished;

    ✅// 若是注册了 observer 监听 kCFRunLoopEntry 状态(即将进入 loop)，则通知 observer
    if (currentMode->_observerMask & kCFRunLoopEntry)
        __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
    ✅✅✅✅// runloop 核心函数 __CFRunLoopRun
    result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
    ✅// 若是注册了 observer 监听 kCFRunLoopExit 状态(即将推出 loop)，则通知 observer
    if (currentMode->_observerMask & kCFRunLoopExit)
        __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
    // 对 currentMode 解锁
    __CFRunLoopModeUnlock(currentMode);
    // 还原原来的 previousPerRun
    __CFRunLoopPopPerRunData(rl, previousPerRun);
    // 还原原来的 mode
    rl->_currentMode = previousMode;
    // 对 runloop 解锁
    __CFRunLoopUnlock(rl);
    return result;
}
复制代码

CFRunLoopRun

CFRunLoopRun是RunLoop的核心函数，一次运行循环就是一次 CFRunLoopRun 的运行。其5个参数分别表明的意义以下：

• CFRunLoopRef rl: CFRunLoopRef 对象
• CFRunLoopModeRef rlm: mode 的名称
• CFTimeInterval seconds: 超时时间
• Boolean stopAfterHandle: 处理完 source 后是否直接返回
• CFRunLoopModeRef previousMode: 前一次运行循环的 mode

static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode)
复制代码

因为CFRunLoopRun的函数过长，逻辑比较复杂，因此咱们精简了代码，只讲解其中的一些的核心逻辑，主要有如下几个步骤：

1. 使用dispatch_source_t建立一个定时器来处理超时相关的逻辑，若是没设置会默认一个特别大的数字
2. 启动do...while循环开始处理事件
3. 通知 Observers: RunLoop 即将触发 Timer 回调。
4. 通知 Observers: RunLoop 即将触发 Source0 (非port) 回调。
5. 执行被加入的block
6. 若是有 Source1 (基于port) 处于 ready 状态，直接处理这个 Source1 而后跳转去处理消息。
7. 通知 Observers: RunLoop 的线程即将进入休眠(sleep)。
8. 调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。
   • 基于 port 的 Source 事件；
   • Timer 时间到；
   • RunLoop 自身的超时时间到了
   • 被其余什么调用者手动唤醒
9. 通知 Observers: RunLoop 的线程刚刚被唤醒了。
10. 收到消息，处理消息。
    • 若是一个 Timer 到时间了，触发这个Timer的回调。
    • 若是有dispatch到main_queue的block，执行block。
    • 若是一个 Source1 (基于port) 发出事件了，处理这个事件
11. 执行加入到Loop的block
12. 根据当前 RunLoop 的状态来判断是否须要走下一个 loop。当被外部强制中止或 loop 超时时，就不继续下一个 loop 了，不然继续走下一个 loop 。

static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode)
{
     // 声明一个空的 GCD 定时器
    dispatch_source_t timeout_timer = NULL;
    // 初始化一个 「超时上下文」 结构体指针对象
    struct __timeout_context *timeout_context = (struct __timeout_context *)malloc(sizeof(*timeout_context));
    ...
    
    int32_t retVal = 0;
    do
    {
        // 通知 Observers 即将处理 Timers
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);
        
        // 通知 Observers 即将处理 Sources
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);

        // 处理 Blocks
        __CFRunLoopDoBlocks(rl, rlm);

        // 处理 Source0
        if (__CFRunLoopDoSources0(rl, rlm, stopAfterHandle))
        {
            // 处理 Blocks
            __CFRunLoopDoBlocks(rl, rlm);
        }

        Boolean poll = sourceHandledThisLoop || (0ULL == timeout_context->termTSR);

        // 判断有无 Source1
        if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL))
        {
            // 若是有 Source1，就跳转到 handle_msg
            goto handle_msg;
        }

            
        didDispatchPortLastTime = false;

        // 通知 Observers 即将休眠
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);
            
        __CFRunLoopSetSleeping(rl);

        CFAbsoluteTime sleepStart = poll ? 0.0 : CFAbsoluteTimeGetCurrent();
        
        do
        {
            if (kCFUseCollectableAllocator)
            {
                // objc_clear_stack(0);
                // <rdar://problem/16393959>
                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, &voucherState, &voucherCopy);

            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);

        // user callouts now OK again
        __CFRunLoopUnsetSleeping(rl);
        
        // 通知 Observers 结束休眠
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);

    handle_msg:
        if (被 timer 唤醒)
        {
            // 处理 timers
            __CFRunLoopDoTimers(rl, rlm, mach_absolute_time());
        }

        else if (被 GCD 唤醒)
        {
            // 处理 GCD 主队列
            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
        }
        else
        {
            // 被 Source1 唤醒
            __CFRunLoopDoSource1(rl, rlm, rls, msg, msg->msgh_size, &reply) || sourceHandledThisLoop;
        }

        // 处理 Blocks
        __CFRunLoopDoBlocks(rl, rlm);

        if (sourceHandledThisLoop && stopAfterHandle)
        {
            retVal = kCFRunLoopRunHandledSource;
        }
        else if (timeout_context->termTSR < mach_absolute_time())
        {
            retVal = kCFRunLoopRunTimedOut;
        }
        else if (__CFRunLoopIsStopped(rl))
        {
            __CFRunLoopUnsetStopped(rl);
            retVal = kCFRunLoopRunStopped;
        }
        else if (rlm->_stopped)
        {
            rlm->_stopped = false;
            retVal = kCFRunLoopRunStopped;
        }
        else if (__CFRunLoopModeIsEmpty(rl, rlm, previousMode))
        {
            retVal = kCFRunLoopRunFinished;
        }

        voucher_mach_msg_revert(voucherState);
        os_release(voucherCopy);

    } while (0 == retVal);

    return retVal;
}

复制代码

RunLoop的退出

1. 主线程销毁RunLoop退出
2. Mode中有一些Timer 、Source、 Observer，这些保证Mode不为空时保证RunLoop没有空转而且是在运行的，当Mode中为空的时候，RunLoop会马上退出
3. 咱们在启动RunLoop的时候能够设置何时中止

[NSRunLoop currentRunLoop]runUntilDate:<#(nonnull NSDate *)#>
[NSRunLoop currentRunLoop]runMode:<#(nonnull NSString *)#> beforeDate:<#(nonnull NSDate *)#>
复制代码

RunLoop的应用

RunLoop在系统中的应用

AutoreleasePool

App启动后，苹果在主线程 RunLoop 里注册了两个 Observer，其回调都是 _wrapRunLoopWithAutoreleasePoolHandler()。

第一个 Observer 监视的事件是Entry(即将进入Loop)，其回调内会调用 _objc_autoreleasePoolPush() 建立自动释放池。其 order 是-2147483647，优先级最高，保证建立释放池发生在其余全部回调以前。

第二个 Observer 监视了两个事件： BeforeWaiting(准备进入休眠) 时调用_objc_autoreleasePoolPop() 和_objc_autoreleasePoolPush() 释放旧的池并建立新池；Exit(即将退出Loop) 时调用 _objc_autoreleasePoolPop() 来释放自动释放池。这个 Observer 的 order 是 2147483647，优先级最低，保证其释放池子发生在其余全部回调以后。

在主线程执行的代码，一般是写在诸如事件回调、Timer回调内的。这些回调会被 RunLoop 建立好的 AutoreleasePool 环绕着，因此不会出现内存泄漏，开发者也没必要显示建立 Pool 了。

事件响应

苹果注册了一个 Source1 (基于 mach port 的) 用来接收系统事件，其回调函数为 __IOHIDEventSystemClientQueueCallback()。

当一个硬件事件(触摸/锁屏/摇晃等)发生后，首先由 IOKit.framework 生成一个 IOHIDEvent 事件并由SpringBoard 接收。这个过程的详细状况能够参考这里。SpringBoard 只接收按键(锁屏/静音等)，触摸，加速，接近传感器等几种 Event，随后用 mach port 转发给须要的App进程。随后苹果注册的那个 Source1 就会触发回调，并调用 _UIApplicationHandleEventQueue() 进行应用内部的分发。

_UIApplicationHandleEventQueue() 会把IOHIDEvent 处理并包装成 UIEvent 进行处理或分发，其中包括识别 UIGesture/处理屏幕旋转/发送给 UIWindow 等。一般事件好比 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的。

手势识别

当上面的 _UIApplicationHandleEventQueue() 识别了一个手势时，其首先会调用 Cancel 将当前的 touchesBegin/Move/End 系列回调打断。随后系统将对应的 UIGestureRecognizer 标记为待处理。

苹果注册了一个 Observer 监测 BeforeWaiting (Loop即将进入休眠) 事件，这个Observer的回调函数是 _UIGestureRecognizerUpdateObserver()，其内部会获取全部刚被标记为待处理的 GestureRecognizer，并执行GestureRecognizer的回调。

当有 UIGestureRecognizer 的变化(建立/销毁/状态改变)时，这个回调都会进行相应处理。

界面更新

当在操做 UI 时，好比改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer 就被标记为待处理，并被提交到一个全局的容器去。

苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件，回调去执行一个很长的函数： _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历全部待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。

这个函数内部的调用栈大概是这样的：

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
    QuartzCore:CA::Transaction::observer_callback:
        CA::Transaction::commit();
            CA::Context::commit_transaction();
                CA::Layer::layout_and_display_if_needed();
                    CA::Layer::layout_if_needed();
                        [CALayer layoutSublayers];
                            [UIView layoutSubviews];
                    CA::Layer::display_if_needed();
                        [CALayer display];
                            [UIView drawRect];
复制代码

定时器

NSTimer 其实就是 CFRunLoopTimerRef，他们之间是 toll-free bridged 的。一个 NSTimer 注册到 RunLoop 后，RunLoop 会为其重复的时间点注册好事件。例如 10:00, 10:10, 10:20 这几个时间点。RunLoop为了节省资源，并不会在很是准确的时间点回调这个Timer。Timer 有个属性叫作 Tolerance (宽容度)，标示了当时间点到后，允许有多少最大偏差。

若是某个时间点被错过了，例如执行了一个很长的任务，则那个时间点的回调也会跳过去，不会延后执行。就好比等公交，若是 10:10 时我忙着玩手机错过了那个点的公交，那我只能等 10:20 这一趟了。

CADisplayLink 是一个和屏幕刷新率一致的定时器（但实际实现原理更复杂，和 NSTimer 并不同，其内部实际是操做了一个 Source）。若是在两次屏幕刷新之间执行了一个长任务，那其中就会有一帧被跳过去（和 NSTimer 类似），形成界面卡顿的感受。在快速滑动TableView时，即便一帧的卡顿也会让用户有所察觉。Facebook 开源的 AsyncDisplayLink 就是为了解决界面卡顿的问题，其内部也用到了 RunLoop.

PerformSelecter

当调用 NSObject 的 performSelecter:afterDelay: 后，实际上其内部会建立一个 Timer 并添加到当前线程的 RunLoop 中。因此若是当前线程没有 RunLoop，则这个方法会失效。

当调用 performSelector:onThread: 时，实际上其会建立一个 Timer 加到对应的线程去，一样的，若是对应线程没有 RunLoop 该方法也会失效。

关于GCD

实际上 RunLoop 底层也会用到 GCD 的东西，NSTimer 是用了 XNU 内核的 mk_timer，我也仔细调试了一下，发现 NSTimer 确实是由 mk_timer 驱动，而非 GCD 驱动的）。但同时 GCD 提供的某些接口也用到了 RunLoop， 例如 dispatch_async()。

当调用 dispatch_async(dispatch_get_main_queue(), block) 时，libDispatch 会向主线程的 RunLoop 发送消息，RunLoop会被唤醒，并从消息中取得这个 block，并在回调 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里执行这个 block。但这个逻辑仅限于 dispatch 到主线程，dispatch 到其余线程仍然是由 libDispatch 处理的。

关于网络请求

iOS 中，关于网络请求的接口自下至上有以下几层:

CFSocket
CFNetwork       ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession    ->AFNetworking2, Alamofire
复制代码

• CFSocket 是最底层的接口，只负责 socket 通讯。
• CFNetwork 是基于 CFSocket 等接口的上层封装，ASIHttpRequest 工做于这一层。
• NSURLConnection 是基于 CFNetwork 的更高层的封装，提供面向对象的接口，AFNetworking 工做于这一层。
• NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 并列的，但底层仍然用到了 NSURLConnection 的部分功能 (好比 com.apple.NSURLConnectionLoader 线程)，AFNetworking2 和 Alamofire 工做于这一层。

下面主要介绍下 NSURLConnection 的工做过程。

一般使用 NSURLConnection 时，你会传入一个 Delegate，当调用了 [connection start] 后，这个 Delegate 就会不停收到事件回调。实际上，start 这个函数的内部会会获取 CurrentRunLoop，而后在其中的 DefaultMode 添加了4个 Source0 (即须要手动触发的Source)。

CFMultiplexerSource 是负责各类 Delegate 回调的，

CFHTTPCookieStorage是处理各类 Cookie 的。

当开始网络传输时，咱们能够看到 NSURLConnection 建立了两个新线程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 线程是处理底层 socket 链接的。NSURLConnectionLoader这个线程内部会使用 RunLoop 来接收底层 socket 的事件，并经过以前添加的 Source0通知到上层的 Delegate。

RunLoop在实际开发中的应用

AFNetworking

AFURLConnectionOperation 这个类是基于 NSURLConnection 构建的，其但愿能在后台线程接收 Delegate 回调。为此 AFNetworking 单首创建了一个线程，并在这个线程中启动了一个 RunLoop：

+ (void)networkRequestThreadEntryPoint:(id)__unused object {
    @autoreleasepool {
        [[NSThread currentThread] setName:@"AFNetworking"];
        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        [runLoop run];
    }
}
 
+ (NSThread *)networkRequestThread {
    static NSThread *_networkRequestThread = nil;
    static dispatch_once_t oncePredicate;
    dispatch_once(&oncePredicate, ^{
        _networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
        [_networkRequestThread start];
    });
    return _networkRequestThread;
}
复制代码

RunLoop 启动前内部必需要有至少一个Timer/Observer/Source，因此 AFNetworking 在 [runLoop run] 以前先建立了一个新的 NSMachPort 添加进去了。一般状况下，调用者须要持有这个 NSMachPort (mach_port) 并在外部线程经过这个 port 发送消息到 loop 内；但此处添加 port 只是为了让 RunLoop 不至于退出，并无用于实际的发送消息。

- (void)start {
    [self.lock lock];
    if ([self isCancelled]) {
        [self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    } else if ([self isReady]) {
        self.state = AFOperationExecutingState;
        [self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    }
    [self.lock unlock];
}
复制代码

当须要这个后台线程执行任务时，AFNetworking 经过调用 [NSObject performSelector:onThread:..] 将这个任务扔到了后台线程的 RunLoop 中。

TableView延迟加载图片

将setImage放到NSDefaultRunLoopMode去作，也就是在滑动的时候并不会去调用这个方法，而是会等到滑动完毕切换到NSDefaultRunLoopMode下面才会调用。

UIImage *downLoadImage = ...;  
[self.avatarImageView performSelector:@selector(setImage:)  
                        withObject:downloadImage  
                        afterDelay:0  
                        inModes:@[NSDefaultRunLoopMode]];
复制代码

Crash的兼容处理

1. program received signal:SIGABRT SIGABRT通常是过分release或者发送unrecogized selector致使。
2. EXC_BAD_ACCESS是访问已被释放的内存致使，野指针错误。 由 SIGABRT 引发的Crash 是系统发这个signal给App，程序收到这个signal后，就会把主线程的RunLoop杀死，程序就Crash了 该例只针对 SIGABRT引发的Crash有效。

检测卡顿

当App发生主线程卡顿时，咱们能够经过RunLoop来监听到相对应的堆栈信息，而后进行优化处理。

• 要想监听 RunLoop，你就首先须要建立一个 CFRunLoopObserverContext 观察者

CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,kCFRunLoopAllActivities,YES,0,&runLoopObserverCallBack,&context);
复制代码

• 将建立好的观察者 runLoopObserver 添加到主线程 RunLoop 的 common 模式下观察。而后，建立一个持续的子线程专门用来监控主线程的 RunLoop 状态。
• 一旦发现进入睡眠前的 kCFRunLoopBeforeSources 状态，或者唤醒后的状态 kCFRunLoopAfterWaiting，在设置的时间阈值内一直没有变化，便可断定为卡顿。接下来，咱们就能够 dump 出堆栈的信息，从而进一步分析出具体是哪一个方法的执行时间过长。

//建立子线程监控
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    //子线程开启一个持续的 loop 用来进行监控
    while (YES) {
        long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 3 * NSEC_PER_SEC));
        if (semaphoreWait != 0) {
            if (!runLoopObserver) {
                timeoutCount = 0;
                dispatchSemaphore = 0;
                runLoopActivity = 0;
                return;
            }
            //BeforeSources 和 AfterWaiting 这两个状态可以检测到是否卡顿
            if (runLoopActivity == kCFRunLoopBeforeSources || runLoopActivity == kCFRunLoopAfterWaiting) {
                //将堆栈信息上报服务器的代码放到这里
            } //end activity
        }// end semaphore wait
        timeoutCount = 0;
    }// end while
});
复制代码

总结

• RunLoop的做用和意义
  • 保持程序持续运行，程序一启动就会开一个主线程，并接受用户输入
  • 处理App中的各类事件，并决定程序在什么时候处理应该处理哪些Event
  • 节省CPU资源，提升程序性能，在须要休眠时休眠
  • 调用解耦，使用户调用的时间有队列来处理，调用方和处理方彻底解耦
• Runloop与线程的关系
  • 每条线程都有惟一的一个与之对应的RunLoop对象
  • RunLoop保存在一个全局的Dictionary里，线程做为key,RunLoop做为value
  • 主线程的RunLoop已经自动建立好了，子线程的RunLoop须要主动建立
  • RunLoop在第一次获取时建立，在线程结束时销毁
• RunLoop的本质与结构
  • RunLoop本质也是一个结构体对象
  • RunloopMode是指的一个事件循环必须在某种模式下跑，系统会预约义几个模式。一个Runloop有多个Mode
  • CFRunloopSource，CFRunloopTimer，CFRunloopObserver这些元素是在Mode里面的，Mode与这些元素的对应关系也是1对多的。可是必须至少有一个Source或者Timer，由于若是Mode为空，RunLoop运行到空模式不会进行空转，就会马上退出
  • CFRunloopSource分为source0(处理用户事件)和source1(处理内核事件)
  • CFRunloopObserver是监听和通知Runloop状态
• RunLoop启动逻辑
  • 从 runloop 中查找给定的 mode
  • 将查找到的 mode 赋值到 runloop 的 _curentMode，也就是说在这 runloop 完成了 mode 的切换
  • 核心函数 __CFRunLoopRun
  • 若是注册了 observer，则通知runloop的开启，运行，结束等状态
• CFRunLoopRun逻辑
  • 使用dispatch_source_t建立一个定时器来处理超时相关的逻辑，若是没设置会默认一个特别大的数字
  • 启动do...while循环开始处理事件
  • 通知 Observers: RunLoop 即将触发 Timer和Source0 回调。
  • 执行被加入的block
  • 若是有 Source1 (基于port) 处于 ready 状态，直接处理这个 Source1 而后跳转去处理消息。
  • 通知 Observers: RunLoop 的线程即将进入休眠(sleep)。
  • 调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。
  • 通知 Observers: RunLoop 的线程刚刚被唤醒了。
  • 收到消息，处理消息。（Timer,dispatch,Source1等），并执行block回调
  • 根据当前 RunLoop 的状态来判断是否须要走下一个 loop。当被外部强制中止或 loop 超时时，就不继续下一个 loop 了，不然继续走下一个 loop 。
• RunLoop的退出
  • 主线程销毁RunLoop退出
  • Mode中有一些Timer 、Source、 Observer，这些保证Mode不为空时保证RunLoop没有空转而且是在运行的，当Mode中为空的时候，RunLoop会马上退出
  • 咱们在启动RunLoop的时候能够设置何时中止

参考

ibireme深刻理解RunLoop

孙源Runloop分享

戴明iOS高手课

iOS 查漏补缺 - RunLoop