iOS RunLoop底层原理分析

准备工作

coreFoundation
swift-corelibs-foundation

1. 什么是RunLoop

RunLoop是一个运行循环，也是一个对象，并且提供了入口函数，进行do while循环，保证运行程序不退出。

一个程序运行结束的标志性语句是return，在iOS应用的入口main函数中，return并执行了一个UIApplicationMain函数，如下：

main函数

既然已经return了，为什么应用依然可以接收消息，处理消息呢？程序不应该到此结束吗？我们在代理AppDelegate的application:didFinishLaunchingWithOptions:方法中添加断点，并bt打印堆栈信息，探索到以下内容，如下：

查看堆栈信息

由堆栈信息看出，程序的执行流程，首先dyld进行应用程序加载，执行main函数，启动RunLoop，加载GCD………由此可见应用程序在启动过程中进行了一系列的初始化工作。同时可以确定，RunLoop来自CoreFoundation框架，CoreFoundation的部分源码是开源的，其中包括RunLoop。在其源码中，RunLoop Run的实现也确实是一个do while循环。如下：

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和线程有关系，并且提供了一套消息处理机制。在苹果官方的开发者文档Documentation Archive中搜索Thread内容，其中就包含了RunLoop的相关说明，如下：

官方文档说明

这也说明了Runloop和线程是息息相关的，这也是我们以下需要分析的。

2. RunLoop的作用

RunLoop的作用总结如下几点：

保持程序的持续运行
处理APP中的各种事件（触摸、定时器、performSelector）
节省cpu资源、提高程序的性能。

2.1 保持程序的持续运行

在main函数创建UIApplicationMain时启动了RunLoop，如果没有启动RunLoop，程序就会直接退出。

2.2 处理`APP`中的各种事件

在苹果的官方文档中，有这样一张图：

结合官方的说明，我们可以知道，RunLoop是线程用于处理运行事件、处理响应事件的循环。这些事件包括port事件源、屏幕触摸事件、performSelector、timer等。

我们在写上层代码的时候很少接触到Runloop，因为Runloop封装的非常好。一些事件处理都运用到了RunLoop，下面通过案例来分析：

Timer
处理Timer事件，对应__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__，如下：

案例分析
performSelector
处理performSelector事件，也对应的__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__，如下：

案例分析
GCD
队列中处理事件，对应__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__，如下：

案例分析

通过上面的探索，我们可以发现这些事件的处理方法均以__CFRUNLOOP_IS_为开头的方式命名，查看源码，其会根据不同的事件，提供不同的响应方法，如下：

响应方法

source相关响应方法

事件处理回调方法总结：

block应用：__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__
调用timer：__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
响应source0：__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
响应source1： __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__
GCD主队列：__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
observer源：__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__

2.3 节省`cpu`资源、提高程序的性能

RunLoop能节省cpu资源，提高程序的性能，这点体现在哪呢？见如下案例：

案例分析

从以上的案例可以发现，应用程序启动后，保持运行状态，但是此时的cpu占用率一直是0%。我们知道，RunLoop实际上就是一个do while循环，我们如果开启一个循环会怎样呢？对比一下！

开启一个循环

通过上图可以发现，cpu占用一直很高，所以可以得出结论，RunLoop所提供的循环是和普通的循环是有区别的，有事需要处理才会运行，没有事则会休息！从而达到了节省cpu资源，提高程序性能的作用。那么这种功能是如何实现的，下面会分析。

3. RunLoop与线程的关系

RunLoop和线程是息息相关的，并且是一一对应的关系。那么他们的关系是如何建立的呢？

    // 获取main RunLoop
    NSLog(@"%@", CFRunLoopGetMain());
    // 获取当前 RunLoop
    NSLog(@"%@", CFRunLoopGetCurrent());

通常会通过上面的两种方式打印输出main RunLoop以及当前RunLoop。在CFRunLoop源码中查看其实现，如下：

//获取主线程的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;
}
//获取当前线程的Runloop
CFRunLoopRef CFRunLoopGetCurrent(void) {
    CHECK_FOR_FORK();
    CFRunLoopRef rl = (CFRunLoopRef)_CFGetTSD(__CFTSDKeyRunLoop);
    if (rl) return rl;
    return _CFRunLoopGet0(pthread_self());
}

