资讯专栏INFORMATION COLUMN

Android 性能优化之减少UI过度绘制

番茄西红柿 / 1229人阅读

摘要:过度绘制最直观的影响就是会导致卡顿。红色次过度绘制这部分的像素点只在屏幕上绘制了五次。我们的目标是要控制界面最多被过度绘制次不出现粉色和红色。但是要根据实际情况来做一个取舍,在保证性能的同时尽量避免。

什么是过度绘制(OverDraw)

在多层次重叠的UI结构里面,如果不可见的UI也在做绘制的操作,会导致某些像素区域被绘制了多次。这样就会浪费大量的CPU以及GPU资源。过度绘制最直观的影响就是会导致APP卡顿。还好系统有提供GPU过度绘制调试工具会在屏幕上用不同的颜色,来表明一个像素点位被重复绘制的次数。

怎样开启GPU过度绘制调试工具?

1.点击进入“设置”;
2.点击进入“开发者选项”
3.选中“调试GPU过度绘制”
4.选中“显示过度绘制区域”

此时,你会注意到屏幕的颜色变化了,别紧张。切换到你的应用,现在我们开始了解怎么通过改善布局来解决过度绘制问题。

屏幕上不同的颜色代表着什么?

1.原色没有被过度绘制 – 这部分的像素点只在屏幕上绘制了一次。
2.蓝色1次过度绘制– 这部分的像素点只在屏幕上绘制了两次。
3.绿色2次过度绘制 – 这部分的像素点只在屏幕上绘制了三次。
4.粉色3次过度绘制 – 这部分的像素点只在屏幕上绘制了四次。
5.红色4次过度绘制 – 这部分的像素点只在屏幕上绘制了五次。

怎么解决应用过度绘制?

由上面的知识,我们知道要解决过度绘制。即是要尽量减少屏幕上的红色区域,增加屏幕上的蓝色和绿色区域。我们的目标是要控制界面最多被过度绘制2次(不出现粉色和红色)。

1.合理选择控件容器
既然overdraw是因为重复绘制了同一片区域的像素点,那我们首先想到的是解决布局问题。Android提供的Layout控件主要包括LinearLayout、TableLayout、FrameLayout、RelativeLayout(这里我们不考虑AbsoluteLayout)。同一个界面我们可以使用不同的容器控件来表达,但是各个容器控件描述界面的复杂度是不一样的。一般来说LinearLayout最易,RelativeLayout较复杂。但是尺有所短,寸有所长,LinearLayout只能用来描述一个方向上连续排列的控件,容易导致布局文件嵌套太深,不符合布局扁平化的设计原理。而RelativeLayout几乎可以用于描述任意复杂度的界面。但是表达能力越强的容器控件,性能往往略低一些,因为RelativeLayout主要在onMeasure和onLayout阶段会耗费更多时间。综上所述:LinearLayout易用,效率高,表达能力有限。RelativeLayout复杂,表达能力强,但是效率稍逊。所以当某一界面在使用LinearLayout并不会比RelativeLayout带来更多的控件数和控件层级时,我们要优先考虑LinearLayout。但是要根据实际情况来做一个取舍,在保证性能的同时尽量避免OverDraw。


2.去掉window的默认背景
当我们使用了Android自带的一些主题时,window会被默认添加一个纯色的背景,这个背景是被DecorView持有的。当我们的自定义布局时又添加了一张背景图或者设置背景色,那么DecorView的background此时对我们来说是无用的,但是它会产生一次Overdraw,带来绘制性能损耗。去掉window的背景可以在onCreate()中setContentView()之后调用
getWindow().setBackgroundDrawable(null);

或者在theme中添加
android:windowbackground="null";


3.去掉其他不必要的背景
有时候为了方便会先给Layout设置一个整体的背景,再给子View设置背景,这里也会造成重叠,如果子View宽度mach_parent,可以看到完全覆盖了Layout的一部分,这里就可以通过分别设置背景来减少重绘。再比如如果采用的是selector的背景,将normal状态的color设置为“@android:color/transparent",也同样可以解决问题。这里只简单举两个例子,我们在开发过程中的一些习惯性思维定式会带来不经意的Overdraw,所以开发过程中我们为某个View或者ViewGroup设置背景的时候,先思考下是否真的有必要,或者思考下这个背景能不能分段设置在子View上,而不是图方便直接设置在根View上。


