由点入面吃透RunLoop

在 Objective-C 中，提到RunLoop 我们总是很难绕过去下面这些问题。

啥是RunLoop？它与线程间又是何种关系？所谓的 RunLoopMode、RunLoopSource、RunLoopObserver、RunLoopTimer又是些啥？有啥关联呢？

下面，我们不妨以这些为点，由点入面，剖析 RunLoop 的真正面目。

写在最前

在 OSX/iOS 系统中，RunLoop 相关的有两个：NSRunLoop 和 CFRunLoopRef。

CFRunLoopRef 是在 CoreFoundation 框架内的，它提供了纯 C 函数的 API，而且所有这些 API 都是线程安全的。
NSRunLoop 是基于 CFRunLoopRef 的封装，提供了面向对象的 API，但是这些 API 不是线程安全的。

目前而言，NSRunLoop 是 Foundation 框架内的一个类，我们只能看到其头文件，而看不到其具体的实现。而 CFRunLoopRef 是开源的，我们可以直接下载其源码。直达下载

__CFRunLoop

既然 NSRunLoop 是基于 CFRunLoopRef 的封装，我们就直接从 CFRunLoopRef 源码入手来看看 RunLoop 究竟是个啥？

我们能从源码中直接拿到 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;
};
复制代码

可以看到，其本质也是个结构体，我们可以只抓住我们关心的重要内容，比如 _pthread、_modes、_currentMode、_commonModeItems、_commonModes等等。

可以确定的是：

_pthread 能看出来 RunLoop 跟线程肯定是有关系的，具体什么关系呢？我们后面再看。
_modes 就是我们前面提到的 RunLoopMode ，这里是一个 set，很明显不止一种，是多种。
_currentMode 呢？直译也能知道是当前的 mode。
_commonModeItems、_commonModes 很明显跟我们通常项目中设置的 commonMode 有关系，而这里又将其与普通的 _modes 区分开，显然并不是一类模式，具体我们后面再看。

__CFRunLoopMode

接下来我们继续来看 __CFRunLoopMode 的定义：

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 */
};
复制代码

同样是一个结构体，而我们也同样抓住我们比较关心的 _sources0、_sources1、_observers、_timers等等。

注意⚠️，这里都是复数形式，而看其数据类型也是 set 或者 array，印证其并不是单个的存在。

我们继续撸源码，很容易发现，__CFRunLoopSource、__CFRunLoopObserver、__CFRunLoopTimer 也都是结构体，也都有其对应的属性。

稍作总结

到这里，其实我们从前面的源码就能知道 RunLoop、RunLoopMode、RunLoopSource、RunLoopObserver、RunLoopTimer 他们之前的关系：

RunLoop 与 RunLoopMode 是一对多的关系，也就是一个 RunLoop 包含多种 RunLoopMode，而 _currentMode 说明其多个 mode 并不是同时生效的，一次只是生效其中的一种；
RunLoopMode 与 RunLoopSource、RunLoopObserver、RunLoopTimer 同样也是一对多的关系，换句话说，就是在一种 RunLoopMode 下，会有多个 RunLoopSource / RunLoopObserver / RunLoopTimer，注意三者并不是互斥关系，一种 RunLoopMode 是可以同时拥有上面三种的，当然，RunLoopSource 又分为通常我们熟知的 source0 和 source1。而上面三者又统称为 modeItem；

网上找到一张图来描述他们之前的关系：

这里面还提到了 RunLoop 与线程，以及commonModes 的关系，后面我们继续看。

RunLoop 怎么 Run ？

前面我们知道，RunLoop 其本质是一个结构体，那么，RunLoop 又是怎么运行起来的呢？我们知道 RunLoop 是一个 Loop，也就是循环，通常我们将其理解为 死循环，这又是为何呢？

我们可以从其主运行函数入手得知一二：

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

可以看到，CFRunLoopRun 其本身实现为一个 do-while 循环体，其结束的条件是 Stop 或者 Finish 。而这两种状态在正常情况下始终不会满足，所以说理解一个正常的 RunLoop 是一个循环，还是个 死循环 也是无可厚非的。

