一般来讲,一个线程一次只能执行一个任务,执行完成后线程就会退出。如果我们需要一个机制,让线程能随时处理事件但并不退出,通常的代码逻辑是这样的:
do {
//获取消息
//处理消息
} while (消息 != 退出)
这种模型通常被称作 Event Loop
。 实现这种模型的关键点在于:如何管理事件/消息,如何让线程在没有处理消息时休眠以避免资源占用、在有消息到来时立刻被唤醒。
所以,RunLoop
实际上就是一个对象,这个对象管理了其需要处理的事件和消息,并提供了一个入口函数来执行上面 Event Loop 的逻辑。线程执行了这个函数后,就会一直处于这个函数内部 “接受消息->等待->处理” 的循环中,直到这个循环结束(比如传入 quit 的消息),函数返回。
以iOS 程序的 main
函数为例:
int main(int argc, char * argv[]) {
@autoreleasepool {
NSLog(@"main start");
int re = UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
NSLog(@"main stop");
return re;
}
}
main
函数是程序的入口,那么为什么程序执行完毕后没有退出呢?因为 RunLoop
,使线程循环,能够随时处理事件但并不退出。上面代码中 UIApplicationMain()
方法在这里不仅完成了初始化我们的程序并设置程序 Delegate
的任务,而且随之开启了主线程的 RunLoop
,开始接受处理事件。这样我们的应用就可以在无人操作的时候休息,需要让它干活的时候又能立马响应。
OSX/iOS
系统中,提供了两个这样的对象: NSRunLoop
和 CFRunLoopRef
。
CFRunLoopRef
是在 CoreFoundation`` 框架内的,它提供了纯 C 函数的 API,所有这些 API 都是线程安全的。
NSRunLoop是基于
CFRunLoopRef``` 的封装,提供了面向对象的 API,但是这些 API 不是线程安全的。
CFRunLoopRef
的代码是开源的,可以点击下载到整个 CoreFoundation
的源码来查看。http://opensource.apple.com/tarballs/CF/
RunLoop
大致内部结构:
struct __CFRunLoop {
CFMutableSetRef _commonModes; // Set
CFMutableSetRef _commonModeItems; // Set<Source/Observer/Timer>
CFRunLoopModeRef _currentMode; // Current Runloop Mode
CFMutableSetRef _modes; // Set
...
};
RunLoop 机制关系图总览:
RunLoop与线程的关系
苹果不允许直接创建 RunLoop
,提供了两个获取函数,CFRunLoopRef
的获取方法为CFRunLoopGetMain()
, CFRunLoopGetCurrent()
。NSRunLoop
的获取方法是 currentRunLoop
,mainRunLoop
。NSRunLoop
对象可以通过 getCFRunLoop
方法获得 CFRunLoopRef
对象。CFRunLoopRef
的内部逻辑如下:
/// 全局的 Dictionary,key 是 pthread_t, value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 访问 loopsDic 时的锁
static CFSpinLock_t loopsLock;
/// 获取一个 pthread 对应的 Run Loop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
OSSpinLockLock(&loopsLock);
if (!loopsDic) {
// 第一次进入时,初始化全局Dic,并先为主线程创建一个 Run Loop。
loopsDic = CFDictionaryCreateMutable();
CFRunLoopRef mainLoop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
}
/// 直接从 Dictionary 里获取。
CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
if (!loop) {
/// 取不到时,创建一个
loop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic, thread, loop);
/// 注册一个回调,当线程销毁时,顺便也销毁其对应的 Run Loop。
_CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
return loop;
}
CFRunLoopRef CFRunLoopGetMain() {
return _CFRunLoopGet(pthread_main_thread_np());
}
CFRunLoopRef CFRunLoopGetCurrent() {
return _CFRunLoopGet(pthread_self());
}
从上面的代码可以看出,线程和 RunLoop
之间是一一对应的(这也就解释了前面关系图中 CFRunLoop
和 Thread
连线中的两个1的意义),其关系是保存在一个全局的 Dictionary
里。线程刚创建时并没有 RunLoop
,如果你不主动获取,那它一直都不会有,所以一个子线程,你想要它有 RunLoop
就必须在该线程内调用 NSRunLoop *runLoop =[NSRunLoop currentRunLoop]
。如果你想启动这个 RunLoop
,则要继续调用[runLoop run]
。但是注意,一般不需要开启子线程的 runLoop
,因为这会让子线程一直存在,不会回收。RunLoop
的创建是发生在第一次获取时,RunLoop
的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop
(主线程除外)。
RunLoop主要组成
在 CoreFoundation
里面关于 RunLoop
有5个类:
- CFRunLoopRef
- CFRunLoopModeRef
- CFRunLoopSourceRef
- CFRunLoopTimerRef
- CFRunLoopObserverRef
他们之间的关系如下图:
一个RunLoop
包含若干个Mode
,每个Mode
又包含若干个Source/Timer/Observer
。每次调用RunLoop
的主函数时,只能指定其中一个Mode
,这个Mode
被称作CurrentMode
。如果需要切换Mode
,只能退出Loop
,再重新指定一个Mode
进入。这样做主要是为了分隔开不同组的Source/Timer/Observer
,让其互不影响。
CFRunLoopMode
CFRunLoopMode
结构大致如下:
struct __CFRunLoopMode {
CFStringRef _name; // mode名称
CFMutableSetRef _sources0; // sources0
CFMutableSetRef _sources1; // sources1
CFMutableArrayRef _observers; // 通知
CFMutableArrayRef _timers; // 定时器
__CFPortSet _portSet; // 保存所有需要监听的port,比如 _wakeUpPort,_timerPort都保存在这个数组中
};
一个CFRunLoopMode
对象有一个name
,若干source0、source1、timer、observer
和若干port
,事件都是由Mode
在管理,而RunLoop
管理Mode
。
Runloop
中有个概念叫 CommonModes
:一个 Mode
可以将自己标记为Common
属性(通过将其 ModeName
添加到 RunLoop
的 commonModes
中)。每当 RunLoop
的内容发生变化时,RunLoop
都会自动将 _commonModeItems
里的Source/Observer/Timer
同步到具有 Common
标记的所有Mode
里。
应用场景举例:主线程的 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
里去。
CFRunLoopSource
Source0 :
处理App内部事件、App自己负责管理(触发),如UIEvent
。source0
是非基于Port的。只包含了一个回调(函数指针),它并不能主动触发事件。使用时,你需要先调用 CFRunLoopSourceSignal(source)
,将这个Source
标记为待处理,然后手动调用 CFRunLoopWakeUp(runloop)
来唤醒 RunLoop
,让其处理这个事件。
Source1 :由RunLoop
和内核管理,Mach port
驱动,如CFMachPort
、CFMessagePort
。
包含了一个 mach_port
和一个回调(函数指针),被用于通过内核和其他线程相互发送消息。这种 Source
能主动唤醒 RunLoop
的线程。
CFRunLoopTimer
是基于时间的触发器,基本上说的就是NSTimer
,它受RunLoop
的Mode
影响,当其加入到 RunLoop
时,RunLoop
会注册对应的时间点,当时间点到时,RunLoop
会被唤醒以执行那个回调。如果线程阻塞或者不在这个Mode
下,触发点将不会执行,一直等到下一个周期时间点触发。
CFRunLoopObserver
CFRunLoopObserverRef
是观察者,每个 Observer
都包含了一个回调(函数指针),当 RunLoop
的状态发生变化时,观察者就能通过回调接受到这个变化。可以观测的时间点有以下几个:
kCFRunLoopEntry = (1 << 0), // 即将进入Loop
kCFRunLoopBeforeTimers = (1 << 1), // 即将处理 Timer
kCFRunLoopBeforeSources = (1 << 2), // 即将处理 Source
kCFRunLoopBeforeWaiting = (1 << 5), // 即将进入休眠
kCFRunLoopAfterWaiting = (1 << 6), // 刚从休眠中唤醒
kCFRunLoopExit = (1 << 7), // 即将退出Loop
kCFRunLoopAllActivities = 0x0FFFFFFFU // 包含上面所有状态
RunLoop 的内部逻辑
RunLoop
内部的逻辑大致如下:
其内部代码整理如下:
/// 用DefaultMode启动
void CFRunLoopRun(void) {
CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}
/// 用指定的Mode启动,允许设置RunLoop超时时间
int CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean stopAfterHandle) {
return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}
/// RunLoop的实现
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
/// 首先根据modeName找到对应mode
CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
/// 如果mode里没有source/timer, 直接返回。
if (__CFRunLoopModeIsEmpty(currentMode)) return;
/// 1. 通知 Observers: RunLoop 即将进入 loop。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
/// 内部函数,进入loop
__CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
Boolean sourceHandledThisLoop = NO;
int retVal = 0;
do {
/// 2. 通知 Observers: RunLoop 即将触发 Timer 回调。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: RunLoop 即将触发 Source 回调。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
/// 执行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 4. RunLoop 触发 Source0 (非port) 回调。
sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
/// 执行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 5. 如果有 Source1 (基于port) 处于 ready 状态,直接处理这个 Source1 然后跳转去处理消息。
if (__Source0DidDispatchPortLastTime) {
Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
if (hasMsg) goto handle_msg;
}
/// 通知 Observers: RunLoop 的线程即将进入休眠(sleep)。
if (!sourceHandledThisLoop) {
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
}
/// 7. 调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。
/// • 一个基于 port 的Source 的事件。
/// • 一个 Timer 到时间了
/// • RunLoop 自身的超时时间到了
/// • 被其他什么调用者手动唤醒
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort) {
mach_msg(msg, MACH_RCV_MSG, port); // thread wait for receive msg
}
/// 8. 通知 Observers: RunLoop 的线程刚刚被唤醒了。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);
/// 收到消息,处理消息。
handle_msg:
/// 9.1 如果一个 Timer 到时间了,触发这个Timer的回调。
if (msg_is_timer) {
__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
}
/// 9.2 如果有dispatch到main_queue的block,执行block。
else if (msg_is_dispatch) {
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
}
/// 9.3 如果一个 Source1 (基于port) 发出事件了,处理这个事件
else {
CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
if (sourceHandledThisLoop) {
mach_msg(reply, MACH_SEND_MSG, reply);
}
}
/// 执行加入到Loop的block
__CFRunLoopDoBlocks(runloop, currentMode);
if (sourceHandledThisLoop && stopAfterHandle) {
/// 进入loop时参数说处理完事件就返回。
retVal = kCFRunLoopRunHandledSource;
} else if (timeout) {
/// 超出传入参数标记的超时时间了
retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(runloop)) {
/// 被外部调用者强制停止了
retVal = kCFRunLoopRunStopped;
} else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
/// source/timer一个都没有了
retVal = kCFRunLoopRunFinished;
}
/// 如果没超时,mode里没空,loop也没被停止,那继续loop。
} while (retVal == 0);
}
/// 10. 通知 Observers: RunLoop 即将退出。
__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}
可以看到,实际上 RunLoop
就是这样一个函数,其内部是一个 do-while
循环。当你调用 CFRunLoopRun()
时,线程就会一直停留在这个循环里;直到超时或被手动停止,该函数才会返回。
应用实例
AutoreleasePool
App启动后,苹果在主线程 RunLoop
里注册了两个 Observer
。
第一个 Observer
监视的事件是 Entry
(即将进入Loop),其回调内会调用 _objc_autoreleasePoolPush()
创建自动释放池。其 order 是-2147483647,优先级最高,保证创建释放池发生在其他所有回调之前。
第二个 Observer
监视了两个事件: BeforeWaiting
(准备进入休眠) 时调用_objc_autoreleasePoolPop()
和 _objc_autoreleasePoolPush()
释放旧的池并创建新池;Exit(即将退出Loop) 时调用_objc_autoreleasePoolPop()
来释放自动释放池。这个 Observer 的 order 是 2147483647,优先级最低,保证其释放池子发生在其他所有回调之后。
在主线程执行的代码,通常是写在诸如事件回调、Timer
回调内的。这些回调会被 RunLoop
创建好的 AutoreleasePool
环绕着,所以不会出现内存泄漏。
PerformSelecter
当调用 NSObject
的performSelecter:afterDelay:
后,实际上其内部会创建一个 Timer
并添加到当前线程的 RunLoop
中。所以如果当前线程没有 RunLoop
,则这个方法会失效。
当调用 performSelector:onThread:
时,实际上其会创建一个 Timer
加到对应的线程去,同样的,如果对应线程没有RunLoop
该方法也会失效。
网友评论