4.ClipRect & QuickReject
为了解决Overdraw的问题,Android系统会通过避免绘制那些完全不可见的组件来尽量减少消耗。但是不幸的是,对于那些过于复杂的自定义的View(通常重写了onDraw方法),Android系统无法检测在onDraw里面具体会执行什么操作,系统无法监控并自动优化,也就无法避免Overdraw了。但是我们可以通过canvas.clipRect()来帮助系统识别那些可见的区域。这个方法可以指定一块矩形区域,只有在这个区域内才会被绘制,其他的区域会被忽视。这个API可以很好的帮助那些有多组重叠组件的自定义View来控制显示的区域。同时clipRect方法还可以帮助节约CPU与GPU资源,在clipRect区域之外的绘制指令都不会被执行,那些部分内容在矩形区域内的组件,仍然会得到绘制。除了clipRect方法之外,我们还可以使用canvas.quickreject()来判断是否没和某个矩形相交,从而跳过那些非矩形区域内的绘制操作。
clip方法详解


5.使用ViewStub占位
ViewStub是个什么东西?一句话总结:高效占位符。我们经常会遇到这样的情况,运行时动态根据条件来决定显示哪个View或布局。常用的做法是把View都写在上面,先把它们的可见性都设为View.GONE,然后在代码中动态的更改它的可见性。这样的做法的优点是逻辑简单而且控制起来比较灵活。但是它的缺点就是,耗费资源。虽然把View的初始可见View.GONE但是在Inflate布局的时候View仍然会被Inflate,也就是说仍然会创建对象,会被实例化,会被设置属性。也就是说,会耗费内存等资源。推荐的做法是使用android.view.ViewStub,ViewStub是一个轻量级的View,它一个看不见的,不占布局位置,占用资源非常小的控件。可以为ViewStub指定一个布局,在Inflate布局的时候,只有ViewStub会被初始化,然后当ViewStub被设置为可见的时候,或是调用了ViewStub.inflate()的时候,ViewStub所向的布局就会被Inflate和实例化,然后ViewStub的布局属性都会传给它所指向的布局。这样,就可以使用ViewStub来方便的在运行时,要还是不要显示某个布局。

当你想加载布局时,可以使用下面其中一种方法:


6.用Merge减少布局深度
Merge标签有什么用呢?简单粗暴点回答:干掉一个view层级。Merge的作用很明显,但是也有一些使用条件的限制。有两种情况下我们可以使用Merge标签来做容器控件。第一种子视图不需要指定任何针对父视图的布局属性,就是说父容器仅仅是个容器,子视图只需要直接添加到父视图上用于显示就行。另外一种是假如需要在LinearLayout里面嵌入一个布局(或者视图),而恰恰这个布局(或者视图)的根节点也是LinearLayout,这样就多了一层没有用的嵌套,无疑这样只会拖慢程序速度。而这个时候如果我们使用merge根标签就可以避免那样的问题。另外Merge只能作为XML布局的根标签使用,当Inflate以开头的布局文件时,必须指定一个父ViewGroup,并且必须设定attachToRoot为true。
使用HierarchyViewer检查布局层级


7.善用draw9patch
给ImageView加一个边框,你肯定遇到过这种需求,通常在ImageView后面设置一张背景图,露出边框便完美解决问题,此时这个ImageView,设置了两层drawable,底下一层仅仅是为了作为图片的边框而已。但是两层drawable的重叠区域去绘制了两次,导致overdraw。优化方案: 将背景drawable制作成draw9patch,并且将和前景重叠的部分设置为透明。由于Android的2D渲染器会优化draw9patch中的透明区域,从而优化了这次overdraw。 但是背景图片必须制作成draw9patch才行,因为Android 2D渲染器只对draw9patch有这个优化,否则,一张普通的Png,就算你把中间的部分设置成透明,也不会减少这次overdraw。


