从事android开发有一段时间了，但是对于它的底层原理一直感到很陌生，前几天听同事问到，为什么app显示有时候很卡，对于这个问题我一般都会从内存占用过多方面去思考，但是为什么内存占用过多会卡顿呢，没办法了，在这个时候你如果不懂android的图像显示的底层原理那么这个问题你是根本答不了的。先来看一张图。
首先我们需要了解上面那张图里几个名词对象的作用，CPU它的作用是计算图片的形状和文字的纹体，GPU它的功能是渲染图像的颜色，Display屏幕显示图像，VSync网上好多将它翻译成“垂直同步”，然而它的意思却是显卡输出频率与屏幕刷新平率同步的意思，我的理解是其实它就是一个固定的时间节点，它的作用是只有在这个时间节点才能开始做某些事情，过了这个节点，你就得等下一个节点才能开始做了。就像坐地铁一样，这班地铁错过了那你只能等下班地铁了。
了解了他们的作用现在需要知道它们是怎么样协同工作了，首先是CPU计算出图像形状，计算完成CPU会将图像交给GPU渲染出颜色，如果这一切都能够在16ms内完成，那么在下一个VSync出现时，就能显示刚刚渲染出来的那1帧图像了，但是如果CPU和GPU处理1帧图像时间超过16ms，那么这帧图像只能等到第2个VSync出现时才能刷出屏幕，呈现给用户了，这也就意味着用户在32ms内所看到的是同1帧的图像，这就是所谓的掉帧，也就是卡顿了。
从代码层面上来看，到底是哪些因素使得CPU,GPU处理图像时间过长呢？
1. 过度重绘，有时候是因为你的UI布局存在大量重叠的部分，还有的时候是因为非必须的重叠背景。例如某个Activity有一个背景，然后里面的Layout又有自己的背景，同时子View又分别有自己的背景。仅仅是通过移除非必须的背景图片，这就能够减少大量的红色Overdraw区域。
2. 动画使用次数过多。
通常情况下Android需要将xml布局文件转换成GPU可以识别的绘制对象，而这些绘制对象被存放到DisplayList的数组中，当view第一次绘制的时候DisplayList被创建，view第二次绘制的时候GPU就直接从DisplayList获取绘制对象，省去了Measure,Layout的时间，但是如果我们改变了view的绘制内容那么得重新Measure,layout，DisplayList也会被重新创建，这么看来动画效果是非常消耗性能的。因为它必须经过多次重绘。
3. 短时间内创建的对象过多
android的垃圾回收机制是，当heap被占用的空间达到一个阈值，GC就开始回收对象了，GC工作的时候大部分线程是阻塞的，所以如果GC耗时超过16ms那么也会出现失帧卡顿的现象。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，
转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/qq_34168374/article/details/54407976
