页面卡顿是由哪些原因导致的?
1.死锁: 主线程拿到锁A, 需要获取锁B, 而同时子线程拿了锁B, 需要锁A, 这时主线程等待锁B的释放, 子线程等待锁A的释放, 相互等待.
2.抢锁: 主线程需要访问DB, 而这时某个子线程往DB插入数据. 通常抢锁的体验就是卡顿一阵子就恢复了.
3.主线程大量IO: 主线程为了方便直接写入大量数据, 导致页面卡顿.
4.主线程大量计算: 程序中的算法不合理, 大量循环等操作, 导致主线程某个函数占用大量CPU.
5.大量的UI绘制: 复杂的UI, 图文混排等, 带来大量的UI绘制.
卡顿问题怎么定位?
1.死锁一般会伴随Crash, 我们可以通过Crash日志进行分析.
2.抢锁的问题不太好办, 我们能将锁等待的时间打印出来, 但我们还需要知道是谁占用了锁, 可以检测Runloop的执行,观察耗时.
3.大量的IO可以在函数开始结束打点, 将函数占用时间打到日志中.
4.线程大量计算同理也可以将耗时记录到日志中.
5.大量UI绘制一般是难免的, APP中总会有复杂页面的绘制, 我们可以用AsnycDisplayKit等框架进行预排版,异步绘制,图片解码等.
如果我们能将上述问题发生时线程的堆栈信息捕捉下来, 那么就能快速定位到问题, 从而问题迎刃而解. 所以, iOS卡顿检查的思路就是创建一个子线程, 监控主线程Runloop的执行, 观察执行耗时是否超过预阈值, 如果有就立即记录线程堆栈.
如何获取所有线程的堆栈呢?
很有名的PLCrashReporter, 拿来主义就好!
这里也写了一个监测主线程RunLoop的demo
如何判断主线程是否发生了卡顿?
FPS降低
CPU占用率很高
主线程Runloop执行了很久
FPS能够兼容后面两个特征, 但在实际操作过程中发现FPS不好衡量抖动比较大. 对于抢锁或者大量IO的情况, 光靠CPU是不行的, 所以一般检测判断, CPU占用是否超过了100%, 主线程Runloop执行是够超过阈值.
具体原因和思路如上, 下面贴出微信内存监控解决方案:
关于卡顿检测, 世界上最好的免费APM平台Fabric却没有, 国内腾讯的bugly, 网易云捕等提供了类似的功能.
