iOS---RunLoop深度剖析
前言
-
RunLoop是iOS/OS开发中比较基础的一个概念，在苹果开发中用在事件处理，延迟加载，屏幕刷新等功能的处理，其实抛开语言，RunLoop是一个的架构模式，也就是RunLoop不仅仅局限于iOS开发。
-
网上有很多关于RunLoop的干货，但大多不怎么全，这位哥们的写的挺好的，挺详细的，基本上把要说的都说了，底层也研究的很细，本文基本上是转载他的，只是在它的基础上，基于我的知识水平补充了一些，原文： http://www.cocoachina.com/ios/20150601/11970.html
-
官方有已经有 关于RunLoop的官方文档 ，英语的，不过网上已经有人把它翻译为中文了，大家可以去看看.
概念
-
简单来说RunLoop是线程的基本架构模式，架构模式，架构模式-重要的事情说三遍，然并卵，具体怎么做呢，就是有事做事，没事睡觉，有事叫我，就这样，想看详细的自己看中文文档去，毕竟文档哪里已经写的好详细了，再板书就没意义了。
-
分类(获取)：苹果提供了两个途径来获取分别是Cocoe里面定义的NSRunLoop以及CoreFoundation里面定义的CFRunLoopRef。
- CFRunLoopRef提供了纯C函数的API，所有这些API都是线程安全的。
- NSRunLoop提供了面向对象的API，但这些API不是线程安全的。
- 创建，苹果官方对CFRunLoopRef进行了开源，在这里 官方源码 下载就好，苹果官方不提供向我们平时那样子的新建对象的方法来获取NSRunLoop实例，但是可以通过[NSRunLoop getCurrentLoop]来创建，接下来看看具体是怎么创建的把,Show code！
// 全局字典，用来存放线程对应的RunLoop // key是线程，value是RunLoop实例，换言之线程与RunLoopRunLoop一一对应 static CFMutableDictionaryRef __CFRunLoops = NULL; static CFSpinLock_t loopsLock = CFSpinLockInit; // 当t == 0 的时候，代表主线程 CF_EXPORT CFRunLoopRef _CFRunLoopGet0(pthread_t t) { // 如果存进来的线程等于 0 if (pthread_equal(t, kNilPthreadT)) { // 那么当前线程等于主线程 t = pthread_main_thread_np(); } // 给操作加锁 __CFSpinLock(&loopsLock); // 如果当前RunLoop没有为空，创建。 if (!__CFRunLoops) { __CFSpinUnlock(&loopsLock); CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks); CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np()); // 把线程与RunLoop一一对应的存进字典 CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop); if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) { CFRelease(dict); } CFRelease(mainLoop); __CFSpinLock(&loopsLock); } // 获取当前线程的RunLoop CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t)); __CFSpinUnlock(&loopsLock); // 如果不是主线程并且之前没有创建，也即是为空 if (!loop) { CFRunLoopRef newLoop = __CFRunLoopCreate(t); __CFSpinLock(&loopsLock); loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t)); if (!loop) { // 把当前子线程和创建的RunLoop一一对应的存进字典 CFDictionarySetValue(__CFRunLoops, pthreadPointer(t), newLoop); loop = newLoop; } // don't release run loops inside the loopsLock, because CFRunLoopDeallocate may end up taking it __CFSpinUnlock(&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; } - 上面是苹果开源的CFRunLoop中获取RunLoop的代码，简而言之就是，在调用这个方法要存进一个PThread(PThread提供了跨平台的管理多线程的API)，利用这个PThread作为全局字典中的key，并创建与之对应的RunLoop作为Value.RunLoop在我们获取的时候创建，不获取不创建，主线程的RunLoop在一开始就自动创建。
简而言之，线程与RunLoop一一对应
对外接口
- 在CoreFoundation里面关于RunLoop有5个类
- CFRunLoopTimerRef
- CFRunLoopObserverRef
- CFRunLoopSourceRef
- CFRunLoopRef
- CFRunLoopModeRef
其中CFRunLoopModeRef类没有对外暴露，只是通过CFRunLoopRef接口进行了封装
- 一个RunLoop包含若干个Mode,每个Mode又包含若干个source/Timer/Observer,如图。
-
每次调用RunLoop的主函数时，只能指定其中一个Mode作为CurrentMode(可以通过这个属性获取当前的Mode),只能退出Loop,在重新指定一个Mode进入。在这里需要清楚的是，系统默认注册了5个Mode
- NSDefaultRunLoopMode:App默认Mode,当没有接收到ScrollView滚动是，主线程通常使用这个Mode
-
NSTrackingRunLoopMode:到接收到ScroolView或其子类的时候，主线程就会切换到这个模式下运行。
-
UIInitializationRunLoopMode：当App启动时使用的第一个Mode,当启动完成后不再使用。
- NSRunLoopCommonModes，是一个tag,本质上不是一个Mode,默认NSDefaultRunLoopMode和NSTrackingRunLoopMode都绑定这个tag。(应用场景：有时候我们需要添加一个NSTimer在RunLoop,在这时需要制定一个Modes，现在的需求是:我们既要在默认模式下要监听，在滚动模式下也要监听，但只能制定一个模式，这是可以制定这个CommonMode)
- GSEventReceiveRunLoopMode：接受系统内部的Mode,通常做不到。
- 处理不同事件使用不同的Mode，可以最大限度的把性能的最大化处理不同分类的事件，提高性能。
-
CFRunLoopSourceRef：事件产生的地方，按照函数调用栈来分，Source的分类可以分为
- Source0：非基于Port的，只包含一个回调(函数指针)，他并不能主动触发事件。使用时，你需要先把这个Source标记为待处理，然后手动调用CFRunLoopWakeUp(RunLoop)，然后再让它执行。
- Source1：基于Port的，通过内核和其他线程通信分发的、系统事件。
- 这里的Port是线程间通信的一种方式，简而言之，如果两个线程之间想通信，可以对方的Port来通信。
- CFRunLoopTimerRef
- 基于时间触发器，当其加入RunLoop时，RunLoop会注册对应的时间点，当时间点到，RunLoop会被唤醒执行里面的回调。
-
CFRunLoopObserverRef
- 这是观察者，能够监听RunLoop的状态改变。
-
可以监听的时间点有以下几个。
/* Run Loop Observer Activities */ 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 kCFRunLoopAllActivities = 0x0FFFFFFFU }; - 上面的Source/Timer/Observer被统称为mode item,一个item可以被同时加入多个mode。但一个item被重复加入同一个mode时不会有效果，如果一个item里面一个mode也没有，则RunLoop刚创建就被退出，不进入循环，这里在线程常驻的时候会讲到。
-
CFRunLoop对外暴露的管理Mode的接口只有下面2个
CF_EXPORT SInt32 CFRunLoopRunInMode(CFStringRef mode, CFTimeInterval seconds, Boolean returnAfterSourceHandled); CF_EXPORT void CFRunLoopAddCommonMode(CFRunLoopRef rl, CFStringRef mode); -
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没有对应的mode.RunLoop会自动帮你创建对应的CFRunLoopModeRef。对于一个RunLoop来说，其内部的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 的核心是基于 mach port 的，其进入休眠时调用的函数是mach_msg()。为了解释这个逻辑，下面稍微介绍一下 OSX/iOS 的系统架构
- 苹果官方将整个系统大致划分为上述4个层次：
- 应用层包括用户能接触到的图形应用，例如 Spotlight、Aqua、SpringBoard 等。
- 应用框架层即开发人员接触到的 Cocoa 等框架。
- 核心框架层包括各种核心框架、OpenGL 等内容。
- Darwin 即操作系统的核心，包括系统内核、驱动、Shell 等内容，这一层是开源的，其所有源码都可以在 苹果开源源码 里找到。
- 我们在深入看一下 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)，即函数ach_msg_trap()，陷阱这个概念在Mach中等同于系统调用。当你在用户态调用mach_msg_trap()时会触发陷阱机制，切换到内核态；内核态中内核实现的 mach_msg() 函数会完成实际的工作，如下图：
-
RunLoop 的核心就是一个mach_msg()(见上面代码的第7步)，RunLoop 调用这个函数去接收消息，如果没有别人发送 port 消息过来，内核会将线程置于等待状态。例如你在模拟器里跑起一个 iOS 的 App，然后在App静止时点击暂停，你会看到主线程调用栈是停留在 mach_msg_trap() 这个地 -
当 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); } RunLoop 的实际应用举例
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(基于machport的)用来接收系统事件，其回调函数为 __IOHIDEventSystemClientQueueCallback()。
-
当一个硬件事件(触摸/锁屏/摇晃等)发生后，首先由IOKit.framework 生成一个 IOHIDEvent事件并由SpringBoard接收。这个过程的详细情况可以参考这里。SpringBoard只接收按键(锁屏/静音等)，触摸，加速，接近传感器等几种 Event，随后用macport转发给需要的App进程。随后苹果注册的那个 Source1 就会触发回调，并调用_UIApplicationHandleEventQueue() 进行应用内部的分发。
-
_UIApplicationHandleEventQueue() 会把 IOHIDEvent 处理并包装成 UIEvent 进行处理或分发，其中包括识别UIGesture/处理屏幕旋转/发送给 UIWindow 等。通常事件比如UIButton点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的。
手势识别
-
当上面的 _UIApplicationHandleEventQueue()识别了一个手势时，其首先会调用 Cancel 将当前的touchesBegin/Move/End系列回调打断。随后系统将对应的 UIGestureRecognizer 标记为待处理。
-
- 苹果注册了一个 Observer 监测 BeforeWaiting(Loop即将进入休眠) 事件，这个Observer的回调函数是_UIGestureRecognizerUpdateObserver()，其内部会获取所有刚被标记为待处理的GestureRecognizer，并执行GestureRecognizer的回调。
-
当有 UIGestureRecognizer的变化(创建/销毁/状态改变)时，这个回调都会进行相应处理。
界面更新
-
当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 层次时，或者手动调用了UIView/CALayer的setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer就被标记为待处理，并被提交到一个全局的容器去。
-
苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件，回调去执行一个很长的函数：
-
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的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,10:10,10:20这几个时间点。RunLoop为了节省资源，并不会在非常准确的时间点回调这个Timer。Timer 有个属性叫做 Tolerance (宽容度)，标示了当时间点到后，容许有多少最大误差。
-
如果某个时间点被错过了，例如执行了一个很长的任务，则那个时间点的回调也会跳过去，不会延后执行。就比如等公交，如果10:10时我忙着玩手机错过了那个点的公交，那我只能等 10:20 这一趟了。
-
CADisplayLink 是一个和屏幕刷新率一致的定时器（但实际实现原理更复杂，和 NSTimer 并不一样，其内部实际是操作了一个Source）。如果在两次屏幕刷新之间执行了一个长任务，那其中就会有一帧被跳过去（和 NSTimer 相似），造成界面卡顿的感觉。在快速滑动TableView时，即使一帧的卡顿也会让用户有所察觉。Facebook开源的AsyncDisplayLink就是为了解决界面卡顿的问题，其内部也用到了RunLoop。
-
解决方案:如果有某些需求或者有强迫症的同学一定要做到时刻准确，那么可以用GCD的定时器来实现(下面应用场景会有讲到)。
PerformSelecter(利用RunLoop常驻线程)
-
当调用 NSObject的performSelecter:afterDelay:后，实际上其内部会创建一个 Timer 并添加到当前线程的RunLoop中。所以如果当前线程没有 RunLoop，则这个方法会失效。
-
当调用 performSelector:onThread: 时，实际上其会创建一个 Timer 加到对应的线程去，同样的，如果对应线程没有RunLoop该方法也会失效。
GCD
-
实际上 RunLoop 底层也会用到 GCD 的东西，比如 RunLoop 是用 dispatch_source_t 实现的 Timer。但同时 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 的工作过程。
-
通常使用 NSURLConnection 时，你会传入一个Delegate，当调用了 [connection start]后，这个Delegate会不停收到事件回调。实际上，
start这个函数的内部会会获取CurrentRunLoop，然后在其中的DefaultMode添加了4个 Source0(即需要手动触发的Source)。CFMultiplexerSource是负责各种 Delegate回调的，CFHTTPCookieStorage是处理各种Cookie 的。 -
当开始网络传输时，我们可以看到NSURLConnection创建了两个新线程：com.apple.NSURLConnectionLoader和com.apple.CFSocket.private。其中 CFSocket程是处理底层socket连接的。NSURLConnectionLoader 这个线程内部会使用RunLoop来接收底层socket的事件，并通过之前添加的 Source0 通知到上层的 Delegate。
-
-
NSURLConnectionLoader 中的 RunLoop 通过一些基于 mach port 的 Source 接收来自底层CFSocket的通知。当收到通知后，其会在合适的时机向 CFMultiplexerSource等Source0发送通知，同时唤醒 Delegate 线程的RunLoop来让其处理这些通知。CFMultiplexerSource 会在 Delegate 线程的 RunLoop 对Delegate执行实际的回调。
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 启动前内部必须要有至少一个item(Obsever除外)，所以 AFNetworking在[runLooprun]之前先创建了一个新的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]; } - 注意
RunLoop 启动前内部必须要有至少一个item，虽然Obsever也是item的一种，但是只会等待Timer和Source ，Timer是因为有回调，Source是会接收事件，所以当RunLoop里面有Timer或者Source的时候，RunLoop会等待里面的item(除Obsever以外)主动给他发消息，然后Oberver被动的接收RunLoop发送过来的消息，亦即是说，能主动给RunLoop发消息的item会让RunLoop跑起来并且不退出。
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) { }); CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode); [[NSRunLoop currentRunLoop] run]; - 当需要这个后台线程执行任务时，AFNetworking 通过调用[NSObject performSelector:onThread:..] 将这个任务扔到了后台线程的 RunLoop 中。
AsyncDisplayKit
-
AsyncDisplayKit是Facebook推出的用于保持界面流畅性的框架，其原理大致如下：
-
UI 线程中一旦出现繁重的任务就会导致界面卡顿，这类任务通常分为3类：排版，绘制，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 事件，在收到回调时，遍历所有之前放入队列的待处理的任务，然后一一执行。
常驻线程
- 有这么一个需求，我们要在子线程中没接收一个事件就调用一次方法。但是子线程在完成任务后就销毁，全局变量强引用？试试
- (void)viewDidLoad { [super viewDidLoad]; NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(run:) object:@"etund"]; self.thread = thread; NSLog(@"-----%p",[NSRunLoop currentRunLoop]); [self.thread start]; } - (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ [self performSelector:@selector(test) onThread:self.thread withObject:nil waitUntilDone:NO]; } - (void)run:(NSString *)name{ NSLog(@"=========="); } - (void)test{ NSLog(@"------------------"); } 结果不能执行，这里要清楚线程的5个状态，新建，就绪，运行，阻塞，死亡。意思就是就算你是强引用一个子线程，但是他执行完任务就已经处于死亡状态了，只是他还存储在内存， 那么现在分析一下。
- 想在子线程中不断执行任务，必须保证子线不处于死亡状态 - 但是子线程执行完一次任务就进入死亡状态 - 那我们可以把线程停留在进入死亡状态之前，这里可以用RunLoop- 我们可以在线程初始化的时候执行的方法中给他创建一个运行时RunLoop,这是他就可以不断接收source，也就是这样
- (void)run:(NSString *)name{ [[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode]; // 1 [[NSRunLoop currentRunLoop] run]; } 注意：上面第一行代码必须加上，因为一个RunLoop里面必须有至少一个item(Obsever除外)
GCD定时器
- 有这么一个需求，需要这么一个定时器，误差几乎为0的定时器，但是无论是NSTimer还是CGDisplayLink都会有误差，而且误差都比较大，这是我们可以用GCD来实现定时器，实际上，上面已经说了，RunLoop底层也是调用GCD的source来实现NSTimer的，只是NSTimer还受mode的影响，下面来看看怎么用GCD实现
// 获取队列 dispatch_queue_t queue = dispatch_get_main_queue(); // 创建定时器 self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue); // 设置定时器属性(什么时候开始，间隔多大) // 定义开始时间 dispatch_time_t start = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * NSEC_PER_SEC)); // 定义时间间隔 uint64_t interver = (uint64_t)(1.0 * NSEC_PER_SEC); // 设置开始时间和时间间隔 dispatch_source_set_timer(self.timer, start,interver, 0); // 设置回调 dispatch_source_set_event_handler(self.timer, ^{ NSLog(@"==================") ; }); // dispatch_cancel(self.timer); // self.timer = nil; // 取消定时器 // 启动定时器 dispatch_resume(self.timer); 正文到此结束
- 本文标签： remote 公交 UI API HTML 操作系统 Connection 端口 swap 系统架构 管理 App 参数 同步 tab tar 安全 Facebook CTO value 开源 源码 apr NSA Apple key 苹果 翻译 struct cat IDE 时间 实例 final update ip 进程 数据 需求 URLs 锁 spring shell 线程 调试 代码 Select volatile node find 开发者 多线程 遍历 开发
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
