简介
- 起因
- 一般来讲，线程一次只能执行一个任务，执行完就会退出，被系统释放。所以为了实现线程执行完任务以后不退出，类似于一种循环，让线程一直处于不断执行任务，使之不退出。
- 这种模型通称为Event loop。在Node.js 叫做事件处理，在Windows中叫做消息循环，在OSX和iOS中叫做RunLoop。
- 模型实现的关键点：
- 如何管理实事件/消息
- 如何让线程在没有处理消息(事件)时进行休眠(避免资源占用)
- 如何在有消息时立即唤醒处理消息(事件)
- 基本设计
RunLoop根据以上的关键点进行设计
- 是一个对象
- 管理其需要处理的消息(事件)
- 提供一个入口函数，让某线程执行了这个函数以后，就一直处于函数内部的
接受消息 ==》等待 ==》处理的循环中，直到退出循环(或者叫做循环结束)的时候，函数返回，线程退出
- OSX/iOS系统中的RunLoop对象
- 在 OSX/iOS系统中提供了两个对象
NSRunLoop 和 CFRunLoopRef - CFRunLoopRef 是在 CoreFoundation 框架内的，它提供了纯 C 函数的 API，所有这些 API 都是线程安全的。
CFRunLoopRef 的代码是开源的，你可以在这里 http://opensource.apple.com/tarballs/CF/CF-855.17.tar.gz 下载到整个 CoreFoundation 的源码。为了方便跟踪和查看，你可以新建一个 Xcode 工程，把这堆源码拖进去看。 - NSRunLoop 是基于 CFRunLoopRef 的封装，提供了面向对象的 API，但是这些 API 不是线程安全的。
- 苹果不允许直接创建 RunLoop，它只提供了两个自动获取的函数：
CFRunLoopGetMain()和CFRunLoopGetCurrent()。
详细介绍
1.与线程的关系
先看一段代码
/// 全局的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 访问 loopsDic 时的锁
static CFSpinLock_t loopsLock;
/**
获取(创建)RunLoop的方法
@param t 线程
*/
// should only be called by Foundation
// t==0 is a synonym for "main thread" that always works
CF_EXPORT CFRunLoopRef _CFRunLoopGet0(pthread_t t) {
// 判断是不是主线程
if (pthread_equal(t, kNilPthreadT)) {
t = pthread_main_thread_np();
}
__CFLock(&loopsLock);
// 判断主线程对应的RunLoop是否存在，不存在的话，执行里面的代码
if (!__CFRunLoops) {
__CFUnlock(&loopsLock);
// 主线程对应的RunLoop是默认创建好的
// 创建字典（以线程为key,以RunLoop为value）
CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks);
// 创建(获取)主线程对应的RunLoop
CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np());
// 字典存储： 以线程为key,以RunLoop为value
CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop);
if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) {
CFRelease(dict);
}
CFRelease(mainLoop);
__CFLock(&loopsLock);
}
// 从字典中获取子线程对应的RunLoop
CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
__CFUnlock(&loopsLock);
if (!loop) {
// 如果子线程对应的RunLoop不存在，就创建子线程对应的RunLoop
CFRunLoopRef newLoop = __CFRunLoopCreate(t);
__CFLock(&loopsLock);
loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
// 把当前子线程对应的RunLoop存储到字段中，以当前子线程为key
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;
}
通俗的解释：
从上面的代码可以看出，线程和 RunLoop 之间是一一对应的，其关系是保存在一个全局的 Dictionary 里。线程刚创建时并没有 RunLoop，如果你不主动获取，那它一直都不会有。RunLoop 的创建是发生在第一次获取时，RunLoop 的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop（主线程除外）。
总结上面的代码关系：
- 每条线程都有唯一的一个与之对应的RunLoop对象，其关系是保存在一个全局的 Dictionary 里
- 主线程的RunLoop已经自动创建好，子线程的RunLoop需要主动创建，并且手动开启
- RunLoop在第一次
获取时创建，在线程结束时销毁
tip 代码演示一下获取RunLoop的代码
2. RunLoop的结构
- 整体结构介绍
RunLoop 结构图如下，其内部由不同mode(运行模型)构成，每个mode又包含一个或者多个的Source/Timer/Observer，这是大致结构，其中有几个要点：
- 一个运行模式(mode)要是至少包含一个Source
或者一个Timer，Observe不是必须的 - RunLoop启动后只能选择一种运行模型(即 CurrentMode)，如果想切换运行模式，必须要先退出当前运行模式
- 这样的设计好处是，通过运行模式分隔开不同组的 Source/Timer/Observer，让其互不影响。
runloop结构图
- 在OSX/iOS系统提供的类
在 CoreFoundation 里面关于 RunLoop 有5个类:
* CFRunLoopRef // 获取（创建）RunLoop
* CFRunLoopModeRef // 运行模式
* CFRunLoopSourceRef // 事件源
* CFRunLoopTimerRef // 定时器
* CFRunLoopObserverRef // 观察者
3.运行模式 mode介绍
转入其他日志https://www.jianshu.com/p/59f525c3c729
- 运行模式分类
-
kCFRunLoopDefaultMode: App的默认 Mode，通常主线程是在这个 Mode 下运行的。 -
UITrackingRunLoopMode: 界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响。 -
kCFRunLoopCommonModes: 这是一个占位的 Mode，没有实际作用。 -
UIInitializationRunLoopMode: 在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用。 -
GSEventReceiveRunLoopMode: 接受系统事件的内部 Mode，通常用不到。
