RunLoop入门提高

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;

1. KCFRunLoopDefaultMode:App默认的Mode.通常主线程是在这个Mode下运行的
2. UITrackingRunLoopMode:界面追踪Mode,用于ScrollView追踪触摸滑动.保证界面滑动时不受其他Mode影响.
3. UIInitIalizationRunLoopMode: 在刚启动App时进入的第一个Mode,启动完成后就不再使用.
4. GSEventReceiveRunLoopMode:接受系统事件内部Mode.通常用不到.
5. KCFRunLoopCommonModes:这是一个占位用的Mode,作为标记KCFRunLoopDefaultMode 和 UITrackingRunLoopMode用.并不是一种真正的Mode.

---

RunLoop的内部逻辑

根据苹果在文档里的说明.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的系统架构.

OSX/iOS系统架构
苹果官方将整个系统大致划分为上述四个层次:
应用层包括用户能接触到的图形应用,例如spotlight,aqua,springBoard等
应用框架层即开发人员接触到的cocoa等框架
核心框架层包括各种核心框架,OPenGL等内容.
Darwin即操作系统的核心,包括系统内核,驱动,shell等内容.这一层是开源的. 其所有开源都可以在opensource.apple.com里面找到.
我们再深入看一下Darwin这个核心的架构:
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的消息定义是在<mach/message.h>头文件的,很简单:

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;

1. kCFRunLoopDefaultMode: App的默认Mode,通常主线程是在这个Mode下运行的.
2. UITrackingRunLoopMode: 界面追踪Mode,用于ScorllView追踪触摸事件,保证界面滑动时不受到其他Mode影响.
3. UIInitializationRunLoopMode: 在刚启动App时进入的第一个Mode,启动完成后就不会再使用.
4. GSEventReceiveRunLoopMode:接受系统事件的内部Mode,通常用不到.
5. 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.

NSURLConnection工作原理
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。