背景:
《Google的性能优化典范》一文是Android程序内存优化的指导,分别从渲染、电量、运算和内存几个方面阐述了优化方向。
本文关注渲染方向:
渲染其实是指GPU渲染,是App计算--绘制--渲染 过程中的最后一步。CPU负责Measure Layout,Execute GPU负责Rasterization(栅格化)。
CPU通常存在的问题是 非必需的视图组件、视图层级;GPU的问题是过度绘制。
Overdraw 过度绘制:
定义:屏幕上的某个像素在同一帧的时间内被绘制了多次
例如UI是层叠的,看不见的UI也做绘制操作,就是多余的。当设计效果上更加华丽炫酷时,堆叠视图层级是常见的情况,但这很容易产生性能问题。
怎么过度绘制打开开关和如何看,不介绍了就。
解决方案:
1.写合理而高效的布局
Android的布局可以通过xml来实现,这使得开发者布局时较为随意,只以实现功能为目的,忽略性能问题的累积效应。
在开发设计之初,就应该考虑布局的效率问题,以免出现后期修改的高成本。
降低Layout层级,有很多方法 不列举了。
2.移除非必须的background: Activity的DecorView有默认的背景色,可以改为透明
getWindow().getDecorView().setBackgroundColor(getResources().getColor(R.color.transparent));
这个颜色从ActivityTheme设置,被decorView所持有
<style name="Theme">
...
<!-- Window attributes -->
<item name="windowBackground">@drawable/screen_background_selector_dark</item>
...
</style>
screen_background_selector_dark在sdk中定义为纯黑色
所以也可以android:windowbackground="null"
方法来修改
后续会在Theme自定义,或BaseActivity 统一优化
3.View BackGround 优化:
- 所有的View都可以设置Background,ImageView除了可以设置BackGround外,还可以设置imageResource
在使用ImageView时,尤其是ListView ViewHolder中,可能imageView设置默认bitmap给background,然后
真正的bitmap给imageResource,导致了重复绘制。解决方法是都通过imageResource设置 - 有时采用selector背景,可以normal状态设置为transparent
4.移除不必要的背景色
比如Activity中含Fragment,如果Fragment有背景色而且是全屏的,Activity就不必要。
又比如ViewPager中含fragment ViewPager的背景色是不必要的
5.ClipRect
在ViewGroup的drawChild方法中,
protected boolean drawChild(Canvas canvas, View child, long drawingTime)
在ViewGroup的Canvas上绘制子child,不同的child都在同一个canvas绘制,如果view相互遮盖,则重复绘制难免。
Canvas的clipRect方法,提供了限定绘制区域的功能,在某个child 绘制时,可以限定绘制区域为自己的显示区域,解决了这个问题。
v4包中的DrawerLayout,就专门做了ClipRect优化
@Override
protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
final int height = getHeight();
final boolean drawingContent = isContentView(child);//是否mainContent
int clipLeft = 0, clipRight = getWidth();
//如果是绘制mainContent,则先canvas.save 再 canvas.restore
//并拿到drawerContent的right作为自己绘制的left,通过canvas.clipRect限定绘制区域
final int restoreCount = canvas.save();
if (drawingContent) {
final int childCount = getChildCount();
//此for循环找到drawerCotnent,
for (int i = 0; i < childCount; i++) {
final View v = getChildAt(i);
//注意此处对于drawerContent的筛选条件:
//visible,背景非透明!hasOpaqueBackground(v)
//如果drawerContent无背景色,此优化直接continue,因为mainContent要全显示
if (v == child || v.getVisibility() != VISIBLE ||
!hasOpaqueBackground(v) || !isDrawerView(v) ||
v.getHeight() < height) {
continue;
}
if (checkDrawerViewAbsoluteGravity(v, Gravity.LEFT)) {
final int vright = v.getRight();
if (vright > clipLeft) clipLeft = vright;
} else {
final int vleft = v.getLeft();
if (vleft < clipRight) clipRight = vleft;
}
}
canvas.clipRect(clipLeft, 0, clipRight, getHeight());
}
final boolean result = super.drawChild(canvas, child, drawingTime);
canvas.restoreToCount(restoreCount);
pilot端的问题就在于DrawerContent没有背景,而是把背景设置在了里面的Fragment,导致DrawerLayout优化没有生效
此优化一般用于自定义view中,而且控件交互存在View之间重叠的情况
Android中每个Window对应一个Canvas,window下所有view绘制公用一个canvas,viewtree的父节点在调用child.draw之前都会根据child的layout边界对canvas进行裁剪,这也是为什么超过view边界的内容不会被显示的原因。
但是对于各child大部分重叠的控件,会产生过度绘制,就需要clipRect优化。大部分容易重叠的控件FrameLayout RelativeLayout本身没有优化,需要开发者根据实际情况对自定义控件进行优化。
优化前:[图片上传失败...(image-5fc76c-1513077609721)]
优化后:[图片上传失败...(image-87aa6e-1513077609721)]
6.善用9patch,背景图如果只显示边框,选用9patch,中间的透明会被2D渲染器优化overdraw
过度绘制的原因无外乎:复杂的Layout层级、重叠的背景、重叠的View几种。开发人员在设计之初就要充分考虑过度绘制等性能敏感地带,要知道等到功能实现之后再去改Layout层级,onDraw方法等,成本和风险都会指数型提高。