根据上面的代码不难发现，获取RunLoop均是通过线程进行获取。那么线程和RunLoop的关系是如何建立的呢？这就需要解读_CFRunLoopGet0函数的实现源码，如下：

_CFRunLoopGet0 - 1

_CFRunLoopGet0 - 2

解读_CFRunLoopGet0源码:

维护了一个CFMutableDistionaryRef字典__CFRunLoops，字典默认为NULL；
如果CFRunLoops是空，则创建一个CFMutableDistionaryRef字典，并默认初始化主线程的RunLoop；
将创建的RunLoop放入到CFMutableDistionaryRef字典中，也就是放入__CFRunLoops中，以线程为key，RunLoop为value；
在通过线程获取RunLoop时，以key-value方式从字典中获取对应的RunLoop；
如果RunLoop为空，则创建一个newLoop，以线程为key，RunLoop为value，存储到__CFRunLoops中；
返回线程对应的RunLoop。

结论：主线程的RunLoop会默认被创建，而子线程的RunLoop是懒加载的，需要时才会创建，RunLoop和线程是一对一的关系，存储在一个字典中。

子线程RunLoop案例分析

    GFThread * gfThread = [[GFThread alloc] initWithBlock:^{
        NSLog(@"running....");

        [NSTimer scheduledTimerWithTimeInterval:1.0 repeats:YES block:^(NSTimer * _Nonnull timer) {
            NSLog(@"helloc timer...%@", [NSThread currentThread]);
        }];
    }];

    gfThread.name = @"Hello.thread";
    [gfThread start];

GFThread是一个继承自NSThread的自定义线程，并重写了dealloc方法。案例中，在子线程中使用了一个NSTimer，运行这段代码会是什么结果呢？请往下看：

运行结果

线程生命周期结束，但是NSTimer的任务并没有执行。这是因为NSTimer需要依赖于RunLoop，主线程的RunLoop默认开启，而子线程的RunLoop是懒加载，需要手动开启。

对上面的案例进行修改，启动子线程的RunLoop。如下：

案例分析

那么如何结束NSTimer呢？首先我们需要理理清楚一个关系：线程和RunLoop一一对应，而NSTimer又依赖于RunLoop。根据这个思路可以做如下修改：

案例分析

通过外部变量可以控制线程，如果线程退出，对应的RunLoop也会停止运行，NSTimer又依赖于RunLoop，也自然不能运行。

4. RunLoop数据结构

RunLoop中涉及到5个重要的类，分别如下：

CFRunLoop - RunLoop对象
CFRunLoopMode - 五种运行模式
CFRunLoopSource - 输入源/事件源，包括Source0和Source1
CFRunLoopTimer - 定时源，也就是NSTimer
CFRunLoopObserver - 观察者，用来监听RunLoop

1. CFRunLoop
在底层RunLoop对象为CFRunLoop，NSRunLoop是OC层的封装。我们可以通过以下两种方式获取当前线程的RunLoop:

    // c/c++
    CFRunLoopRef lp     = CFRunLoopGetCurrent();
    // OC
    NSRunLoop *currentRunLoop = [NSRunLoop currentRunLoop];

CFRunLoop在底层是如何定义的呢？查找得出源码如下：

struct __CFRunLoop {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;          /* locked for accessing mode list */
    __CFPort _wakeUpPort;           // used for CFRunLoopWakeUp 
    Boolean _unused;
    volatile _per_run_data *_perRunData;              // reset for runs of the run loop
    pthread_t _pthread;
    uint32_t _winthread;
    CFMutableSetRef _commonModes;
    CFMutableSetRef _commonModeItems;
    CFRunLoopModeRef _currentMode;
    CFMutableSetRef _modes;
    struct _block_item *_blocks_head;
    struct _block_item *_blocks_tail;
    CFAbsoluteTime _runTime;
    CFAbsoluteTime _sleepTime;
    CFTypeRef _counterpart;
};

CRRunLoop中包括锁_lock、用于处理source1的唤醒端口_wakeUpport、关联的线程_pthread、当前模式_currentMode等。同时维护了一个set集合_modes。通过其结构体的数据，我们可以得出结论：RunLoop和mode是一对多的关系。同时包括_commonModes属性，commonMode是一个伪模式。