另，我们从上面的源码了解到，其 Run 起来的核心函数是 CFRunLoopRunSpecific()：

SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) {     /* DOES CALLOUT */
    CHECK_FOR_FORK();
    if (__CFRunLoopIsDeallocating(rl)) return kCFRunLoopRunFinished;
    __CFRunLoopLock(rl);
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(rl, modeName, false);
    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);
    CFRunLoopModeRef previousMode = rl->_currentMode;
    rl->_currentMode = currentMode;
    int32_t result = kCFRunLoopRunFinished;

	if (currentMode->_observerMask & kCFRunLoopEntry ) __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
	result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
	if (currentMode->_observerMask & kCFRunLoopExit ) __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);

        __CFRunLoopModeUnlock(currentMode);
        __CFRunLoopPopPerRunData(rl, previousPerRun);
	rl->_currentMode = previousMode;
    __CFRunLoopUnlock(rl);
    return result;
}
复制代码

我们可以大致了解起过程，这个函数传入参数 RunLoop、mode名、时间以及是否 Handled 之后返回的 Boolean 值，其整个过程就是：通过 __CFRunLoopFindMode() 找到 currentMode ，最终通过 __CFRunLoopRun() 运行。

这中间，免不了一堆各种判断，但是不影响主流程。

值得一提的是，我们放眼望去那些个各种 lock、unlock，实际上就是我们线程安全的保障。

实际上，RunLoop run起来的姿势还有一种，那就是 CFRunLoopRunInMode() ：

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

从上面的源码知道，其本质还是 CFRunLoopRunSpecific()，跟上面是一致的。

从这里实际上我们也能发现另一个问题：RunLoopRun 总是 run 在某一种 mode 下面的，也就对应前面提到的 _currentMode 的问题了。换句话说就是，一个 RunLoop 有很多 mode，但是每次运行只是指定其一种。我们在让其运行的时候可以指定其运行的 mode，也可以不指定，走默认值，默认值为 kCFRunLoopDefaultMode 。

接着深入一下，既然只能是一个 mode 在运行，那只有这个 mode 下面的 modeItems 生效是不是就是理所应当，这里就是为什么 Timer 在 kCFRunLoopDefaultMode 下时，滑动会暂停其计时了，因为滑动的时候，mode 切换了。所以，了然与否呢？

RunLoop 与线程的关系

前面，RunLoop 的结构体中，我们看到一个 RunLoop 中对应一个 _pthread，即线程，因为这里并不是类似前面提到的 set OR Array 的这种集合的数据结构。

那么一个线程中，是否能有多个 RunLoop 呢？其实不然，官方根本就没有给予我们自己创建 RunLoop 的入口，结合其源码我们可以肯定，一个线程中也只能有一个 RunLoop。

问题是，啥源码呢？我们来看。

我们通常通过下面的方式获取 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;
}

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) {
    if (pthread_equal(t, kNilPthreadT)) {
	t = pthread_main_thread_np();
    }
    __CFLock(&loopsLock);
    if (!__CFRunLoops) {
        __CFUnlock(&loopsLock);
	CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks);
	CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np());
	CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop);
	if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) {
	    CFRelease(dict);
	}
	CFRelease(mainLoop);
        __CFLock(&loopsLock);
    }
    CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
    __CFUnlock(&loopsLock);
    if (!loop) {
	CFRunLoopRef newLoop = __CFRunLoopCreate(t);
        __CFLock(&loopsLock);
	loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
	if (!loop) {
	    CFDictionarySetValue(__CFRunLoops, pthreadPointer(t), newLoop);
	    loop = newLoop;
	}
        // don't release run loops inside the loopsLock, because CFRunLoopDeallocate may end up taking it
        __CFUnlock(&loopsLock);
	CFRelease(newLoop);
    }
    if (pthread_equal(t, pthread_self())) {
        _CFSetTSD(__CFTSDKeyRunLoop, (void *)loop, NULL);
        if (0 == _CFGetTSD(__CFTSDKeyRunLoopCntr)) {
            _CFSetTSD(__CFTSDKeyRunLoopCntr, (void *)(PTHREAD_DESTRUCTOR_ITERATIONS-1), (void (*)(void *))__CFFinalizeRunLoop);
        }
    }
    return loop;
}
复制代码

