一、卡顿问题的几种原因
复杂 UI 、图文混排的绘制量过大；
在主线程上做网络同步请求；
在主线程做大量的 IO 操作；
运算量过大，CPU 持续高占用；
死锁和主子线程抢锁。
二、监测卡顿的思路
监测FPS：
FPS 是一秒显示的帧数，也就是一秒内画面变化数量。如果按照动画片来说，动画片的 FPS 就是 24，是达不到 60 满帧的。也就是说，对于动画片来说，24 帧时虽然没有 60 帧时流畅，但也已经是连贯的了，所以并不能说 24 帧时就算是卡住了。 由此可见，简单地通过监视 FPS 是很难确定是否会出现卡顿问题了，所以我就果断弃了通过监视 FPS 来监控卡顿的方案。
RunLoop：
通过监控 RunLoop 的状态来判断是否会出现卡顿。RunLoop原理这里就不再多说，主要说方法，首先明确loop的状态有六个
我们需要监测的状态有两个：RunLoop 在进入睡眠之前和唤醒后的两个 loop 状态定义的值，分别是 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting ，也就是要触发 Source0 回调和接收 mach_port 消息两个状态。
三、如何检查卡顿
说下步骤：
创建一个 CFRunLoopObserverContext 观察者；
将创建好的观察者 runLoopObserver 添加到主线程 RunLoop 的 common 模式下观察；
创建一个持续的子线程专门用来监控主线程的 RunLoop 状态；
一旦发现进入睡眠前的 kCFRunLoopBeforeSources 状态，或者唤醒后的状态 kCFRunLoopAfterWaiting，在设置的时间阈值内一直没有变化，即可判定为卡顿；
dump 出堆栈的信息，从而进一步分析出具体是哪个方法的执行时间过长
