<p>RunLoop，顾名思义就是跑圈，相信每个iOS开发者都听闻过，但是好多人都是一知半解，毋庸置疑，RunLoop是iOS进阶过程中不可逃避的一个坎，面试的时候也遇到过不少相关问题吧，所以咯，逃不出的圈子 -- RunLoop</p>    <h3>问题</h3>    <ul>     <li>当scroll滑动时，同页面上的定时器为什么会暂停？</li>     <li>怎么在tableview滑动时延迟加载图片来提高流畅度？</li>     <li>常说的AFNetworking常驻线程保活是什么原理？<br> ...</li>    </ul>    <h3>基本概念</h3>    <p>其实上述问题都与RunLoop有关系，要想弄清楚其中的原因，就需要理解RunLoop到底是什么？</p>    <h3>RunLoop：让线程能随时处理事件但并不退出的一种机制</h3>    <p>我们知道每个程序的入口都是main函数：</p>    <pre>  <code class="language-objectivec">int main(int argc, char * argv[]) {      @autoreleasepool {          return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));      }  }</code></pre>    <p>就这么几行代码，可是不应该是代码执行完后程序就结束了吗？那我们见到的程序是怎么能长时间保持在活跃状态的？这一切都是RunLoop的功劳，其实UIApplicationMain()会创建主线程，主线程内部会主动开启一个RunLoop，而RunLoop本质上就是一个do-while循环，只要条件满足，就会不停的循环，进而程序一直保持运行的状态。RunLoop源码：</p>    <pre>  <code class="language-objectivec">void CFRunLoopRun(void) {    /* DOES CALLOUT */      int32_t result;      do {          result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);          CHECK_FOR_FORK();      } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);  }</code></pre>    <p>原来程序是这样子一直运行的呀，一直单纯这样循环是不是会影响性能？所以RunLoop在这机制的关键在于： 如何管理事件/消息，如何让线程在没有处理消息时休眠以避免资源占用、在有消息到来时立刻被唤醒</p>    <p>要了解这种机制，我们只有进一步分析源代码了。我们先看看RunLoop相关的API：</p>    <ul>     <li>CFRunLoopRef：CoreFoundation 框架内的，基于C语言</li>     <li>NSRunLoop：基于CFRunLoopRef的进一步封装，提供了面向对象的 API</li>    </ul>    <p>所以我们下面都是基于对CFRunLoopRef的源码分析，在 CoreFoundation 里面关于 RunLoop 有5个类:</p>    <pre>  <code class="language-objectivec">CFRunLoopRef //就是RunLoop，提供CFRunLoopGetMain()和CFRunLoopGetCurrent()  CFRunLoopModeRef //RunLoop运行模式  CFRunLoopSourceRef //RunLoop里面内容 -- 事件源，输入源  CFRunLoopTimerRef //RunLoop里面内容 -- 定时器  CFRunLoopObserverRef //RunLoop里面内容 -- 观察者</code></pre>    <p style="text-align:center"><img src="https://simg.open-open.com/show/28b6c3b13e08212a1f2920f299640c8d.png"></p>    <p style="text-align:center">RunLoop_0.png</p>    <p>上面是RunLoop的结构图，可以看出，一个RunLoop里面可以有多个mode，每个mode又可以多个source，observer，timer。 可是每次RunLoop只能指定一个mode运行，如果想要切换mode，就必须先退出RunLoop，然后重新指定mode运行，这样做的目的就是避免mode之间相互影响</p>    <h3>CFRunLoopModeRef</h3>    <p>创建RunLoop时，系统默认注册了五种mode：</p>    <pre>  <code class="language-objectivec">1. kCFRunLoopDefaultMode: 默认 mode，通常主线程在这个 mode 下运行  2. UITrackingRunLoopMode: 追踪mode，保证Scrollview滑动顺畅不受其他 mode 影响  3. UIInitializationRunLoopMode: 启动程序后的过渡mode，启动完成后就不再使用  4: GSEventReceiveRunLoopMode: Graphic相关事件的mode，通常用不到  5: kCFRunLoopCommonModes: 占位用的mode，作为标记kCFRunLoopDefaultMode和UITrackingRunLoopMode用</code></pre>    <h3>当scroll滑动时，同页面上的定时器为什么会暂停？</h3>    <p>这个问题在这里就能得到解释了，当你用</p>    <pre>  <code class="language-objectivec">func scheduledTimer(withTimeInterval interval: TimeInterval, repeats: Bool, block: @escaping (Timer) -> Swift.Void) -> Timer</code></pre>    <p>创建一个timer时，系统默认把timer添加到kCFRunLoopDefaultMode模式中，但是当页面滚动的时候，RunLoop的Mode会自动切换成UITrackingRunLoopMode模式，因此timer失效，当停止滑动，RunLoop又会切换回NSDefaultRunLoopMode模式，因此timer又会重新启动了。</p>    <p>kCFRunLoopCommonModes的存在就是来解决这个问题的，RunLoop运行时，会把kCFRunLoopCommonModes中的资源下发到每一个NSDefaultRunLoopMode和UITrackingRunLoopMode中，所以加入到kCFRunLoopCommonModes中的timer不管在页面有没有滑动时都会运行。解决方法：</p>    <pre>  <code class="language-objectivec">let timer = Timer.init(timeInterval: 1, repeats: true) { }  RunLoop.main.add(timer, forMode: .commonModes)</code></pre>    <p>怎么在tableview滑动时延迟加载图片来提高流畅度？</p>    <p>这个问题也是同理，把加载图片放入NSDefaultRunLoopMode模式中就可以避免了：</p>    <pre>  <code class="language-objectivec">[self.imageView performSelector:@selector(setImage:) withObject:[UIImage imageNamed:@"abc"] afterDelay:2.0 inModes:@[NSDefaultRunLoopMode]];</code></pre>    <h3>CFRunLoopSourceRef</h3>    <p>事件产生的地方，分为 <strong>Source0</strong> 和 <strong>Source1</strong> 两种</p>    <ul>     <li><strong>Source0</strong> ： 只包含了一个回调（函数指针），它并不能主动触发事件。使用时，你需要先调用 CFRunLoopSourceSignal(source)，将这个 Source 标记为待处理，然后手动调用 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop，让其处理这个事件</li>     <li><strong>Source1</strong> ： 包含了一个 mach_port 和一个回调（函数指针），被用于通过内核和其他线程相互发送消息。这种 Source 能主动唤醒 RunLoop 的线程</li>    </ul>    <h3>CFRunLoopTimerRef</h3>    <p>基于时间的触发器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一个时间长度和一个回调（函数指针）。当其加入到 RunLoop 时，RunLoop会注册对应的时间点，当时间点到时，RunLoop会被唤醒以执行那个回调</p>    <p>CFRunLoopObserverRef</p>    <p>观察者，每个 Observer 都包含了一个回调（函数指针），当 RunLoop 的状态发生变化时，观察者就能通过回调接受到这个变化。可以观测的时间点有以下几个：</p>    <pre>  <code class="language-objectivec">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  };</code></pre>    <p>其中最重要就是，休眠与唤醒之间的切换，核心代码：</p>    <pre>  <code class="language-objectivec">/// 用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);  }</code></pre>    <p>具体流程表现为下图：</p>    <p><img src="https://simg.open-open.com/show/7aab9f00eb57aec05e3b18a3d2086374.png"></p>    <p style="text-align:center">RunLoop_1.png</p>    <p>看到有些人指出图中第七步中，Source0应该改为Source1，因为只有Source1能主动唤醒RunLoop，但是这里没有强调是主动唤醒，Source0也可以通过手动来唤醒。而且这里Source0后面有标注基于port， <strong>猜测</strong> 这种Source0可能是基于port 的Source1分发出来的。</p>    <p>RunLoop 的核心就是一个 mach_msg()，当一个RunLoop处理完事件后，即将进入休眠时，会经历下面几步：</p>    <p>1. 指定一个将来唤醒自己的mach_port端口</p>    <p>2. 调用mach_msg来监听这个端口，保持mach_msg_trap状态</p>    <p>3. 由另一个线程（比如有可能有一个专门处理键盘输入事件的loop在后台一直运行）向内核发送这个端口的msg后，mach_msg_trap状态被唤醒，RunLoop继续运行</p>    <p>mach相关方法涉及到内核，这里不做深入</p>    <h3>常说的AFNetworking常驻线程保活是什么原理？</h3>    <p>我们知道，当子线程中的任务执行完毕之后就被销毁了，那么如果我们需要开启一个子线程，在程序运行过程中永远都存在，那么我们就会面临一个问题，如何让子线程永远活着，答案就是给子线程开启一个RunLoop，下面是AFNetworking相关源码：</p>    <pre>  <code class="language-objectivec">+ (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;  }</code></pre>    <p>RunLoop 启动前内部必须要有至少一个 Timer/Source，所以 AFNetworking 在 [runLoop run] 之前先创建了一个新的 NSMachPort 添加进去了。通常情况下，调用者需要持有这个 NSMachPort (mach_port) 并在外部线程通过这个 port 发送消息到 loop 内；但此处添加 port 只是为了让 RunLoop 不至于退出，并没有用于实际的发送消息。</p>    <p>ps.RunLoop 启动前内部就算有一个observer也是会返回的。源代码：</p>    <pre>  <code class="language-objectivec">__CFRunLoopModeIsEmpty  {  if (NULL != rlm->_sources0 && 0 _sources0)) return false;  if (NULL != rlm->_sources1 && 0 _sources1)) return false;  if (NULL != rlm->_timers && 0 _timers)) return false;  }</code></pre>    <p>注意点</p>    <ul>     <li> <h3>AutoreleasePool</h3> <p>App启动后，苹果在主线程 RunLoop 里注册了两个 Observer：</p> <p>第一个 Observer 监视的事件是 Entry(即将进入Loop)，其回调内会调用 _objc_autoreleasePoolPush() 创建自动释放池。其 order 是-2147483647，优先级最高，保证创建释放池发生在其他所有回调之前。</p> <p>第二个 Observer 监视了两个事件： BeforeWaiting(准备进入休眠) 时调用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 释放旧的池并创建新池；Exit(即将退出Loop) 时调用 _objc_autoreleasePoolPop() 来释放自动释放池。这个 Observer 的 order 是 2147483647，优先级最低，保证其释放池子发生在其他所有回调之后。</p> <p>在主线程执行的代码，通常是写在诸如事件回调、Timer回调内的。这些回调会被 RunLoop 创建好的 AutoreleasePool 环绕着，所以不会出现内存泄漏，开发者也不必显示创建 Pool 了</p> </li>     <li> <h3>GCD</h3> <p>GCD与RunLoop是平级合作关系，GCD的timer跟RunLoop没关系，只是调用点在RunLoop上，需要注意的是，GCD中的dispatch到mainqueue的block被分发到RunLoop.main执行</p> </li>     <li> <h3>事件响应</h3> <p>当一个事件(触摸/锁屏/摇晃等)发生后，首先由 SpringBoard 接收，随后用 mach port 转发给需要的App进程，从而触发进程的Source1 （基于 mach port ，提前注册用来接收系统事件的Source）的回调_UIApplicationHandleEventQueue()，把事件包装成 UIEvent 进行处理或分发（之后的事件分发处理，可以看 <a href="/misc/goto?guid=4959738961744684958" rel="nofollow,noindex">从用户点击屏幕到程序作出反应之间都发生了什么？ --- iOS事件响应</a> ）。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的</p> <p>这里有一点值得注意，当我们点击一个按钮后，进行断点调试可以发现调用的函数栈里显示的是Source0:</p> </li>    </ul>    <p style="text-align:center"><img src="https://simg.open-open.com/show/65d824cd02ec6e0eccbe41d80f5c6267.png"></p>    <p style="text-align:center">btnClick.png</p>    <p>原因：首先是由那个Source1 接收事件，之后在回调内触发的 Source0，Source0 再触发的 _UIApplicationHandleEventQueue()进行事件分发和处理。所以UIButton事件看到是在 Source0 内的。</p>    <ul>     <li> <p>线程</p> <p>RunLoop的寄生于线程：一个线程只能有唯一对应的RunLoop，但这个根RunLoop里可以嵌套子RunLoop，主线程的RunLoop自动创建，子线程的RunLoop默认不创建，在子线程中调用NSRunLoop.current获取RunLoop对象的时候，就会创建RunLoop</p> </li>     <li> <p>界面刷新</p> <p>当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer 就被标记为待处理，并被提交到一个全局的容器去。苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件，回调去执行一个很长的函数：</p> <p>_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。</p> </li>    </ul>    <p>参考：</p>    <p><a href="/misc/goto?guid=4958875209744303120" rel="nofollow,noindex">深入理解RunLoop</a></p>    <p><a href="/misc/goto?guid=4958863644973252548" rel="nofollow,noindex">iOS线下分享《RunLoop》by 孙源@sunnyxx</a></p>    <p> </p>    <p>来自：http://www.jianshu.com/p/e51b1a2e49fc</p>    <p> </p>