Android 布局渲染流程与原理
首先，咱们要知道Android系统每隔16ms就从新绘制一次Activity，也就是说，咱们的应用必须在16ms内完成屏幕刷新的所有逻辑操做，这样才能达到每秒60帧，然而这个每秒帧数的参数由手机硬件所决定，如今大多数手机屏幕刷新率是60赫兹（赫兹是国际单位制中频率的单位，它是每秒中的周期性变更重复次数的计量），也就是说咱们有16ms（1000ms/60次=16.66ms）的时间去完成每帧的绘制逻辑操做，若是错过了，好比说咱们花费34ms才完成计算，那么就会出现咱们称之为丢帧的状况。缓存
CPU负责计算数据，把计算好数据交给GPU 负责Measure，Layout,Record，Execute等计算操做优化
GPU会对图形数据进行渲染， 负责Rasterization(栅格化)操做动画
Android VSYNC原理http://shangjin615.iteye.com/blog/1775684设计
Step1. Display显示第0帧数据，此时CPU和GPU渲染第1帧画面，并且赶在Display显示下一帧前完成blog
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卡顿的时候
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标签详解https://blog.csdn.net/u012792686/article/details/72901531
Lint建议
咱们看到优化布局是一项很是繁琐复杂的工做，因此咱们平时在开发中必定要注意。
出了使用hv和li两种工具以外，咱们还可使用Lint检查，让Lint给出存在问题的地方来修改(activity_main4)。
而后弹出框
选择Lint检查的范围
按照Lint的提示修改布局便可。