RunLoop是iOS和OSX开发中非常基础的一个概念.首先从CFRunLoop的源码入手,介绍RunLoop的概念以及底层实现原理.还有苹果是如何利用RunLoop实现自动释放池,延迟回调,触摸事件,屏幕刷新等功能.
RunLoop的概念
一般来讲,一个线程一次只能执行一个任务,执行完成后线程就会退出,如果我们需要一个机制,让先逞能随时处理事件单兵不退出,通常的代码逻辑是这样的.
function loop(){
initialize();
do{
var message = get_next_message();
process_message(message);
}while(message != quit);
}
这种模型通常被称为Event Loop.Event Loop在很多系统和框架里面都有实现,比如Node.js的事件处理,比如Windows程序的消息循环,再比如OSX/iOS的RunLoop.实现这种模型的关键点在于, 如何管理事件/消息,如何让线程在没有处理消息时休眠以避免资源占用.在有消息到来时立刻被唤醒.
所以,RunLoop实际上就是一个对象,这个对象管理了其需要处理的事件和消息,并提供了一个入口函数来执行上面Event Loop的逻辑.线程执行了这个函数后,就会一直处于这个函数内部"接受消息->等待->处理"的循环中,知道这个循环结束(比如传入quit的消息),函数返回.
OSX/iOS系统中,提供了两个这样的对象:NSRunLoop和CFRunLoopRef
CFRunLoopRef是在CoreFoundation框架内的,他提供了纯C函数的API,所有这些API都是线程安全的.
NSRunLoop是基于CFRunLoopRef的封装,提供了面向对象的API,但是这些API不是线程安全的.
CFRunLoopRef的代码是开源的,你可以在这里http://opensource.apple.com/tarballs/CF/下载到整个CoreFoundation的源码来查看.
(Update:Swift开源后,苹果又维护了一个跨平台的CoreFoundation版本:https://github.com/apple/swift-corelibs-foundation/,这个版本的源码可能和现有的iOS系统中的实现略不一样,但更容易编译,而且已经适配了Linux/Windows)
RunLoop与线程的关系
首先,iOS开发中能遇到两个线程对象:pthread_t和NSThread.过去苹果有份文档标明了NSThread只是pthread_t的封装,但是那份文档已经失效了.现在他们也有可能都是直接包装自最底层的mac thread.苹果并没有提供这两个对象互相转换的接口.但不管怎么样,可以肯定的就是pthread_t和NSThread是一一对应的.比如你可以通过pthread_main_thread_np()或者[NSThread mainThread]来获取主线程,也可以通过pthread_self()或者[NSthread currentThread]来获取当前线程.CFRunLoop是基于pthread来管理的.
苹果不允许直接创建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);
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();
CFDictionarySetValue(loopsDic,thread,loop);
///注册一个回调,当线程销毁时候,顺便也销毁其对应的RunLoop
_CFSetTSD(...,thread,loop,_CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
return loop;
}
上面的代码可以看出,线程和RunLoop之间是一一对应的.其关系是保存在一个全局的字典中,线程刚创建时并没有RunLoop.如果你不主动获取.那么他就一直不会有,RunLoop的创建是发生在第一次获取时,RunLoop的销毁是发生在线程结束时,你只能在一个线程的内部获取其RunLoop(主线程除外)
RunLoop对外的接口
在CoreFoundation里面关于RunLoop有5个类.
- CFRunLoopRef
- CFRunLoopModeRef
- CFRunLoopSourceRef
- CFRunLoopTimerRef
- CFRunLoopObserverRef
其中CFRunLoopModeRef类并没有对外暴露,只是通过CFRunLoopRef的接口进行了封装.他们的关系如下:
RunLoop关系表
一个RunLoop包含若干个Mode,每个Mode又包含若干个Source/Timer/Observer.每次调用RunLoop主函数时,只能指定其中一个Mode,这个Mode被称为CurrentMode.如果需要切换Mode,只能退出Loop.再重新指定一个Mode进入,这样做主要是为了分隔开不同组的Source/Timer/Observer.让其互不影响
CFRunLoopSourceRef是事件产生的地方.Source有两个版本:Source()和Source1.
- Source0只包含了一个回调(函数指针).他并不能主动触发事件.使用时,你需要先调用CFRunLoopSourceSignal(Source),将这个Source标记为待处理,然后手动调用CFRunLoopWakeUp(runloop)来唤醒RunLoop,让其处理这个事件
- Source1包含了一个mach_port和一个回调(函数指针),被用于通过内核和其他线程相互发送消息,这种Source能主动唤醒RunLoop的线程.
***CFRunLoopTimerRef ***是基于时间的触发器,它和NSTimer是toll-free bridged的.可以混用.其包含一个时间长度和一个回调(函数指针).当其加入到RRunLoop时,RunLoop会注册对应的时间点,当时间点到时,RunLoop会被唤醒以执行那个回调.
CFRunLoopObserverRef是观察者,每个Observer都包含了一个回调(函数指针),当RunLoop的状态发生变化时,观察者就能通过回调接收到这个变化,可以观察的时间点有以下几个:
typedef CF_OPTIONS(CFOptionFlags,CFRunLoopActivity){
kCFRunLoopEntry == (1UL << 0), // 即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), // 即将退出Loop
}
上面的Source/Timer/Observer被统称为mode item. 一个item可以被同时假如多个mode.但是一个item被重复加入同一个mode时候是不会有效果的.如果一个mode中一个item都没有,则RunLoop会直接退出.不进入循环.
RunLoop的Mode
CFRunLoopMode和CFRunLoop的结构大体如下
struct _CFRunLoopMode{
CFStringRef name; //Mode Name 比如@"KCFRunLoopDefaultMode"
CFMutableSetRef _sources0; //Set
CFMutableSetRef _sources1; //Set
CFMutableArrayRef _observers; //Array
CFMutableArrayRef _timers; //Array
};
struct _CFRunLoop{
CFMutableSetRef _commonModes; //Set
CFMutableSetRef _CommonModeItems; //Set(Source/Timer/Observer)
CFMutableModeRef _currentMode; //Current RunLoop Mode
CFMutableSetRef _modes; //Set
};
这个有个概念叫"CommonModes":一个Mode可以将自己标记为"Common"属性(通过将其ModeName添加到RunLoop的"CommonModes"中).每当RunLoop的内容变化时,RunLoop都会自动将_commonModeItems里的Source/Timer/Observer同步到具有"Common"标记的所有mode里面.
应用场景举例:主线程的RunLoop里有两个预置的Mode:KCFRunLoopDefaultMode和UITrackingRunLoopMode.这两个Mode都已经被标注为"Common"属性.DefaultMode 是App平时所处的状态.TrackingRunLoopMode是追踪ScrollView滑动时候的状态.当你创建一个Timer并加到DefaultMode时候,Timer会得到重复回调.但此时滑动一个TableView时,RunLoop会将mode切换为TrackingRunLoopMode,这是Timer就不会被回调,并且也不会影响到滑动操作.
重点 有时候你需要一个Timer.在两个Mode中都能得到回调.一种办法就是将这个Timer分别加入这两个Mode中. 还有一种方式,就是将NSTimer加入到顶层的RunLoop的"commonModelItems"中. "commonModelItems"被RunLoop自动更新到所有具有"Common"属性的model中去.上面刚刚讲过. 重复看一遍 CommonModes这个概念的讲解
CFRunLoop对外暴露的管理Mode接口只有下面两个
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName); //Mode可以将自己标记为"Common"属性(通过这个方法将其ModeName添加到RunLoop的CommonModes中.)
CFRunLoopRunInMode(CFStringRef modeName,...); //来使当前线程的run
loop以指定模式运行起来一段时间或者直到run loop被停止
***Mode暴露的管理mode item的接口有下面几个:
CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopAddObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopAddTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
CFRunLoopRemoveSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopRemoveObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopRemoveTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
你只能通过mode name来操作内部的mode.当你传入一个新的mode name但RunLoop内部没有对应mode时,RunLoop会自动帮你创建对应的CFRunLoopModeRef.对于一个RunLoop来说. 其内部的mode只能增加不能删除.
苹果公开提供的Model有两个:KCFRunLoopDefaultMode(NSDefaultRunLoopMode)和UITrackingRunLoopMode.你可以用这两个Mode Name来操作其对应的Mode.
同时苹果还提供了一个操作Common标记的字符串:KCFRunLoopCommonModes(NSRunLoopCommonModes),你可以用这个字符串来操作Common Items,或者标记一个Mode为"Common".使用时注意区分这个字符串和其他mode name.
一个Mode中可以有多个Source(事件源,输入源,基于端口事件源,例如键盘触摸等),Observer(观察者,观察当前RunLoop运行状态)和Timer(定时器事件源).但是必须至少有一个Source或者Timer.因为如果Mode为空,RunLoop运行到空模式不会进行空转,就会立即退出.
系统默认注册了5个Mode;
- KCFRunLoopDefaultMode:App默认的Mode.通常主线程是在这个Mode下运行的
- UITrackingRunLoopMode:界面追踪Mode,用于ScrollView追踪触摸滑动.保证界面滑动时不受其他Mode影响.
- UIInitIalizationRunLoopMode: 在刚启动App时进入的第一个Mode,启动完成后就不再使用.
- GSEventReceiveRunLoopMode:接受系统事件内部Mode.通常用不到.
- KCFRunLoopCommonModes:这是一个占位用的Mode,作为标记KCFRunLoopDefaultMode 和 UITrackingRunLoopMode用.并不是一种真正的Mode.
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/observer, 直接返回。
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 即将触发 Source0 (非port) 回调。
__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/observer一个都没有了
retVal = kCFRunLoopRunFinished;
}
/// 如果没超时，mode里没空，loop也没被停止，那继续loop。
} while (retVal == 0);
}
/// 10. 通知 Observers: RunLoop 即将退出。
__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}
可以看到,实际上RunLoop就是这样一个函数,其内部是一个do-while循环,当你调用CFRunLoopRun()时,线程就会一直停留在这个循环中,直到超时或者被手动停止,该函数才会返回.
RunLoop的底层实现
从上面代码可以看出,RunLoop的核心是基于mach port的.其进入休眠时候调用的函数是mach_msg(),为了解释这个逻辑,下面稍微介绍一下OSX/iOS的系统架构.
苹果官方将整个系统大致划分为上述四个层次:
应用层包括用户能接触到的图形应用,例如spotlight,aqua,springBoard等
应用框架层即开发人员接触到的cocoa等框架
核心框架层包括各种核心框架,OPenGL等内容.
Darwin即操作系统的核心,包括系统内核,驱动,shell等内容.这一层是开源的. 其所有开源都可以在 opensource.apple.com里面找到.
我们再深入看一下Darwin这个核心的架构:
其中在硬件层上面的三个组成部分:Mach,BSD,IOKit(还包括一些上面没标注的内容),共同组成了XNU内核.
XNU内核的内环被称为Mach,其作为一个微内核,仅提供了诸如处理器调度,IPC(进程间通讯)等非常少量的基础服务.
BSD层可以作为围绕Mach层的一个外环,其提供了诸如进程管理,文件系统,和网络的功能.
IOKit层为设备驱动提供了一个面向对象(C++)的一个框架.
Mach本身提供的API非常有限,而且苹果也不鼓励使用Mach的API,但是这些API非常基础,如果没有这些API的话,其他任何工作都无法实施,在Mach中,所有的东西都是通过自己的对象实现的, 进程,线程和虚拟内存都被称为"对象",和其他架构不同,Mach的对象间不能直接调用,只能通过消息传递的方式实现对象间的通信,"消息"是Mach中最基础的概念,消息在两个端口(port)之间传递,这就是Mach的IPC(进程间通信)的核心.
Mach的消息定义是在
typedef struct{
mach_msg_header_t header;
mach_msg_body_t body;
} mach_msg_base_t;
typedef struct{
mach_msg_bits_t msgh_bits;
mach_msg_size_t msgh_size;
mach_port_t msgh_remote_port; //目标端口
mach_port_t msgh_local_port; //当前端口
mach_port_name_t msgh_voucher_port;
mach_msg_id_t msgh_id;
} mach_msg_header_t;
一条Mach消息实际上就是一个二进制数据包(BLOB),其中头部定义了当前端口local_port和目标端口remote_port
发送和接受消息是通过同一个API进行的,其option标记了消息传递的方向.
mach_msg_return_t mach_msg(
mach_msg_header_t *msg,
mach_msg_option_t option, //消息传递的方向
mach_msg_size_t send_size,
mach_msg_size_t rcv_size,
mach_port_name_t rcv_name,
mach_msg_timeout_t timeout,
mach_port_name_t notify);
为了实现消息的发送和接收,mach_msg()函数实际上是调用了一个Mach陷阱(trap),即函数mach_msg_trap(),陷阱这个概念在Mach中等同于系统调用,当你在用户态调用mach_msg_trap()时会触发陷阱机制,切换到内核态,内核态中内核实现的mach_msg()函数会完成实际的工作,如下图:
这些概念可以参考维基百科: System_call、 Trap_(computing)。
RunLoop的核心就是一个mach_msg()(上面代码第7步),RunLoop调用这个函数去接收消息,如果没有别人发送port消息过来,内核会将线程置于等待状态,例如你在模拟器里跑起来一个iOS的app,然后再App静止的时候点击暂停,你会看到主线程调用栈是停留在mach_msg_trap()这个地方.
关于具体的如何利用mach port发送消息,可以看看 NSHipster 这一篇文章，或者 这里的中文翻译 。
关于Mach的历史可以看看这篇很有趣的文章： Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian。
苹果用RunLoop实现的功能
首先我们可以看一下App启动后RunLoop的状态:
CFRunLoop {
current mode = kCFRunLoopDefaultMode
common modes = {
UITrackingRunLoopMode
kCFRunLoopDefaultMode
}
common mode items = {
// source0 (manual)
CFRunLoopSource {order =-1, {
callout = _UIApplicationHandleEventQueue}}
CFRunLoopSource {order =-1, {
callout = PurpleEventSignalCallback }}
CFRunLoopSource {order = 0, {
callout = FBSSerialQueueRunLoopSourceHandler}}
// source1 (mach port)
CFRunLoopSource {order = 0, {port = 17923}}
CFRunLoopSource {order = 0, {port = 12039}}
CFRunLoopSource {order = 0, {port = 16647}}
CFRunLoopSource {order =-1, {
callout = PurpleEventCallback}}
CFRunLoopSource {order = 0, {port = 2407,
callout = _ZL20notify_port_callbackP12__CFMachPortPvlS1_}}
CFRunLoopSource {order = 0, {port = 1c03,
callout = __IOHIDEventSystemClientAvailabilityCallback}}
CFRunLoopSource {order = 0, {port = 1b03,
callout = __IOHIDEventSystemClientQueueCallback}}
CFRunLoopSource {order = 1, {port = 1903,
callout = __IOMIGMachPortPortCallback}}
// Ovserver
CFRunLoopObserver {order = -2147483647, activities = 0x1, // Entry
callout = _wrapRunLoopWithAutoreleasePoolHandler}
CFRunLoopObserver {order = 0, activities = 0x20, // BeforeWaiting
callout = _UIGestureRecognizerUpdateObserver}
CFRunLoopObserver {order = 1999000, activities = 0xa0, // BeforeWaiting | Exit
callout = _afterCACommitHandler}
CFRunLoopObserver {order = 2000000, activities = 0xa0, // BeforeWaiting | Exit
callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}
CFRunLoopObserver {order = 2147483647, activities = 0xa0, // BeforeWaiting | Exit
callout = _wrapRunLoopWithAutoreleasePoolHandler}
// Timer
CFRunLoopTimer {firing = No, interval = 3.1536e+09, tolerance = 0,
next fire date = 453098071 (-4421.76019 @ 96223387169499),
callout = _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv (QuartzCore.framework)}
},
modes ＝ {
CFRunLoopMode {
sources0 = { /* same as 'common mode items' */ },
sources1 = { /* same as 'common mode items' */ },
observers = { /* same as 'common mode items' */ },
timers = { /* same as 'common mode items' */ },
},
CFRunLoopMode {
sources0 = { /* same as 'common mode items' */ },
sources1 = { /* same as 'common mode items' */ },
observers = { /* same as 'common mode items' */ },
timers = { /* same as 'common mode items' */ },
},
CFRunLoopMode {
sources0 = {
CFRunLoopSource {order = 0, {
callout = FBSSerialQueueRunLoopSourceHandler}}
},
sources1 = (null),
observers = {
CFRunLoopObserver >{activities = 0xa0, order = 2000000,
callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}
)},
timers = (null),
},
CFRunLoopMode {
sources0 = {
CFRunLoopSource {order = -1, {
callout = PurpleEventSignalCallback}}
},
sources1 = {
CFRunLoopSource {order = -1, {
callout = PurpleEventCallback}}
},
observers = (null),
timers = (null),
},
CFRunLoopMode {
sources0 = (null),
sources1 = (null),
observers = (null),
timers = (null),
}
}
}
可以看到,系统默认注册了5个Mode;
- kCFRunLoopDefaultMode: App的默认Mode,通常主线程是在这个Mode下运行的.
- UITrackingRunLoopMode: 界面追踪Mode,用于ScorllView追踪触摸事件,保证界面滑动时不受到其他Mode影响.
- UIInitializationRunLoopMode: 在刚启动App时进入的第一个Mode,启动完成后就不会再使用.
- GSEventReceiveRunLoopMode:接受系统事件的内部Mode,通常用不到.
- KKCFRunLoopCommonModes:这是一个占位的Mode,没有实际作用
你可以在这里看到更多的苹果内部的 Mode，但那些 Mode 在开发中就很难遇到了。
当RunLoop进行回调时,一般都是通过一个很长的函数调出去(call out),当你在你的代码中下断点调试时,通常能在调用栈上看到这些函数,下面是这几个函数的整理版本,如果你在调用栈中看到这些长函数名,在这里查找一下就能定位到具体的调用地点了:
{
/// 1. 通知Observers，即将进入RunLoop
/// 此处有Observer会创建AutoreleasePool: _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
do {
/// 2. 通知 Observers: 即将触发 Timer 回调。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: 即将触发 Source (非基于port的,Source0) 回调。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 4. 触发 Source0 (非基于port的) 回调。
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 6. 通知Observers，即将进入休眠
/// 此处有Observer释放并新建AutoreleasePool: _objc_autoreleasePoolPop(); _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeWaiting);
/// 7. sleep to wait msg.
mach_msg() -> mach_msg_trap();
/// 8. 通知Observers，线程被唤醒
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopAfterWaiting);
/// 9. 如果是被Timer唤醒的，回调Timer
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
/// 9. 如果是被dispatch唤醒的，执行所有调用 dispatch_async 等方法放入main queue 的 block
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block);
/// 9. 如果如果Runloop是被 Source1 (基于port的) 的事件唤醒了，处理这个事件
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__(source1);
} while (...);
/// 10. 通知Observers，即将退出RunLoop
/// 此处有Observer释放AutoreleasePool: _objc_autoreleasePoolPop();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopExit);
}
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了
事件响应
苹果注册了一个Source1(基于mach port的)用来接收系统事件,其回调函数为_IOHIDEventSystemClientQueueCallback();
当一个硬件事件(触摸/锁屏/摇晃等)发生后,首先由IOKit.framework生成一个IOHIDEvent事件并由SpringBoard接收,这个过程的详细情况可以参考这里。SpringBoard只接收按键(锁屏/静音等),触摸,加速,接近传感器等几种Event,随后用mach port转发给需要的App进程,随后苹果注册的那个Source1就会触发回调,并调用_UIApplicationHandleEventQueue()进行应用内部的分发.
_UIApplicationHandleEventQueue()会把IOHIDEvent处理并包装成UIEvent进行处理或者分发,其中包括了UIGesture/处理屏幕旋转/发送给UIWindow等,通常事件比如UIButton点击,touchesBegin/Move/End/Cancel事件都是在这个回调中完成的.
手势识别
当上面的_UIApplicationHandleEventQueue()识别了一个手势,其首先会调用Cancel将当前的touchesBegin/Move/End系列回调打断,随后系统将对应的UIGestureRecognizer标记为待处理.
当有UIGestureRecognizer变化(创建/销毁/状态改变)时,这个回调都会进行相应处理.
界面更新
当在操作UI时,比如改变了frame,更新了UIView/CALayer的层次时,或者手动调用了UIView/CALayer的setNeedsLayout/setNeedsDisPlay方法后,这个UIView/CALayer就被标记为待处理,并被提交到一个全局的容器中.
苹果注册了一个Observer监听BeforeWaiting(即将进入休眠)和Exit(即将推出Loop)事件,回调去执行一个很长的函数:
_ZN2CA11Transaction17observer_callbackEP19_CFRunLoopObserverPV().这个函数里会遍历所有待处理的UIView/CALayer以执行实际的描绘和调整.并更新UI界面.
这个函数内部的调用栈大概是这样的.
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
QuartzCore:CA::Transaction::observer_callback:
CA::Transaction::commit();
CA::Context::commit_transaction();
CA::Layer::layout_and_display_if_needed();
CA::Layer::layout_if_needed();
[CALayer layoutSublayers];
[UIView layoutSubviews];
CA::Layer::display_if_needed();
[CALayer display];
[UIView drawRect];
定时器
NSTimer其实就是CFRunLoopTimerRef,他们之间是toll_free bridged,一个NSTimer注册到RunLoop后, RunLoop会为其重复的时间点注册好事件,例如 10:00 12:00这几个时间点,RunLoop为了节省资源,并不会在非常准确的时间点回调这个Timer,Timer有个属性叫做Tolerance(宽容度),标示了当前时间点后,容许有多少最大误差.
如果某个时间点被错过了,例如执行了一个很长的任务,则那个时间点的回调也会跳过去,不会延后执行就比如等公交,如果10:10的没有赶上, 就只能等10:40这一趟了.
CADisplayLink是一个和屏幕刷新率一致的定时器(但实际实现原理更复杂,和NSTimer并不一样,其内部实际上是操作了一个Souce),如果在两次屏幕刷新之间执行了一个长任务,那其中就会有一帧被跳过去(和NSTimer类似),造成界面卡顿的感觉,在快速滑动TableView时,即使一帧的卡顿.用户也会有所察觉,FaceBook开源的AsyncDisplayLink就是为了解决界面卡顿的问题.其内部也用到了RunLoop.
PerformSelecter
当调用NSObject的performSelcter:afterDelay:后,实际上其内部会创建一个Timer并添加到当前线程的RunLoop中, 所以如果当前的线程没有RunLoop,则这个方法会失效.
当调用performSelctor:onThread:时,实际上其会创建一个Timer加到对应的线程中,同样的.如果 对应的线程没有RunLoop该方法也会失效.
关于GCD
实际上RunLoop底层也会用到GCD的东西,(NSTimer使用了XNU内核的mk_timer驱动,并非GCD驱动),但同时GCD提供的某些接口夜用到了RunLoop,例如dispatch_async().
当调用dispatch_async(dispatch_get_main_queue(),block)时,libDispatch会向主线程的RunLoop发送消息,RunLoop会被唤醒,并从消息中取得这个block,并在回调CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里执行这个 block。但这个逻辑仅限于dispatch到主线程,dispatch到其他线程仍然是由libDispatch()处理的.
关于网络请求
iOS中,关于网络请求的接口自下而上有如下几层
CFSocket
CFNetwork ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession ->AFNetworking2, Alamofire
- CFSocket 是最底层的接口,只负责socket通信
- CFNetwork 是基于CFSocket等接口的上层封装,ASIHttpRequest工作于这一层.
- NSURLConnection是基于CFNetwork的更高层的封装,提供面向对象的接口,AFNetworking工作于这一层.
- NSURLSession 是iOS7中新增加的接口,表面上和NSURLConnection并列,但底层仍然用到了NSURLConnection的部分功能(比如com.apple.NSURLConnectionLoader线程).
AFNetworking2 和ALAmofire工作于这一层.
下面主要介绍NSURLConnection的工作过程
通常使用NSURLConnection时,你会传入一个Deleagete,当调用[connection start]后,这个Delegate就会不停收到事件回调,实际上,start这个函数的内部会获取CurrentRunLoop,然后在其中的DefaultMode中添加了四个source0(即需要手动触发的Source),CFMulitiplexerSource是负责各种Delegate回调的,CFHTTPCookieStorage是处理各种Cookie的.
当开始网络传输时,我们可以看到NSURLConnection创建了两个线程:
***com.apple.NSURLConnectionLoader ***和 com.apple.CFSocket.private。其中CFSocket线程是处理底层socket连接的,NSURLConectionLoader这个线程内部会使用RunLoop来接收底层socket的事件,并通过之前添加的Source0通知到上层的Delegate.
NSURLConnectionLoader中的RunLoop通过一些基于mach port的Source接受来自顶层CFSocket的通知,当收到通知后,其会在合适的时机向CFMultiplexerSource等Source0发送通知,同时唤醒Delegate线程的RunLoop来让其处理这些通知,CFNultiplexerSource会在Delegate线程RunLoop对Delegate执行实际的回调.
RunLoop的实际应用举例
AFNetworking
AFURLConnectionOperation 这个类是基于 NSURLConnection 构建的，其希望能在后台线程接收Delegate回调,为此AFNetworking单独创建了一个线程,并在这个线程中启动了一个RunLoop;
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
@autoreleasepool {
[[NSThread currentThread] setName:@"AFNetworking"];
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runLoop run];
}
}
+ (NSThread *)networkRequestThread {
static NSThread *_networkRequestThread = nil;
static dispatch_once_t oncePredicate;
dispatch_once(&oncePredicate, ^{
_networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
[_networkRequestThread start];
});
return _networkRequestThread;
}
RunLoop启动前内部必须要至少一个Timer/Observer/Source. 所以AFNetworking在[runloop run]之前先创建了一个新的NSMachPort添加进去了.通常情况下,调用者需要持有这个NSMachPort(mach_port)并在外部线程通过这个port发送消息到loop内,但此处添加port只是为了让RunLoop不至于退出,并没有用于实际的发送消息
- (void)start {
[self.lock lock];
if ([self isCancelled]) {
[self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
} else if ([self isReady]) {
self.state = AFOperationExecutingState;
[self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
}
[self.lock unlock];
}
当需要这个后台线程执行任务时,AFNetworking通过调用[NSObject performSelector: onThread:]将这个任务让盗了后台线程的RunLoop中.
AsyncDisplayKit
AsyncDisplayKit 是 Facebook 推出的用于保持界面流畅性的框架，其原理大致如下：
UI线程中一旦出现繁重的任务就会导致界面卡顿,这类任务通常分为三类:排版,绘制,UI对象操作.
排版通常包括计算视图大小,计算文本高度,重新计算子视图的排版等操作.绘制一般有文字绘制(例如CoreText),图片绘制(比如预先解压),元素绘制(Quartz)等操作.UI对象操作通常包括UIView/CALayer等UI对象的创建,设置属性和销毁.
其中前两类操作可以通过各种方法扔到后台线程执行，而最后一类操作只能在主线程完成，并且有时后面的操作需要依赖前面操作的结果 （例如TextView创建时可能需要提前计算出文本的大小）。ASDK 所做的，就是尽量将能放入后台的任务放入后台，不能的则尽量推迟 (例如视图的创建、属性的调整)。
为此，ASDK 创建了一个名为 ASDisplayNode 的对象，并在内部封装了 UIView/CALayer，它具有和 UIView/CALayer 相似的属性，例如 frame、backgroundColor等。所有这些属性都可以在后台线程更改，开发者可以只通过 Node 来操作其内部的 UIView/CALayer，这样就可以将排版和绘制放入了后台线程。但是无论怎么操作，这些属性总需要在某个时刻同步到主线程的 UIView/CALayer 去。
ASDK 仿照 QuartzCore/UIKit 框架的模式，实现了一套类似的界面更新的机制：即在主线程的 RunLoop 中添加一个 Observer，监听了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回调时，遍历所有之前放入队列的待处理的任务，然后一一执行。具体的代码可以看这里：_ASAsyncTransactionGroup。