iOS 性能优化 — 二、卡顿监控及处理
上篇文章为大家讲解了crash监控及防崩溃处理,这片文章继续为大家讲解下卡顿监控及处理。
卡顿产生原理
如何收集卡顿
* 利用bugly、听云等第三方收集
* 自己收集卡顿
* 监控主线程RunLoop
* 子线程ping
卡顿产生原理
FPS (Frames Per Second) 表示每秒渲染帧数,通常用于衡量画面的流畅度,每秒帧数越多,则表示画面越流畅。通常60是临界值,如果主线层FPS低于60fps,应用程序就可能产生卡顿。大家可以看这篇文章详细了解卡顿产生原理。
如何收集卡顿
利用bugly、听云等第三方收集
国内有很多第三方网站可以用来收集卡顿,常用的有bugly、听云等。笔者推荐大家用腾讯的bugly来收集卡顿。
自己收集卡顿
如果我们要自己手动监控卡顿,其实有好几种方案,如下:
监控主线程RunLoop
我们知道iOS App基于RunLoop运行,我们先来看看RunLoop简化后的代码。
我们可以看到RunLoop调用方法主要集中在kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting之间。我们可以开辟一个子线程来监控主线程RunLoop,然后实时计算 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 两个状态区域之间的耗时是否超过某个阀值,来断定主线程的卡顿情况,比如如果连续5次超时50ms,则认为发生了卡顿。代码如下:
子线程ping
创建一个子线程通过信号量去ping主线程,每次检测时设置标记位为YES,然后派发任务到主线程中将标记位设置为NO。接着子线程沉睡超时阙值时长,判断标志位是否成功设置成NO,如果没有说明主线程发生了卡顿。
资料推荐
如果你正在跳槽或者正准备跳槽不妨动动小手,添加一下咱们的交流群1012951431来获取一份详细的大厂面试资料为你的跳槽多添一份保障。
评论