在面试iOS应聘者的过程中，貌似流传着一个不成文的规矩，就是问：Runloop、Runtime、GCD这三个东西，便足以判断一个iOS开发者的水准。
Runloop对于大多数iOS新手来说，可能只是一个只有在面试中才能遇到的一个术语。但是其在iOS开发中其实有很多的应用。下面来总结一下我在实际开发遇到过的使用Runloop的场景。
1.NSTimer定时器的相关应用
具体应用包括轮播图，或者在tableview上存在NSTimer。
这个可能也是最常见的应用了吧。写一个定时器，但是它存在的问题就是有定时器存在时进行一些拖动滑动等UI交互操作，你会发现定时器停止了。
导致这个问题的原因是因为一般的定时器默认是NSDefaultRunLoopMode，进行UI操作时，会切换为UITrackingRunLoopMode，导致定时器暂停。
要解决也很简单，就是把定时器的Mode改为NSRunLoopCommonModes；其为一组run loop mode的集合，将输入源加入此模式意味着在Common Modes中包含的所有模式下都可以处理。
2.涉及一些优化处理需要用到
比如同时在tableView上显示数十个imageView，且image都是分辨率较高的图片时，此时拖动tableView肯定会造成卡顿。如何优化？
传统的优化方法包括异步加载图片、CoreGraphics绘制缩略图等等。这里还可以用RunLoop来进行优化处理。
之前之所以会卡顿的原因是因为image的绘制显示需要在主线程中操作，在主线程的RunLoop中同时处理加载数十张大分辨率的图片导致一次RunLoop还未执行完就进行滑动操作，给人的观感下造成了阻塞卡顿的感觉。而解决的思路便是：让每次RunLoop循环只加载一张图片。
具体的实现细节包括：通过注册CFRunloopObserver，观察RunLoop的各种状态如开始、结束等。然后在RunLoop开始后每次从数组tasks中只取出一个任务执行然后将该任务从数组中移除掉。
3.写一个监测iOS卡顿的工具
每一次Runloop完成的时间过长，给人造成卡顿的感觉，那么可以利用这个思路，对RunLoop的时间进行监测，那么就可以自己实现一个app卡顿监测的小工具，来优化自己的app。
具体的思路是：监测Runloop的kCFRunLoopAfterWaiting，用一个子线程不断去循环执行，每次RunLoop循环开始创建一个信号量dispatch_semaphore，然后在一次RunLoop执行完成后结束该信号量。记录每次信号量的开始和结束时间，也就是此次RunLoop循环用掉的时间。如果某次循环用时过长则打印出该循环中执行的方法，然后进行具体优化。
