用户之所以会感到卡顿,可能是APP在运行时出现了丢帧的现象,为保证应用的流畅度,每一帧的渲染时间不得超过16ms,如果UI渲染过慢,就会出现掉帧的情况,渲染过慢就会出现卡顿。然而界面的性能主要是依赖于设备的UI渲染性能,如果UI线程被阻塞也会导致APP卡顿。就这篇文章读懂u-apm工具中卡顿分析带来的帮助!

  一、卡顿16ms原则

  android每16ms会对界面进行一次渲染,如果app的绘制、计算等超过了16ms那么只能等下一个16ms才能进行渲染,这就发生了丢帧现象。丢帧现象的发生就会导致app卡顿.

  二、卡顿表现

  1. 速度曲线。

  当你滑动界面然后松手,这时界面会继续滑动,然后速度减小,直到速度为0时停止。

  2. 帧率。

  绝大部分时间两者都能保持60FPS左右的满帧率。但都会有偶尔的掉帧。并且Android上 要比iOS上严重很多。UI线程受到阻塞,显而易见的是,我们的Traversal过程也将受阻塞!画面卡顿是妥妥的发生啊。触摸响应速度。

  3. 触摸响应速度。

  从手指碰到触摸屏,到屏幕上显示处理这次触摸产生的画面,是需要时间的。时间越短感觉 越跟手。Android的显示机制是app-->SurfaceFlinger-->Display,这比传统的app-->Display多了一步,主要基于这个原因,画面最终输出到屏幕要比传统的方式慢一帧(16.7ms)

  三、卡顿原因

  1、布局过于复杂:xml布局文件可能存在深层嵌套或者组件过多。

  2、重复绘制:一个界面的某一点可能在同一时间进行了多次绘制。

  3、内存抖动:系统内存是有限的,系统经常会将不活跃的进程置入外存中就是常说的虚拟内存,当调用它时再把它从外存转入内存,内存外存转换频率过大就会导致内存抖动。

  4、性能瓶颈: 任务过多且执行调度不够好。

  5、历史问原因,老代码以及设计问题。

  6、团队人众多员 ,存在过多的代码合并和插入问题。

  7、个别程序员的渣代码。

  四、卡顿解决方案

  1,减低布局的复杂度。

  2,单线程任务不要太多。

  3,适当调度。

  4,将一些计算分担给服务器端。

  五、U-APM卡顿监测分析

  卡顿分析模块对卡顿的定义为:SDK监控到主线程消息执行超时的次数。

  Android:2秒无响应定义为卡顿。

  iOS:连续3个2秒无响应定义为卡顿。

  卡顿分析中详尽展示:卡顿趋势、卡顿列表、卡顿模块、卡顿分布其中:

  1、卡顿趋势表现出APP总卡顿次数、综合卡顿率、卡顿用户数、卡顿用户占比。

  2、卡顿列表中展示卡顿摘要、最近一次时间、错误类型、版本范围、卡顿次数、卡顿用户数、错误ID、处理状态、告警设置这些详尽信息。

  3、卡顿模块展示聚合内容。

  4、卡顿分布中设备分布、系统分布、运营商分布、版本分布 、渠道分布、地域分布这些详尽靠谱信息。