【Android端 APP GPU过度绘制】GPU过度绘制及优化

一、Android端的卡顿

Android端APP在具体使用的过程中容易出现卡顿的情况，比如查看页面时出现一顿一顿的感受，切换tab之后响应很慢，或者具体滑动操作的时候也很慢。

二、卡顿的原因

卡顿的原因可能有很多种，比如：

1、CPU过高

2、内存溢出

3、主线程处理IO操作等

…

其中过度绘制，是一个容易被忽视但也最好修改并且能够看到效果的内容，其中Android官网给出的过度绘制相关内容见：https://developer.android.com/topic/performance/rendering/overdraw.html

三、什么是过度绘制

1、过度绘制的概念 及如何确定是否是过度绘制？

过度绘制就是在绘制界面时，对同一个像素重复绘制了多次，但是用户能够看到的也只有最顶层绘制的内容。

Android端显示原理的简介见：http://djt.qq.com/article/view/987

显示原理用一句话描述就是：Android应用程序调用SurfaceFlinger服务把经过测量、布局和绘制后的Surface渲染到显示屏幕上。

名词解释

SurfaceFlinger：Android系统服务，负责管理Android系统的帧缓冲区，即显示屏幕。

Surface：Android应用的每个窗口对应一个画布（Canvas），即Surface，可以理解为Android应用程序的一个窗口。

通过Android端的开发者设置-调试GPU过度绘制，选择显示过度绘制区域，就能够看到如下图所示内容：

以小米4 的设置—短信界面为例：

其中我们能够看到四种颜色，分别是：蓝色、绿色、淡红色和红色

其中颜色标识所代表的含义如下：（其中1x代表依次过度绘制，即红色已经是5次及5次以上绘制了）

（1）蓝色1x过度绘制

（2）绿色2x过度绘制

（3）淡红色3x过度绘制

（4）红色4x过度绘制（4次及以上）

App的验收标准：

（1）控制过度绘制为2x

（2）非强制GPU的情况下，无红色区域，即无4x过度绘制情况

（3）浅红色区域总面积不超过屏幕的1/4大小

2 、如何进行优化？

一般出现过度绘制的可能原因是：

（1）无用的背景图片

（2）层级太深

（3）无用的父节点、子节点

（4）没有使用9patch图片

...

下面看我自己写的一个登录程序的例子，来看绘制的时候，oncreate方法花费的时长来进行一个优化和比较验证。

首先看到的是存在过度绘制的一个登录页面，可以看到红色区域占据了很大一部分

首先，我们通过把无用的背景色全部删除掉，之后将无用的节点删除，比如一个LinearLayout的父节点下面就只有一个Button的属性，这样就没必要有LinearLayout的这个节点了，删除就可以了，因为这里面没有用到图片，后面再通过.9图片和非.9图片的效果验证进行对比。

无过度绘制的登录界面的截图如下：

然后我们通过获取多次onCcreate的时长，来进行平均时长的验证（每次都会杀进程，一共获取10次，不包含第一次装包）：

这是有过度绘制的安装包的onCreate的时长：

01-03 18:33:36.375 16700-16700/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:33:36.475 16700-16700/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:33:51.415 17067-17067/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:33:51.495 17067-17067/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:34:05.415 17416-17416/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:34:05.515 17416-17416/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:34:15.615 17689-17689/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:34:15.715 17689-17689/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:34:24.335 18011-18011/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:34:24.425 18011-18011/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:34:34.855 18297-18297/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:34:35.005 18297-18297/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:34:58.075 18821-18821/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:34:58.215 18821-18821/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:35:07.635 19100-19100/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:35:07.765 19100-19100/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:35:54.535 19385-19385/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:35:54.635 19385-19385/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:36:03.775 19675-19675/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:36:03.905 19675-19675/com.example.a58.testapplication D/onCreate: endCreate

汇总：ms为单位

100、80、100、100、90、150、140、130、100、130

之后是替换成无过度绘制的安装包的onCreate的时长：

01-03 18:42:49.445 24469-24469/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:42:49.525 24469-24469/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:42:57.185 24720-24720/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:42:57.305 24720-24720/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:43:07.075 24987-24987/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:43:07.185 24987-24987/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:44:26.615 26384-26384/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:44:26.715 26384-26384/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:44:34.475 26634-26634/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:44:34.575 26634-26634/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:45:03.965 27023-27023/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:45:04.065 27023-27023/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:46:04.285 28059-28059/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:46:04.375 28059-28059/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:46:43.925 28540-28540/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:46:44.045 28540-28540/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:47:03.865 28907-28907/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:47:03.975 28907-28907/com.example.a58.testapplication D/onCreate: endCreate

01-03 18:47:24.755 29303-29303/com.example.a58.testapplication D/onCreate: startCreate

01-03 18:47:24.855 29303-29303/com.example.a58.testapplication D/onCreate: endCreate

汇总：ms为单位

80、120、110、100、100、100、90、120、110、100

通过以上数据比较可以看出，整体平均值是有减少，幅度将近10%，最长时长明显减少了30ms

时间： 2024-10-26 15:23:08

【Android端 APP GPU过度绘制】GPU过度绘制及优化的相关文章

史无前例，详细视频讲解开发Android端APP开发！！

