iOS监控:卡顿方案思考

前言

最近因为工作原因迁移到了北京,大致有两周时间。入职也大概有一周时间,工作内容与APM相关,包括改进与攻克新监控方案。虽然入职时间善短,但是庞大的用户量下,即便是不到百分之一的卡顿率仍然影响到了巨大的用户。如何改进现有的卡顿监控方案是目前我在思考的问题。

ANR

回顾市面上大多数的开源监控方案,大多采用ANR这种机制下的做法去实现卡顿的监控,进而进行堆栈信息的追溯采集等。ANR这种方案最大的优点在于采集数据的准确率很高,基本可以说一旦发现主线程被block住了,那是一抓一个准的。但是同样也有着自己的缺陷,即ping的周期阈值的问题。

目前多数的做法是在子线程中周期性的ping主线程判断主线程是否被堵塞。如果不能在阈值内ping成功,说明主线程已经发生了卡顿

因此,此方案的问题在于这个ping周期应该是多长。本身在实现一套性能监控体系时,我们必须去衡量导入这个工具会带来怎样的损耗,因此这个周期不能太短。同样的,太长的周期也必然会漏掉可能发生的卡顿现象,而且这个概率不低。

平滑度

最近出现了一个称作平滑度的概念,通过应用使用前后的平滑对比来判断是否产生了卡顿问题。目前笔者没有看到相关的处置代码,但是并不妨碍笔者对这种方案的猜测。通过所谓的平滑度对比应该是通过FPS查看应用运行过程中的帧数变化。我们都知道通常情况下,屏幕会保持60帧/秒的刷新频率,如果在某一帧发生了大量计算导致跳帧,也可以称作掉帧现象,具体表现就是我们感受到的卡顿。

这种卡顿采用ANR其实是很难检测到的,这是视觉上的卡顿而非Not Response。因此除了CADisplayLink和人工测试之外,还是相当难的去捕获到这种卡顿。

所以,一种改进的方案是放弃现有的纯ANR方式的卡顿监控方案,结合CADisplayLink来实现另一种方式的监控。大致为主线程监听屏幕刷新信号,子线程循环获取FPS,并判断是否发生下滑现象。如果发生下滑,此时再尝试去ping主线程判断是否被block住。相比起纯ANR方案,这种方式的ping目的性更强,但是由于监控FPS的变化也是有时间的消耗的。这意味着短时的主线程block可能在ping出去没多久时就已经恢复,实际发生的卡顿却没有被监控到,也算是这种方案的缺陷了。

最后

上面的方案属于个人猜测的方案,具体效果如何还需要去实践得真知。对于卡顿监控来说,有两个相当重要的指标。准确率捕获率,这两者在一定意义上是互相矛盾的,我们所做的工作无非是尽量在两者之间权衡比较,得出当下最有利的方案。不过如果非要二选一的话,个人还是选择准确率。毕竟只要有足够的时间和样本采集,捕获率即便低了一些也总归有机会采集的到。

参阅

页面间跳转的性能优化(一)
页面间跳转的性能优化(二)

1 1 收藏 评论

关于作者:林欣达

iOS码农一枚 个人主页 · 我的文章 · 1 ·     

可能感兴趣的话题



直接登录
跳到底部
返回顶部