RunLoop 笔记

作者: CocoBird | 来源:发表于2016-08-13 22:33 被阅读0次

RunLoop笔记
RunLoop笔记
RunLoop笔记
RunLoop笔记
RunLoop 笔记
runloop笔记
runloop笔记
喜欢的链接
runloop详解
2020-11-10

RunLoop 是 iOS 开发中非常重要的一个概念，本文是对孙源大神的视频的总结笔记与实践

命令式执行与事件驱动

# 命令式执行
先看一段 hello word 的代码：

int main(int argc, char * argv[]) {
    NSLog(@"hello world!");
    return 0;
}

这种实现特别像是我们在命令行输入一些指令，然后返回一个结果就完了，所以称为命令行执行。但是对于 APP 来说，用户肯定是希望程序能够不停地运行下去。

# 事件驱动
事实上，APP 是一个基于事件驱动的整体架构，在程序没有事件要处理的时候就休眠，事件来了的时候再唤醒，然后去处理事件。撸一段简单的伪码：

int main(int argc, char * argv[]) {
    while (AppIsRuning) {
        id whoWakeMe = SleepForWakingUp();
        id event = GetEvent(whoWakeMe);
        HandleEvent(event);
    }
    return 0;
}

所以简单来讲，RunLoop 就是干这么一件事情，当然，实际情况会复杂得多。

RunLoop 的作用

RunLoop 有几个作用

保持程序的运行并接受用户的输入
决定程序在何时应该处理哪些事件（因为事件可以有很多）
调用解耦（相当于消息队列）
节省 CPU 时间

前边两点很好理解，下边说下调用解耦和节省 CPU 时间

**# 调用解耦 **

什么是调用解耦呢？比如说，用户操作产生若干的 UIEvent 事件，主调方（用户）不可能等待被调方（能够响应某特定事件的对象）将所有的这些事件处理完了才去产生下一个事件，所以就要对主调方和被调方进行解耦。这时候就需要一个消息队列，主调方把要处理的事件放到消息队列，然后由被调方从消息队列中取出事件进行处理，这是一个事件传递和响应的过程。

**# 节省 CPU 时间 **

操作系统实际上是以“时间片”的方式进行 CPU 调度的，关于这方面的东西可以复习下操作系统。那么 RunLoop 是如何节省时间的呢？其实通俗点说就是 RunLoop 在有活干的时候去干活，没活干的时候什么都不做，这时候 CPU 就不用管它了。

Cocoa 架构中的 RunLoop

Cocoa 架构中的 RunLoop.png

CFRunLoop 是在 CoreFoundation 框架内的，它提供了纯 C 函数的 API，所有这些 API 都是线程安全的。而 NSRunLoop 是基于 CFRunLoop 的封装，提供了面向对象的 API，但是这些 API 不是线程安全的。此外，RunLoop 还与操作系统内核有着密切的关系。

RunLoop 机制

先来看下 RunLoop 的结构：

RunLoop 构成元素.png

** # RunLoop 与线程的关系 **

线程和 RunLoop 之间是一一对应的，这种关系保存在一个全局的 Dictionary 里。注意一一对应并不是说一个线程只能有一个 RunLoop，可以有多个，但是多个的 RunLoop 必须是嵌套的。线程刚创建时并没有 RunLoop，但可以手动获取。RunLoop 的创建是发生在第一次获取时，RunLoop 的销毁是发生在线程结束时。我们只能在一个线程的内部获取其 RunLoop（主线程除外）。

CFRunLoop 是基于 pthread 来管理的，因此我们可以通过 pthread_main_thread_np() 来获取主线程；同时也可以通过 pthread_self() 来获取当前线程。此外，苹果并不允许直接创建 RunLoop，所幸它提供了两个自动获取的函数：CFRunLoopGetMain() 和 CFRunLoopGetCurrent(). 这两函数的内部实现简化如下：

/// 全局的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 访问 loopsDic 时的锁
static CFSpinLock_t loopsLock;
 
/// 获取一个 pthread 对应的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
    OSSpinLockLock(&loopsLock);

    // ------------------------ Croe ---------------- //
    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();
        // key 是 pthread_t， value 是 CFRunLoopRef
        CFDictionarySetValue(loopsDic, thread, loop);
        /// 注册一个回调，当线程销毁时，顺便也销毁其对应的 RunLoop。
        _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
    }
    // --------------------------------------------- //

    OSSpinLockUnLock(&loopsLock);
    return loop;
}
 
CFRunLoopRef CFRunLoopGetMain() {
    return _CFRunLoopGet(pthread_main_thread_np());
}
 
CFRunLoopRef CFRunLoopGetCurrent() {
    return _CFRunLoopGet(pthread_self());
}

** # CFRunLoopMode 简单认识**

Mode 是 RunLoop 里的一个非常核心的概念，是 RunLoop 运行的模式。RunLoop 与 Mode 之间是一对多的关系，一个 RunLoop 包含若干个 Mode，每个 Mode 又包含若干个 Source/Timer/Observer。

** # CFRunLoopTimer **

基于时间的触发器，NSTimer 是对 CFRunLoopTimer 的封装，而且它俩是 toll-free bridged 的，可以混用。其包含一个时间长度和一个回调（函数指针）。当其加入到 RunLoop 时，RunLoop会注册对应的时间点，当时间点到时，RunLoop会被唤醒然后去执行那个回调。

注意：GCD 里边也有 timer ，但是 CFRunLoopTimer 用的是 XNU 内核的 mk_timer ，与 GCD 无关

** # CFRunLoopSource **

Source 是输入源，可以理解为数据源的抽象类（protocol），就是说它定义了一些 protocol ，实现了这些 protocol 的子类的对象就可以作为 RunLoop 的数据源。

struct __CFRunLoopSource {
    CFRuntimeBase _base;
    uint32_t _bits;
    pthread_mutex_t _lock;
    CFIndex _order;         /* immutable */
    CFMutableBagRef _runLoops;
    union { /// 共享内存
        CFRunLoopSourceContext version0;    /* immutable, except invalidation */
        CFRunLoopSourceContext1 version1;   /* immutable, except invalidation */
    } _context;
};

Source有两个版本：Source0 和 Source1。它们各有分工：

** Source0 ** 用于处理 APP 内部的事件，由 APP 自己去管理（触发）。比如说触发 UIEvent 中的 touch 事件：用户点了一下屏幕，这个事件是怎么触发的，就是 Source0 干的事情。

Source0.png

从 touch 事件的调用堆栈上可以看出它是从 Source0 中调起的，就是下边的这个函数。

static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__() __attribute__((noinline));
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(void (*perform)(void *), void *info) {
    if (perform) {
        perform(info);
    }
    asm __volatile__(""); // thwart tail-call optimization 阻挠尾调用优化
}

注意：这里为了让这个函数能在调用堆栈上显示，阻挠了尾调用优化（tail-call optimization）。关于 tail-call optimization 去看下这篇文章就懂了。

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;

它只包含了一个回调（函数指针 perform），它并不能主动触发事件。使用时，需要先调用 CFRunLoopSourceSignal(source)，将这个 Source 标记为待处理，然后手动调用 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop，让其处理这个事件。

** Source1 ** 包含了一个 mach_port 和一个回调（函数指针），由 RunLoop 和系统内核管理，被用于通过内核和其他线程相互发送消息。Matt 大神在Inter-Process Communication中讲解了mach_port 以及进程间通信。

** # CFRunLoopObserver **

观察者，向外部报告 RunLoop 当前的状态。

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 都包含了一个回调（函数指针），当 RunLoop 的状态发生变化时，观察者就能通过回调接受到这个变化。

观察的时间点有6个：

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry         = (1UL << 0), /// 即将进入 RunLoop
    kCFRunLoopBeforeTimers  = (1UL << 1), /// 即将处理 Timer
    kCFRunLoopBeforeSources = (1UL << 2), /// 即将处理 Source
    kCFRunLoopBeforeWaiting = (1UL << 5), /// 即将进入休眠状态
    kCFRunLoopAfterWaiting  = (1UL << 6), /// 刚从休眠中唤醒
    kCFRunLoopExit          = (1UL << 7), /// 即将退出
    
    kCFRunLoopAllActivities = 0x0FFFFFFFU
};

