APP卡顿原因

目录介绍

• 01.Android卡顿原理

• 02.复杂的视图树

• 03.频繁的requestlayout()

• 04.UI线程被阻塞

• 05.内存抖动

 

01.Android卡顿原理

• 通过对Android绘制机制的了解，我们知道造成应用卡顿的根源就在于16ms内不能完成绘制渲染合成过程，因为Android平台的硬件刷新率为60HZ，大概就是16ms刷新一次。如果没能在16ms内完成这个过程，就会使屏幕重复显示上一帧的内容，即造成了卡顿。在这16ms内，需要完成视图树的所有测量、布局、绘制渲染及合成。而我们的优化工作主要就是针对这个过程的。

 

02.复杂的视图树

• 如果视图树复杂，会使整个Traversal过程变长。因此，我们在开发过程中要控制视图树的复杂程度。减少不必要的层级嵌套。比如使用RelativeLayout可以减少复杂布局的嵌套。

 

03.频繁的requestlayout()

• 如果频繁的触发requestLayout()，就可能会导致在一帧的周期内，频繁的发生布局计算，这也会导致整个Traversal过程变长。有的ViewGroup类型的控件，比如RelativeLayout，在一帧的周期内会通过两次layout()操作来计算确认子View的位置，这种少量的操作并不会引起能够被注意到的性能问题。但是如果在一帧的周期内频繁的发生layout()计算，就会导致严重的性能，每次计算都是要消耗时间的！而requestLayout()操作，会向ViewRootImpl中一个名为mLayoutRequesters的List集合里添加需要重新Layout的View，这些View将在下一帧中全部重新layout()一遍。通常在一个控件加载之后，如果没什么变化的话，它不会在每次的刷新中都重新layout()一次，因为这是一个费时的计算过程。所以，如果每一帧都有许多View需要进行layout()操作，可想而知你的界面将会卡到爆！卡到爆！需要注意，setLayoutParams()最终也会调用requestLayout()，所以也不能烂用！

 

04.UI线程被阻塞

• 如果UI线程受到阻塞，显而易见的是，我们的Traversal过程也将受阻塞！画面卡顿是妥妥的发生啊。这就是为什么大家一直在强调不要在UI线程做耗时操作的原因。通常UI线程的阻塞和以下原因脱不了关系。

  • 在UI线程中进行IO读写数据的操作。这是一个很费时的过程好吗？千万别这么干。如果不想获得一个卡到爆的App的话，把IO操作统统放到子线程中去。

  • 在UI线程中进行复杂的运算操作。运算本身是一个耗时的操作，当然简单的运算几乎瞬间完成，所以不会让你感受到它在耗时。但是对于十分复杂的运算，对时间的消耗是十分辣眼睛的！如果不想获得一个卡到爆的App的话，把复杂的运算操作放到子线程中去。

  • 在UI线程中进行复杂的数据处理。我说的是比如数据的加密、解密、编码等等。这些操作都需要进行复杂运算，特别是在数据比较复杂的时候。如果不想获得一个卡到爆的App的话，把复杂数据的处理工作放到子线程中去。

  • 频繁的发生GC，导致UI线程被频繁中断。在Java中，发生GC(垃圾回收)意味着Stop-The-World，就是说其它线程全部会被暂停啊。好可怕！正常的GC导致偶然的画面卡顿是可以接受的，但是频繁发生就让人很蛋疼了！频繁GC的罪魁祸首是内存抖动。简单的说就是在短时间内频繁的创建大量对象，导致达到GC的阀值，然后GC就发生了。如果不想获得一个卡到爆的App的话，把内存的管理做好，即使这是Java。

 

05.内存抖动

• 什么是内存抖动？

  • 是由于短时间内有大量对象进出Young Generiation区导致的，它伴随着频繁的GC。在Java内存管理机制中我提到过内存抖动会引起频繁的GC，从而使UI线程被频繁阻塞，导致画面卡顿。

• 避免发生内存抖动的几点建议：

  • 尽量避免在循环体内创建对象，应该把对象创建移到循环体外。

  • 注意自定义View的onDraw()方法会被频繁调用，所以在这里面不应该频繁的创建对象。

  • 当需要大量使用Bitmap的时候，试着把它们缓存在数组中实现复用。

  • 对于能够复用的对象，同理可以使用对象池将它们缓存起来。

• 内存抖动是由于大量对象在短时间内被配置而引起的，所以要做的就是谨慎对待那些可能会大量创建对象的情况。

  • 这块可以看我的这个开源项目，有效使用对象池避免对象大量创建。