首先，我们要知道Android系统每隔16ms就重新绘制一次Activity，也就是说，我们的应用必须在16ms内完成屏幕刷新的全部逻辑操作，这样才能达到每秒60帧，然而这个每秒帧数的参数由手机硬件所决定，现在大多数手机屏幕刷新率是60赫兹（赫兹是国际单位制中频率的单位，它是每秒中的周期性变动重复次数的计量），也就是说我们有16ms（1000ms/60次=16.66ms）的时间去完成每帧的绘制逻辑操作，如果错过了，比如说我们花费34ms才完成计算，那么就会出现我们称之为丢帧的情况。
在一个典型的显示系统中，
CPU、GPU、显示器三个部分，
CPU负责计算数据，把计算好数据交给GPU 负责Measure，Layout,Record，Execute等计算操作
GPU会对图形数据进行渲染， 负责Rasterization(栅格化)操作
然后显示器 负责把buffer里的数据呈现到屏幕上
SouthEast
Android VSYNC原理http://shangjin615.iteye.com/blog/1775684
以时间的顺序来看下将会发生的异常：
Step1. Display显示第0帧数据，此时CPU和GPU渲染第1帧画面，而且赶在Display显示下一帧前完成
Step2. 因为渲染及时，Display在第0帧显示完成后，也就是第1个VSync后，正常显示第1帧
Step3. 由于某些原因，比如CPU资源被占用，系统没有及时地开始处理第2帧，直到第2个VSync快来前才开始处理
Step4. 第2个VSync来时，由于第2帧数据还没有准备就绪，显示的还是第1帧。这种情况被Android开发组命名为“Jank”。
Step5. 当第2帧数据准备完成后，它并不会马上被显示，而是要等待下一个VSync。
所以总的来说，就是屏幕平白无故地多显示了一次第1帧。原因大家应该都看到了，就是CPU没有及时地开始着手处理第2帧的渲染工作，以致“延误军机”。
从上图可以看到，CPU和GPU的处理时间因为各种原因都大于一个VSync的间隔（16.6ms），所以在第二个VSync还在处理1区域的绘制时， 试想用户盯着同一张图看了32ms而不是16ms，当然很容易察觉出卡顿感，哪怕仅仅出现一次掉帧，用户都会发现动画不是很顺畅，大家在察觉到APP卡顿的时候
Android GPU 设计的缓冲机制
button转换成特定的向量图形是一个时间消耗过程，再由向量图形传递给GPU又是一个时间消耗过程，而由CPU传递给GPU同样是一个非常耗时的过程。这样就意味着，GPU中进行栅格化所节省下来的时间，可能在这里被消耗大半。
幸运的是Open GL考虑到了这一点，它提供了一个类似缓存到机制：CPU上传到GPU中的资源，可以作为缓冲保存在GPU当中，在下次再次利用的过程中，就省去了CPU的格式转换和CPU上传到GPU的过程消耗。
Android系统就灵活利用到了这一点，它在系统启动过程中，就将主题中的系统资源以一个单一向量图形的形式上传至GPU，以后在调用系统资源时，就可以直接在GPU中取到相应资源，而不需要转换和传递。这就是加载Android系统图片为啥这么快的原因。
然而，有了这个机制就可以万事大吉了？并不，随着UI画的图越来越诡异，产品设计的动画越来越彪悍，GPU的缓冲机制变得几乎形同虚设，因为每一个图片都是不同的，都无法服用，因此GPU中的缓存资源只能通过不断被覆盖来达到相应效果，
Android系统提供了差异化绘制机制，简单来说就是缓存的旧资源与即将写入的新资源进行对比，只对发生了改变的部分进行重新处理。以此缓解GPU的压力。
在上面，我们有提到，有DisplayList对CPU处理好的格式资源以及需要进行的相应的绘制指令，进行接收。这里的DispalyList在特殊情况下，可以对其接收的信息进行复用，举例来说：
如果一个button改变了其位置：GPU可以将DisplayList中的信息可以进行复用。
如果一个button改变了其大小或者其形状，表面颜色发生改变（视觉上的形体，色彩改变 ）：GPU就无法使用之前CPU传递来的DisplayList，需要通过CPU进行重新格式转换，然后将命令和转换好的资源存入一个新的DisplayList当中。
布局优化神器 include 、merge、ViewStub标签详解
Lint建议
我们看到优化布局是一项非常繁琐复杂的工作，所以我们平时在开发中一定要注意。
出了使用hv和li两种工具之外，我们还可以使用Lint检查，让Lint给出存在问题的地方来修改(activity_main4)。
然后弹出框
选择Lint检查的范围
按照Lint的提示修改布局即可。