导读:本文记录了一个机友-小徐基于机智云APP开源框架,从搭建Java环境开始,教你下载JDk.下载AndroidStudio,到控制设备页面等,完成一款正式版安卓APP的开发过程.擅长硬件开发的小伙伴们,如果你想探索APP开发的奥秘,那就来看小徐分享的开发视频吧. 声明:           本人发视频是以个人分享精神.完全免费的心态发布的,这也是我个人生涯第一次录制视频并发布,课程好与坏咱们不谈,我尽最大的努力,把视频做好,把知识点传授给大家,但如果有用词不当,或讲错什么知识点,还请万分见谅

【Android端 APP 内存分析】使用工具进行APP的内存分析

Android端可以通过adb 命令直接获取内存信息,当然Android studio也提供了对内存的监控分析工具,并且后续可以结合MAT做分析 今天介绍的是通过Android studio和MAT工具进行分析的方法: 1.通过Android studio打包之后,app安装成功 2.点击 Android Monitor,具体见下图: 运行APP成功之后,就能看到下图中所示,说明APP的进程已经启动起来了,然后就可以进行操作和观察数据了 看到Android Monitor里面能够监控的数据有:C

【Android端 APP 启动时长获取】启动时长获取方案及具体实施

一.什么是启动时长? 1.启动时长一般包括三种场景,分别是:新装包的首次启动时长,冷启动时长.热启动时长 冷启动 和 热启动 : (1)冷启动:当启动应用时,后台没有该程序的进程,此时启动的话系统会分配一个新的进程给应用. (2)热启动:程序的进程依然存在,启动时通过已有进程启动进入到Activity显示页面的,就是热启动,或者从Android官网来看我们获取到的其实是温启动时长,就是Activity不存在的情况. (3)新装包的启动时长: 新装包的启动时长,预估是最长的,并且在5.0以下及5.

将报表移动端集成到自有移动端app方法【IOS、Android】

应用场景 用户有自己的app,希望把报表的移动端[本文中以FineReport移动端为例]功能集成到他们的app里面去,而不需要安装两个app.Android端和IOS端的集成接口是不一样的,下面我们分开详述如何实现. IOS端集成App 1. 资源准备 准备好IOS端集成FineReport App的资源文件,包括自己的IOS工程.FineReport提供的资源包. 下载FineReport提供的集成资源包,解压至文件夹中,可以看到如下图所示的文件: 其中FRDemo和FRDemo_目录树是示

微信app支付(android端+java后台)

本文讲解使用微信支付接口完成在android开发的原生态app中完成微信支付功能, 文章具体讲解了前端android如何集成微信支付功能以及后台如何组装前端需要支付信息, 话不多话, 具体看文章内容吧00:00 / 07:03正常 本实例项目运行条件: 开发环境: [Android Studio] 到微信开放平台注册帐号并且创建移动应用 https://open.weixin.qq.com/cgi-bin/frame?t=home/app_tmpl&lang=zh_CN Column 1 Col

UI设计师必须了解：2015年十大移动端APP设计主流趋势

从移动端兴起,主流设计风格定型,再到Uber.Vine等现象级APP的崛起,移动端的APP设计直到现在才渐入佳境.促成这一切的影响因素很多,比如社会发展趋势的变化.共享经济的大热.新技术的积累,等等等等.这些事物的出现需要时间积累,这也是为什么这些应用到现在才火起来. 同样的,今年我们要关注的是定型了的巨屏手机和逐渐沉淀下来的可穿戴设备. 随着日常生活中所涉及到的移动端应用的增加,用户在这些东西上的所耗费的精神和脑力也越来越多.查看邮件.预订酒店.叫外卖都有赖于各种应用,而诸如Airbnb和Gr

Android中app卡顿原因分析示例

在知乎回答了一个“为什么微博的app在iPhone比Android上流畅”的问题.后面部分是一个典型的动画卡顿的性能分析过程,因此帖在这里.有编程问题可以在这里交流.知乎链接. ========================================================= 我来说下我所知道的事情.我不知道iOS为什么流畅,但我知道一些Android为什么不流畅的原因. 首先,就题主所说的问题,我用iPad和小米Pad对比了一下微博滑动滚屏这件事情(2014年8月10日目前微博

android之app流畅度分析

大多数人感觉卡顿等性能问题的最主要根源都是因为渲染性能.从设计师的角度,他们希望App能够有更多的动画,图片等时尚元素来实现流畅的用户体验.但是Android系统很有可能无法及时完成那些复杂的界面渲染操作.Android系统每隔16ms发出VSYNC信号,触发对UI进行渲染,如果每次渲染都成功,这样就能够达到流畅的画面所需要的60fps,为了能够实现60fps,这意味着程序的大多数操作都必须在16ms内完成.时间超出16ms越多,丢的帧就越多(可以大概估计5秒没响应抛出anr异常期间丢了多少帧,

Daydream从入门到精通——快速入门开发基础教程二：Android端开发环境配置二

开始部署 上篇介绍了开发Daydream Android VR需要的基本环境,这篇我们来看看如何部署和运用官方示例. -------------------------------------------------------------------------------------------------------------------- Daydream快速入门开发基础教程一:Android端开发环境配置一 http://blog.csdn.net/jaikydota163/arti