Android性能优化学习笔记

本文探讨了Android UI性能优化中的过度渲染问题,分析了如何利用GPU呈现模式分析进行性能检测,并介绍了CPU性能分析工具Systrace和TraceView在定位性能瓶颈中的应用,同时提到了内存性能优化的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.UI性能优化

过度渲染(overdraw)

一个视图中,视图层级越多,过度渲染就越严重。就是说一个像素点上,如果存在10个view层级,如果每个层级在onDraw中都会绘制,那么这个像素点将会被渲染十次。

在Android4.4及以上版本中,如果某个View完全被其他视图遮挡住了,那么就不会渲染这个view,这种技术叫Overdraw Avoidance。

检测视图渲染可以使用开发者选项的“调试GPU过度绘制”,不同颜色代表不同次数的过度绘制。网上大多说法是白色是0次,蓝色是1次,绿色是2次,浅红色是3次,深红色是4次或以上。但是我在7.0的机子上看到的是不止有这五种颜色,还有其他颜色。猜测可能是按照红橙黄绿蓝靛紫的顺序来排的,越靠近红色就也严重。

注意:当用上述提到的过度绘制检测工具时,KitKat 的 Overdraw Avoidance 功能会被禁止,因此你看到的还是原始布局,而不是系统优化后的布局。

检测GPU渲染的工具:Profile GPU Render(GPU 呈现模式分析)

可以看到上图中,除了条形图外,还有一条绿线,这是一条y=16ms的线。动画时,Android根据统计一秒刷新60帧,即一桢在16ms内完成,用户看起来就是流畅的,否则会显得卡顿。所以这是一条参考线。无论你主动刷新有多快,android两次渲染最小间隔是16ms。就是说一个view在5ms内渲染完了,然后马上invalidate请求刷新,Android也不会去那么快执行,即会延迟11ms执行。

每一帧会产生一个数据,在跳转Activity时,或者一个视图从不可见到可见的过程花费的时间很长远远超过16ms,一般滑动页面或者页面在做一些简单动画时花费的时间一般在16ms内,数据在不断产生,即条形图在不断向左移动。

条形图不同颜色代表不同意义

橘色(Swap Buffers):代表CPU等待GPU结束绘制的时间。如果该色段很高,意味着该应用在GPU中做了很多工作。我的点评:swapbuffer通知GPU,同时完成向SurfaceFlinger画布数据的提交。估计swapBuffers会在某个地方调用glFinish(),glFinish()的特性的是glFlush:将GL命令队列中的命令发送给显卡并清空命令队列,发送完立即返回;glFinish:将GL命令队列中的命令发送给显卡并清空命令队列,显卡完成这些命令(也就是画完了)后返回。如果GPU绘制需要比较多的时间,那么CPU在这里等待的时间就比较可观了。所以我觉得不是说cpu就等着GPU绘制完才开始工作,而是UI线程阻塞等待GPU绘制完,CPU还是会去调度其他线程执行的。如果该色段出现异常,看看是不是要GPU渲染的东西太多了。

红色(Command issue):代表了花费在Android 2D渲染器向OpenGL发起绘制和重绘display lists的的时间。色段的高度与绘制和重绘各个display lists的时间总和成正比--display list越多,色段越高。我的点评:应该几乎每个view实例都对应一个display list,所以色段异常这代表该控件树中的view实例较多,或者是需要更新的display list较多。

浅蓝色(Sync&Upload):代表了上传bitmap数据到GPU的时间。如果该色段很大则意味着应用正在花费着大量的时间用于加载大量图像。我的点评:如果该色段异常,则检查是否在绘制高质量的图片或者大量图片。

深蓝色(Draw):代表花费在创建view的display lists的时间。如果该色段很高,则可能有大量的自定义view在绘制,或者onDraw方法中有大量的处理逻辑。我的点评:如果该色段异常,则检查该界面的对应的控件树的各个onDraw方法中的逻辑,优先检查自定义

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值