注意这里：CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));

很明显的是，这里有个字典(Dictionary)，通过这个字典能通过线程的指针，拿到对象应的 RunLoop，所以呢？要是一个线程对应多个 RunLoop ，这里怎么解释？

所以，线程和 RunLoop 之间是一一对应的，并且其关系是保存在一个全局的 Dictionary 里。

实际上，线程刚创建时并没有 RunLoop，如果你不主动获取，那它一直都不会有。RunLoop 的创建是发生在第一次获取时，RunLoop 的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop（主线程除外）。

commonMode

截止目前，我们还遗留另一个问题，关于 commonMode 的，这里又是何解呢？

我们先来看这段源码：

void CFRunLoopAddCommonMode(CFRunLoopRef rl, CFStringRef modeName) {
    CHECK_FOR_FORK();
    if (__CFRunLoopIsDeallocating(rl)) return;
    __CFRunLoopLock(rl);
    if (!CFSetContainsValue(rl->_commonModes, modeName)) {
	CFSetRef set = rl->_commonModeItems ? CFSetCreateCopy(kCFAllocatorSystemDefault, rl->_commonModeItems) : NULL;
	CFSetAddValue(rl->_commonModes, modeName);
	if (NULL != set) {
	    CFTypeRef context[2] = {rl, modeName};
	    /* add all common-modes items to new mode */
	    CFSetApplyFunction(set, (__CFRunLoopAddItemsToCommonMode), (void *)context);
	    CFRelease(set);
	}
    } else {
    }
    __CFRunLoopUnlock(rl);
}
复制代码

这个函数是干啥的呢？其实就是给 RunLoop 添加 commonMode 的，我们可以看到，其最终是添加到了 RunLoop 的 _commonModes 属性里面，但是这里加进去的只是 mode 的 name。

而在之后呢？注意这个函数 CFSetApplyFunction()，我们可以直接看其注释就知道具体干了啥，就是将所有的 commonModeItems 加到这个新的 commonMode 里面了。具体添加的过程是通过 __CFRunLoopAddItemsToCommonMode() 函数添加的：

static void __CFRunLoopAddItemsToCommonMode(const void *value, void *ctx) {
    CFTypeRef item = (CFTypeRef)value;
    CFRunLoopRef rl = (CFRunLoopRef)(((CFTypeRef *)ctx)[0]);
    CFStringRef modeName = (CFStringRef)(((CFTypeRef *)ctx)[1]);
    if (CFGetTypeID(item) == CFRunLoopSourceGetTypeID()) {
	CFRunLoopAddSource(rl, (CFRunLoopSourceRef)item, modeName);
    } else if (CFGetTypeID(item) == CFRunLoopObserverGetTypeID()) {
	CFRunLoopAddObserver(rl, (CFRunLoopObserverRef)item, modeName);
    } else if (CFGetTypeID(item) == CFRunLoopTimerGetTypeID()) {
	CFRunLoopAddTimer(rl, (CFRunLoopTimerRef)item, modeName);
    }
}
复制代码

可以看到，其就是将这个 mode 里面的各类 modeItem 添加到 commonMode 里面。

