在 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
中涉及可能影响线程安全的操作都是加锁的,所以是线程安全的;
以上,希望都能有所收获。