下载安卓APP箭头
箭头给我发消息

客服QQ:3315713922
论坛 >移动开发 >iOS监控:卡顿方案思考

iOS监控:卡顿方案思考

Abby发布于 2017-08-09 09:48查看:835回复:1

        ANR

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

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

1502243253153900.jpeg

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

1502243278945613.jpeg

       平滑度

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

1502243314790596.jpeg

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

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

        最后

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

收藏(0)0
查看评分情况

全部评分

此主贴暂时没有点赞评分

总计:0

回复分享

共有1条评论

  • MK
  • 药师
  • 慧星的那一夜
  • Mr ken
  • YUI
  • cappuccino
  • mr jack
  • IT宅男
  • 课课家技术团队1
  • 选择版块:

  • 标题:

  • 内容

  • 验证码:

  • 标题:

  • 内容

  • 选择版块:

移动帖子x

移动到: