前言
相信大家对Runloop都或多或少有过一定的了解，就算没有使用过Runloop但也应该听说，尤其对于iOS开发。这篇文章并不会详细讲解Runloop的内部实现与工作原理，主要以iOS开发的角度介绍Runloop的使用实践。
什么是Runloop
Runloop简单来说就是一个消息循环，如同do{}While，主用用于资源的合理分配，有消息时唤起Runloop处理消息、没有消息时进入休眠、合适时机切换循环的mode，避免消息堆积。网上介绍Runloop的文章很多也很详细，并且苹果已经开源了CoreFoundation源代码以及Runloop官方文档，这里也不展开介绍了。
实践
1.卡顿监控
卡顿在用户的感知是页面掉帧、无法操作、操作响应不及时，在研发的角度来看就是主线程正在执行耗时代码，导致页面渲染频率跟不上CPU刷新频率或主线程无法及时响应用户交互事件。
- 通用解决方案
使用CADisplayLink计算FPS，通过FPS监控卡顿情况，但是这种方案局限较大，无法精确定位导致卡顿的问题代码。 - 卡顿的根本原因位
用户交互事件的响应与页面渲染帧的计算在每个消息循环内都能处理，故如果单个消息循环耗时不长，就不会导致卡顿的产生 - Runloop方案
在子线程通过CFRunLoopObserver监听主线程Runloop的CFRunLoopActivity状态，根据kCFRunLoopBeforeSources与kCFRunLoopAfterWaiting两个状态确定每个消息循环耗时情况，根据合理的阀值找出有问题的消息循环，并通过当时的函数调用堆栈即可获取问题代码，可用于统计卡顿的量与问题分析。
2.预加载分发
性能优化过程中少不了预加载、预计算等手段，这些手段确实能给某些指标带来可观的收益，但是预加载的时机也是个需要考虑的问题，如果时机没选好或者多个预加载堆积可能会更影响体验。
- 案例
如TableView的性能优化的过程中，我们会预计算为展示cell的布局或cell高度，以保证滑动的流程性。常规做法是在TableView滑停的时候进行预计算，但一般用户滑停后大概率会进行点击等操作，而预计算可能导致用户无法及时交互。 - 空闲分发
建立一个预加载分发队列，同时监听主线程Runloop的kCFRunLoopBeforeWaiting状态，每监听到一次变为BeforeWaiting的时机，就将一个预加载任务通过performSelector:onThread:withObject:waitUntilDone:modes:以source0的方式抛给主线程Runloop处理。同时队列可提供任务的优先级排序与任务的撤销，便于使用方的资源合理分配与预加载回收。
3.容灾保活
App出现Crash发生异常奔溃是在所难免的事，虽然我们可以通过加保护、消息转发等手段做到一定程度的容灾，但还是无法预测所有的异常发生，在异常发生后希望给用户一定的提示或者短暂的操作时间，进行数据的保持等行为。
- 异常捕获
系统提供了NSSetUncaughtExceptionHandler()与signal()用于捕获native与signal的异常处理，但受限于只有当前ExceptionHandler所在Runloop的执行时间，期间无法给用户提供操作时间。 - 保活
在ExceptionHandler执行过程中可通过CFRunLoopRun()或CFRunLoopRunInMode()重启主线程Runloop，临时挂起ExceptionHandler的上下文。期间提示用户且用户可正常操作，待操作完成后以CFRunLoopStop()关闭ExceptionHandler中新起的消息循环并还原ExceptionHandler的上下文，完成异常处理的完整流程。 - 风险
-
ExceptionHandler的执行时间是否受Watch Dog的监控未知，暂未查到资料。 - 异常已经触发，临时保活也可能是不完整功能。
- 保活后系统主线程调用堆栈都是从
ExceptionHandler开始的，即堆栈中ExceptionHandler变成正常情况下main函数的位置。
-
小结
以上几种Runloop的落地方案均只提及思想，未提供具体实现细节，主要是因各个场景下有各自的诉求，即实现细节各有千秋。卡顿监控与预加载分发方案落地没有什么异议，至于容灾保活是否可落地可酌情选择。再者大家有其他更好的Runloop落地方案也欢迎留言补充。