8.慎用Alpha
假如对一个View做Alpha转化,需要先将View绘制出来,然后做Alpha转化,最后将转换后的效果绘制在界面上。通俗点说,做Alpha转化就需要对当前View绘制两遍,可想而知,绘制效率会大打折扣,耗时会翻倍,所以Alpha还是慎用。如果一定做Alpha转化的话,可以采用缓存的方式。

通过setLayerType方式可以将当前界面缓存在GPU中,这样不需要每次绘制原始界面,但是GPU内存是相当宝贵的,所以用完要马上释放掉。


9.避免“OverDesign”
overdraw会给APP带来不好的体验,overdraw产生的原因无外乎:复杂的Layout层级,重叠的View,重叠的背景这几种。开发人员无节制的View堆砌,究其根本无非是产品无节制的需求设计。有道是“由俭入奢易,由奢入俭难",很多APP披着过度设计的华丽外衣,却忘了简单易用才是王道的本质,纷繁复杂的设计并不会给用户带来好的体验,反而会让用户有压迫感,产品本身也有可能因此变得卡顿。当然,一切抛开业务谈优化都是空中楼阁,这就需要产品设计也要有一个权衡,在复杂的业务逻辑与简单易用的界面展现中做一个平衡,而不是一味的OverDesign。



作者:Rave_Tian
链接:https://www.jianshu.com/p/2cc6d5842986
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/2912.html

相关文章

  • Android App 性能优化实践

    摘要:性能优化实践原文链接本文记录了优化需要用到的工具和以及在实践中的。关于优化,推荐一篇博客,给我很大帮助,性能优化系列。 Android App 性能优化实践 原文链接: http://stackvoid.com/performance-tuning-on-android/ 本文记录了Android App优化需要用到的工具和以及在实践中的Tips。也算对我这半年来部分工作的...

    sPeng 评论0 收藏0
  • Android性能优化问题总结

    摘要:性能优化第七篇严苛模式检测耗时与内存问题意思为严格模式,是用来检测程序中违例情况的开发者工具。但是用来评测一个应用是否真的卡顿存在两个问题,我们可以使用帧率检测。  性能优化这块,分为UI性能优化、内存优化、数据库优化、网络优化、耗电优化等等。可以从1.如何发现问题,2.怎么解决问题,3.解决效果对比,这几个方面去描述。举个简单例子——UI优化,可以从 UI出现什么问题(卡顿不流畅),怎么查...

    yibinnn 评论0 收藏0
  • Android性能优化

    摘要:无线可在手机端直接实现的功能,查看任意界面的布局。可对进行快速的内存流量电量帧率流畅度性能测试开发日志的查看日志查看网络数据包的抓取内部参数的调试真机代码耗时统计等。 性能指标 布局复杂度:布局复杂会导致布局需要更长的时间,从而导致进入应用慢、页面切换慢 耗电量:耗电量大会导致机器发热、缩短机器的有效使用时长 内存:内存消耗大会导致频繁GC,GC时会暂停其它工作,导致页面卡顿;内存泄...

    dackel 评论0 收藏0
  • Android比较实用的性能优化

    摘要:流畅性卡顿优化卡顿的场景通常是发生在用户交互体验最直接的方面。影响卡顿的两大因素,分别是界面绘制和数据处理。界面绘制主要原因是绘制的层级深页面复杂刷新不合理,由于这些原因导致卡顿的场景更多出现在和启动后的初始界面以及跳转到页面的绘制上。Android设备作为一种移动设备,无论是内存还是CPU的性能都受到了很大的限制,这导致Android程序的性能问题异常突出,随着产品的不断更新迭代,对于性能...

    freecode 评论0 收藏0
  • Android开发优化的几点建议

    摘要:网络数据优化移动端获取网络数据优化可以从以下几点着手连接复用节省连接建立时间,如开启。 安卓开发大军浩浩荡荡,经过近十年的发展,Android技术优化日异月新,如今Android 9.0 已经发布,Android系统性能也已经非常流畅,可以在体验上完全媲美iOS。但是,到了各大厂商手里,改源码、自定义系统,使得Android原生系统变得鱼龙混杂,然后到了不同层次的开发工程师手里,因为技...

    赵连江 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<