Overdraw（过度绘制）：描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次的UI结构里面，如果不可见的UI也在做绘制的操作，就会导致某些像素区域被绘制了多次，浪费大量的CPU以及GPU资源，因为底下被覆盖区域怎么重绘也没有意义。当view内容发生改变时，整个view都会重绘，如果层次太“丰富”，那性能就会严重下降。
过渡绘制层次：
无色： 意味着没有overdraw。像素只画了一次。
蓝色： 意味着overdraw 1倍。像素绘制了两次。大片的蓝色还是可以接受的（若整个窗口是蓝色的，可以摆脱一层）。
绿色： 意味着overdraw 2倍。像素绘制了三次。中等大小的绿色区域是可以接受的但你应该尝试优化、减少它们。
浅红： 意味着overdraw 3倍。像素绘制了四次，小范围可以接受。
暗红： 意味着overdraw 4倍。像素绘制了五次或者更多。这是错误的，要修复它们。
界面绘制层次颜色图：
合理选择容器
LinearLayout易用，效率高，表达能力有限。RelativeLayout复杂，表达能力强，效率稍逊，但是relativeLayout可以减少布局层级，用一层写出复杂的嵌套
Viewstub 高效占位符
我们经常会遇到这样的情况，运行时动态根据条件来决定显示哪个View或布局。常用的做法是把View都写在上面，先把它们的可见性都设为View.GONE，然后在代码中动态的更改它的可见性。这样的做法的优点是逻辑简单而且控制起来比较灵活。但是它的缺点就是，耗费资源。虽然把View的初始可见View.GONE但是在Inflate布局的时候View仍然会被Inflate，也就是说仍然会创建对象，会被实例化，会被设置属性。也就是说，会耗费内存等资源。
ViewStub是一个轻量级的View，它一个看不见的，默认不占布局位置，在Inflate布局的时候，只有ViewStub会被初始化。在要显示的时候调用 ((ViewStub)findViewById(R.id.stub_view)).setVisibility(View.VISIBLE);让其可见，ViewStub内部的布局就会被Inflate和实例化。
Merge
当布局根布局没有实际属性仅仅起的是一个简单的父viewgroup时，可以用merge来代替，merge不会作为一个层级进行绘制。
业务逻辑简化
在设计业务逻辑时，尽量不要过度设计。华丽的App界面毕竟会牺牲绘制性能。在功能完成的前提下，尽量设计层级简单操作简单。
网友评论