2. CFRunLoopMode
可以通过以下代码获取当前线程RunLoop的currentMode和mode列表：

    CFRunLoopRef lp     = CFRunLoopGetCurrent();
    CFRunLoopMode mode  = CFRunLoopCopyCurrentMode(lp);
    NSLog(@"mode == %@",mode);

    CFArrayRef modeArray= CFRunLoopCopyAllModes(lp);
    NSLog(@"modeArray == %@",modeArray);

运行上面的代码，查看运行结果，如下：

运行结果

此时currentMode是kCFRunLoopDefaultMode，而当前线程的RunLoop包括了三种mode，分别是：UITrackingRunLoopMode、GSEventReceiveRunLoopMode、kCFRunLoopDefaultMode。

3. 案例了解mode的切换
引入下面的案例，用于了解mode的切换过程，如下：

model切换案例

RunLoop添加Timer时放在了DefaultMode，程序正常情况下也运行在DefaultMode，但在滚动视图时，切换到了UITrackingMode，timer事件也不再触发。当停止滚动视图，又切回到了DefaultMode，timer恢复运行。

为什么model切换timer就停止运行？需要什么操作才能解决这样子的问题？请继续往下走。

首先查看model的定义如下：

typedef struct __CFRunLoopMode *CFRunLoopModeRef;