我们在接着往下看，拿 CFRunLoopAddSource 来看：

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);
    if (modeName == kCFRunLoopCommonModes) {
	CFSetRef set = rl->_commonModes ? CFSetCreateCopy(kCFAllocatorSystemDefault, rl->_commonModes) : NULL;
	if (NULL == rl->_commonModeItems) {
	    rl->_commonModeItems = CFSetCreateMutable(kCFAllocatorSystemDefault, 0, &kCFTypeSetCallBacks);
	}
	CFSetAddValue(rl->_commonModeItems, rls);
	if (NULL != set) {
	    CFTypeRef context[2] = {rl, rls};
	    /* add new item to all common-modes */
	    CFSetApplyFunction(set, (__CFRunLoopAddItemToCommonModes), (void *)context);
	    CFRelease(set);
	}
    } else {
	CFRunLoopModeRef rlm = __CFRunLoopFindMode(rl, modeName, true);
	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);
	}
	if (NULL != rlm && !CFSetContainsValue(rlm->_sources0, rls) && !CFSetContainsValue(rlm->_sources1, rls)) {
	    if (0 == rls->_context.version0.version) {
	        CFSetAddValue(rlm->_sources0, rls);
	    } 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) {
		    CFDictionarySetValue(rlm->_portToV1SourceMap, (const void *)(uintptr_t)src_port, rls);
		    __CFPortSetInsert(src_port, rlm->_portSet);
	        }
	    }
	    __CFRunLoopSourceLock(rls);
	    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 */
    }
}
复制代码

我们这里走的是 modeName != kCFRunLoopCommonModes 的情况，显然就会将 item 同步到 mode 对应的 items 里面了。

⚠️注意，这里并不是调用一次，是将上面 set 里面的每个元素都调用一次上面的过程。也就是将所有的 commonModeItems 加到了新的 mode 里面了。

我们再关注一下 modeName == kCFRunLoopCommonModes 的时候（这是什么情况呢？比如我们让 Timer run 在 commonMode 下的时候），首先是将 source（item）添加到了 RunLoop 的 _commonModeItems 里面。然后呢？

我们注意到这里也有类似的调用：

if (NULL != set) {
    CFTypeRef context[2] = {rl, rls};
    /* add new item to all common-modes */
    CFSetApplyFunction(set, (__CFRunLoopAddItemToCommonModes), (void *)context);
    CFRelease(set);
}
复制代码

需要注意的是，这里操作虽然类似，但是因为 set 的不一样（一个是 modes，一个是 items)，所以这里如注释所述，就是将 item 同步到 RunLoop 的属性 _commonModes 中的所有 mode 的对应的 sourceItems 集合中。

总结来看的话，commonMode 其实并不同于寻常的 mode，它更多的是一个虚的概念(其他的则是实际的 mode)，当是这种模式的时候，若是 mode，会将其添加到 RunLoop 的 _commonModes 属性里面，并将 _commonModeItems 同步到这个 mode 中的 sourceItems 中。若为 item，会先将其添加到 RunLoop 的 _commonModeItems 属性里面，并同步到 _commonModes 属性中的所有 mode 的 sourceItems 中。

总结

到这里，我们基本厘清了 RunLoop 中的一堆概念及其关系，在此总结一二：

RunLoop 与 RunLoopMode 是一对多的关系，也就是一个 RunLoop 包含多种 RunLoopMode；
RunLoopMode 与 modeItem（RunLoopSource、RunLoopObserver、RunLoopTimer）同样也是一对多的关系，换句话说，就是在一种 RunLoopMode 下，会有多个 modeItem；
RunLoop 只能运行在一种 RunLoopMode 下，即为 currentMode；
RunLoop 与线程是意义对应的关系，其关系保存在全局的字典里面（__CFRunLoops），key 是线程对象的指针，value 就是 RunLoop 对象。
RunLoop 中的 _commonModes 属性中存储的是被标记为 commonMode 的所有 modes，只是存储了 modeName；
RunLoop 中的 _commonModeItems 属性中存储的是所有运行在 commonMode 下面的所有的 modeItems；
mode 、 modeItem 在被标记为 commonMode 的过程中，就会同步 RunLoop 的两个属性 _commonModes 和 _commonModeItems，以及同步所有的 commonModes 的 modeItems;
在 CFRunLoopRef 中涉及可能影响线程安全的操作都是加锁的，所以是线程安全的；

以上，希望都能有所收获。