实际上，苹果框架中的很多机制事实上都使用了 Observer ，比如说 CAAnimation：CAAnimation 会在 RunLoop 跑完一圈收集完所有的动画在 BeforeWaiting 或 AfterWaiting 的时候执行动画。

Autorelease Pool 的释放也与 Observer 有关

AutoreleasePool调用堆栈.png

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 环绕着，所以不会出现内存泄漏。

RunLoop 的 Mode

系统提供的 Mode 有：

NSDefaultRunLoopMode：默认状态、空闲状态（点击事件、普通回调等都走这个 Mode）
UITrackingRunLoopMode：ScrollView 滑动时，自动切换到这个 Mode，这是 iOS 滑动顺畅的关键
UIInitializationRunLoopMode：私有的，APP 启动时的 Mode，然后会被切换到 NSDefaultRunLoopMode
NSRunLoopCommonModes：Mode 集合，默认包含 NSDefaultRunLoopMode 和 UITrackingRunLoopMode ，当然也可以包含自定义 Mode（必须要自定的情况很少）

Mode 使用时要注意两点：

程序在某一时刻只能在一种特定的 Mode 下运行
更换 Mode 的时候，需要停止当前的 RunLoop ，切换完成后在重新启动 RunLoop

** # RunLoop Mode 的切换**

RunLoopMode切换.png

上面是开始滑动到停止滑动的调用堆栈，Mode 由 NSDefaultRunLoopMode 切换到 UITrackingRunLoopMode 再切回 NSDefaultRunLoopMode . 可以看到，从停止到开始滑动的过程中，UIKit 将 Mode push 给 RunLoop，然后 CFRunLoopWakeUp 启动RunLoop；滑动到停止时 pop 出栈，这时候栈顶还是原来的 NSDefaultRunLoopMode.

** # RunLoop 与dispatch_get_main_queue () **

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

static void __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() __attribute__((noinline));
static void __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(void *msg) {
    _dispatch_main_queue_callback_4CF(msg);
    asm __volatile__(""); // thwart tail-call optimization
}

RunLoop 与dispatch_get_main_queue () .png

RunLoop 挂起和唤醒

挂起和唤醒过程如下：

RunLoop 先去指定一个用于唤醒自己的 mach_port 端口
调用 mach_msg 监听唤醒端口，被唤醒前，系统将这个线程挂起，停留在 mach_msg_trap 状态
当另外一个线程或者另外一个进程中的线程给这个端口发送消息的时候，RunLoop 从 mach_msg_trap 状态中唤醒，然后处理执行。

RunLoop 执行逻辑

RunLoop 的执行顺序可以参考下面这段伪代码：

SetupThisRunLoopRunTimeoutTimer(); // 调用GCD的Timer设置过期时间
do {
    __CFRunLoopDoObservers(kCFRunLoopBeforeTimers);  // 告诉观察者将要处理Timer
    __CFRunLoopDoObservers(kCFRunLoopBeforeSources); // 告诉观察者将要处理Source
    
    __CFRunLoopDoBlock();
    __CFRunLoopDoSource0(); // 处理 Source0
    
    CheckIfExistMessageInMainQueue(); // 处理主线程中的任务
    
    __CFRunLoopDoObservers(kCFRunLoopBeforeWaiting); // 告诉观察者将要休眠
    
    var wakeUpPort = SleepAndWakeForWakingUpPorts(); // 指定唤醒端口
    
    // 然后进入 mach_msg_trap 状态，休眠...
    
    __CFRunLoopDoObservers(kCFRunLoopAfterWaiting); // 告诉观察者已从休眠状态唤醒
    
    // 处理消息
    if (wakeUpPort == timerPort) {
        __CFRunLoopDoTimer();
    } else if (wakeUpPort == mainDispatchQueuePort) {
        __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__();
    } else {
        __CFRunLoopDoSource1();
    }
    __CFRunLoopDoBlock();

} while(!stop && !timeout);

RunLoop 内部就是一个 do-while 循环，线程会一直停留在这个循环里直到超时或被手动停止。

Reference：
深入理解RunLoop
Threading Programming Guide
尾调用优化
 Inter-Process Communication
NSRunLoop Internals

The end ~