struct __CFRunLoopMode {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;  /* must have the run loop locked before locking this */
    CFStringRef _name;
    Boolean _stopped;
    char _padding[3];
    CFMutableSetRef _sources0;
    CFMutableSetRef _sources1;
    CFMutableArrayRef _observers;
    CFMutableArrayRef _timers;
    CFMutableDictionaryRef _portToV1SourceMap;
    __CFPortSet _portSet;
    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源码定义中包括了4个set集合_sources0、_sources1、_observers、_timers，这四个集合也就是我们常说的事件（事务）。所以我们可以得出结论：CFRunLoopMode和sourses、timer、observer也是一对多的关系。

在Developer Document中搜索NSRunLoopMode可以找到，系统共维护了5种mode见下图：

Developer Document

kCFRunLoopDefaultMode 默认的运行模式，通常主线程是在这个Mode下运行
UITrackingRunLoopMode 界面跟踪Mode，用于ScrollView等视图，追踪触摸滑动，保证界面的滑动不受其他Mode的影响
UIInitializationRunLoopMode 在刚启动App时进入的第一个Mode，启动完成后就不再使用
GSEventReceiveRunLoopMode 接受系统时间的内部Mode，通常用不到
kCFRunLoopCommonModes 是一个伪模式，可以在标记为CommonModes的模式下运行，RunLoop会自动将_commonModeItems里的source、observe、timer同步到具有标记的Mode里。

综上，可以得出以下关系图：

关系图

RunLoop与线程一对一
RunLoop与Mode一对多
Mode和source、timer、observer也是一对多

5. RunLoop事件处理机制

RunLoop处理APP中的各种事件（触摸、定时器、performSelector），也就是说block、timer、source0、source1、GCD、observer都需要依赖于RunLoop，那么这些事件是如何加入到RunLoop中的呢？底层又是如何去处理这些事件的呢？让我们继续往下探讨吧！！

5.1 添加事务

在源码中提供了一些事务(事件)添加方法，这些事务会添加到对应的mode中，如下：

事务添加

5.1.1 `block`事务添加

当有block事务时，RunLoop会调用CFRunLoopPerformBlock方法，将block事务存储到对应的mode中，如下：

CFRunLoopPerformBlock

在此过程中首先进行mode的判断处理，确定需要将事务放到哪个mode中，如果mode或者block为空，则释放；否则会创建一个block_item，该数据是一个链表结构，其存储了一个block和下一个节点的地址信息。

5.1.2 `timer`事务添加

当有timer事务时，RunLoop会调用CFRunLoopAddTimer方法，将timer事务存储到对应的mode中，如下：

CFRunLoopAddTimer

进入__CFRepositionTimerInMode方法，如下:

__CFRepositionTimerInMode

这里会对mode进行判断，判断是否为commonModes，如果是会初始化_commonModeItems集合，并将timer事务添加到集合中。否则找到对应的mode，然后调用__CFRepositionTimerInMode方法，将timer添加到_timers集合中。

注意：CFRunLoopAddObserver、CFRunLoopAddSource流程类似，这里不详细说明。

5.2 RunLoop循环

在程序运行的入口处设置断点，我们可以发现系统会首先调用CFRunLoopRunSpecific方法，启动RunLoop。如下：

汇编断点

下面跟踪RunLoop处理流程。在源码中查找CFRunLoopRunSpecific的方法实现，如下：

CFRunLoopRunSpecific

在这里注册了两个Observer，第一个Observer监视的事件是Entry(即将进入Loop)，第二个Observer监视Exit(即将退出Loop)。

进入__CFRunLoopRun方法，方法实现如下：

__CFRunLoopRun - 1

__CFRunLoopRun - 2

__CFRunLoopRun - 3

__CFRunLoopRun - 4

__CFRunLoopRun - 5

__CFRunLoopRun - 6

__CFRunLoopRun - 7

__CFRunLoopRun - 8

__CFRunLoopRun - 9

循环状态是对retVal进行控制，在循环过程中，会对状态进行判断，如，是否TimedOut、是否Stopped、是否Finished，来确定RunLoop是否需要销毁。
此部分代码是RunLoop的核心流程，关键点做了标注，总结下来，可以得出下面这个流程图：

流程图

5.3 事务处理

上面两节已经摸清楚事务(事件)的添加流程、RunLoop循环处理流程，下面重点分析RunLoop在循环过程中是如何处理事务的。
在上面的do while循环中，有处理事务的入口：__CFRunLoopDoBlocks、__CFRunLoopDoTimers、__CFRunLoopDoSources0、__CFRunLoopDoSource1。

5.3.1 处理`block`事务

__CFRunLoopDoBlocks源码实现，如下：

__CFRunLoopDoBlocks - 1

__CFRunLoopDoBlocks - 2

在分析block事务添加过程时提到，block事务是以链表的形式存储的，这里进行处理事务时通过_next指针循环遍历所有的block事务。

block执行逻辑：

事务加入的mode和当前RunLoop的mode相等
当前mode是commonModes
通过调用回调函数__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__执行任务

static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__() __attribute__((noinline));
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(void (^block)(void)) {
    if (block) {
        block();
    }
    asm __volatile__(""); // thwart tail-call optimization
}

5.3.2 处理`timer`事务

__CFRunLoopDoTimers源码实现如下：

__CFRunLoopDoTimers

此过程中，会从当前mode的_timers中获取需要执行的timer事务，放入到数组timers中，然后在调用__CFRunLoopDoTimer方法执行timer。__CFRunLoopDoTimer实现原理如下：

__CFRunLoopDoTimer

在此流程中会对Timer的状态进行判断，并调用函数__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__完成事务的执行。

__CFRunLoopDoSources0的处理流程不再详细介绍，最终会调用__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__函数。

5.4 总结流程图

总结流程图

6. RunLoop与AutoreleasePool

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了。

总结：

AutoreleasePool创建是在一个RunLoop事件开始之前(push)，
AutoreleasePool释放是在一个RunLoop事件即将结束之前(pop)。
AutoreleasePool里的Autorelease对象的加入是在RunLoop事件中，AutoreleasePool里的Autorelease对象的释放是在AutoreleasePool释放时。

7. RunLoop总结

RunLoop是通过系统内部维护的循环进行事件、消息管理的一个对象。RunLoop实际上就是一个do...while循环，有任务时开始，无任务时休眠。本质是通过mach_msg()函数接收、发送消息。

RunLoop与线程的关系：
- RunLoop的作用就是来管理线程，当线程的RunLoop开启后，线程就会在执行完任务后，处于休眠状态，随时等待接受新的任务，不会退出。
- 只有主线程的RunLoop是默认开启的，其他线程的RunLoop需要手动开启。所以当程序开启后，主线程一直运行，不会退出。
RunLoop中涉及到5个重要的类：
- CFRunLoop - RunLoop对象
- CFRunLoopMode - 五种运行模式
- CFRunLoopSource - 输入源/事件源，包括Source0和Source1
- CFRunLoopTimer - 定时源，也就是NSTimer
- CFRunLoopObserve - 观察者，用来监听RunLoop
CFRunLoopMode - 五种运行模式
- kCFRunLoopDefaultMode 默认的运行模式，通常主线程是在这个Mode下运行
- UITrackingRunLoopMode 界面跟踪Mode，用于ScrollView等视图，追踪触摸滑动，保证界面的滑动不受其他Mode的影响
- UIInitializationRunLoopMode 在刚启动App时进入的第一个Mode，启动完成后就不再使用
- GSEventReceiveRunLoopMode 接受系统时间的内部Mode，通常用不到
- kCFRunLoopCommonModes 是一个伪模式，可以在标记为CommonModes的模式下运行，RunLoop会自动将_commonModeItems里的source、observe、timer同步到具有标记的Mode里。
CFRunLoopSource - 事件源
- Source1:基于mach_port和回调函数指针，也就是端口通讯，处理来自系统内核或其他进程的事件，比如点击手机屏幕
- Source0:非基于Port的处理事件，也就是应用层事件（内部事件、APP负责管理的事件，UIEvent），包含一个回调函数指针，需要手动标记为待处理或者手动唤醒RunLoop，如performSelector、block等
- 例如：一个APP在前台静止，用户点击APP界面，屏幕表面的时事件会先包装成Event告诉source1（基于mach_port），source1唤醒RunLoop将事件Event分发给source0，由source0来处理。
CFRunLooTimer - 定时源
就是NSTimer，在预设的时间点唤醒RunLoop执行回调。因为它是基于RunLoop的，因此它不是实时的（Timer是不准确的，因为RunLoop只负责分发源消息。如果线程当前正在处理繁重的任务，就有可能导致Timer本次延时，或者少执行一次）。
CFRunLoopObserver - 观察者
用来监听时间点事件CFRunLoopActivity。
- KCFRunLoopEntery RunLoop准备启动
- kCFRunLoopBeforeTimers RunLoop将要处理一些Timer相关的事件
- kCFRunLoopBeforeSources RunLoop将要处理一些Source事件
- kCFRunLoopBeforeWaiting RunLoop将要进行休眠状态，即将由用户状态切换内核态
- kCFRunLoopAfterWaiting RunLoop被唤醒，即从内核态切换到用户态
- kCFRunLoopExit RunLoop退出
- kCfRunLoopAllActivitires 监听所有状态
各数据结构之间的联系
- RunLoop和线程是一对一的关系
- RunLoop和RunLoopMode是一对多的关系
- RunLoopMode和RunLoopSource是一对多的关系
- RunLoopMode和RunLoopTimer是一对多的关系
- RunLoopMode和RunLoopObserver是一对多的关系
为什么main函数能够保持一直存在且不退出？
在main函数内容会调用UIApplication函数，而在UIAPPlicationMain内部会启动主线程的RunLoop，可以做到有消息处理，能够迅速从内核态到用户态的切换，立刻唤醒处理，而没有消息处理时，通过用户态到内核态的切换进入等待状态，避免资源的占用。因此main函数能够一直存在并且不退出。

iOS RunLoop底层原理分析

准备工作

1. 什么是RunLoop

2. RunLoop的作用

2.1 保持程序的持续运行

2.2 处理APP中的各种事件

2.3 节省cpu资源、提高程序的性能

3. RunLoop与线程的关系

4. RunLoop数据结构

5. RunLoop事件处理机制

5.1 添加事务

5.1.1 block事务添加

5.1.2 timer事务添加

5.2 RunLoop循环

5.3 事务处理

5.3.1 处理block事务

5.3.2 处理timer事务

5.4 总结流程图

6. RunLoop与AutoreleasePool

7. RunLoop总结

你可能感兴趣的:(iOS RunLoop底层原理分析)

2.2 处理`APP`中的各种事件

2.3 节省`cpu`资源、提高程序的性能

5.1.1 `block`事务添加

5.1.2 `timer`事务添加

5.3.1 处理`block`事务

5.3.2 处理`timer`事务