Android性能优化之-渲染优化

Android的性能优化一直是app开发中非常重要的一环,一款app的性能,直接影响到用户体验和使用率,所以本篇对app性能优化的相关知识进行了汇总,将性能优化的各个问题进行了分类并分析处理;为提高app的性能和效率做准备,说到app的性能问题,主要有以下几类:

性能问题.png

上图列出了app性能优化的各个方面,要想打造一款高质量高性能的app,就要朝着这四方面进行努力
快: 避免卡顿、响应速度快、用户使用流畅、满足用户期望;
稳: 减少Crash率和ANR率;
省:节省流量和耗电,减少用户使用成本,避免手机发烫发热;
小:安装包足够小、减少用户安装时间;
接下来我们就会按照以上四个方面对app的性能优化进行分析和详解,首先是“快”,渲染优化详解;

渲染优化

首先我们来分析一下造成UI卡顿常见的原因有哪些:
1、在UI线程中做轻微耗时操作;
2、Layout过于复杂,无法在16ms中完成渲染;
3、同一时间动画执行次数过多,造成CPU或GPU负载过重;
4、View过渡绘制,某一像素在同一帧重复绘制;
5、View频繁的触发measure、layout,导致measure、layout累计耗时过多及整个View频繁的重新渲染;
6、内存频繁触发GC过多(同一帧中频繁创建内存),导致暂时阻塞渲染操作;
7、冗余资源及逻辑等导致加载和执行缓慢;
8、ANR;

综上所述,我们感受到的卡顿问题大多都是因为渲染性能,Android系统每隔16ms发出VSYNC信号(vertical synchronization --场扫描同步,场同步,垂直同步),触发对UI进行渲染,如果每次渲染都成功,这样就能够达到流畅的画面所需要的60fps,为了能够实现60fps,这意味着程序的大多数操作都必须在16ms(1000/60=16.67ms)内完成。如果你的某个操作花费时间是24ms,系统在得到VSYNC信号的时候就无法进行正常渲染,这样就发生了丢帧现象。那么用户在32ms内看到的会是同一帧画面,造成卡顿;

正常情况


渲染机制

卡顿


渲染机制

通过上面的分析,我们可以知道,造成卡顿最主要的原因是过度绘制和布局不合理,所以接下来我们就着重从这两个方面来进行分析和处理;

1、 过度绘制

Overdraw(过度绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次的UI结构里面,如果不可见的UI也在做绘制的操作,这就会导致某些像素区域被绘制了多次。这就浪费大量的CPU以及GPU资源,找出界面滑动不流畅、界面启动速度慢、手机发热。

如何查看过度绘制
手机---开发者选项---调试GPU过渡绘制
打开过渡绘制后,就会看到如下类似如下页面:

过度绘制测试

可以打开自己的APP,每个页面都会依次来显示页面哪里出现了过渡绘制,各个颜色区别如下所示:
过度绘制级别

可以看出,颜色越深代表绘制的次数越多;
那么造成过渡绘制最根本的原因是什么呢?最主要的原因就是重复和多余的background以及布局的嵌套,父控件有background,子控件也有background,甚至多层嵌套的布局,每层都有不一样的background,这样就会导致页面过渡绘制,因此我们在开发当中,应移除多余重复的background,尽量减少布局嵌套,并移除无用嵌套布局;

综上所述,我们对过渡绘制的问题进行总结:
问题原因
1、重复多余的background;
2、冗余的布局嵌套;
解决方案
1、移除重复多余的background;
2、移除不必要的布局嵌套;
3、移除window默认背景;
4、按需显示占位背景图片;

2、布局优化

布局太过复杂,层级嵌套太深导致绘制操作耗时,且增加内存的消耗。
我们的目标就是,层级扁平化。

布局优化主要从以下几个方面

1、使用效率更高的布局方式,如线性布局、帧布局
能用LinearLayout和FrameLayout,就不要用RelativeLayout,因为RelativeLayout控件相对比较复杂,测绘也想要耗时。如果使用相对布局减少层级的就使用相对布局;

2、减少不必要的布局层级
这里就不得不提到include和merge标签了
include 可以提高布局的复用性,优化了布局的层级结构,使得布局结构清晰,但实际上include并没有减少布局的层级,所以include必须和merge同时使用,方可减少布局层级;

include的使用 one_layout

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <include layout="@layout/title_layout" />

</LinearLayout>

merge 该标签用来合并布局,merge的布局取决于父控件是哪个布局,使用merge相当于减少了自身的一层布局,直接采用父include的布局,当然直接在父布局里面使用意义不大,所以会和include配合使用,既增加了布局的复用性,用减少了一层布局嵌套。
include和merge配合使用

<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="title" />

</merge>

如上代码所示,merge实际上是和使用include标签的父布局同用一个布局 即LinearLayout

3、惰性加载又称延迟加载
使用惰性控件ViewStub实现布局动态加载
ViewStub它可以按需加载,这个标签最大的优点是当你需要时才会加载,使用他并不会影响UI初始化时的性能。通常情况下我们需要在某个条件下使用某个布局的时候会通过gone或者invisible来隐藏,其实这样的方式虽然隐藏了布局,但是当显示该界面的时候还是将该布局实例化的。使用ViewStub可以避免内存的浪费,加快渲染速度。其实ViewStub就是一个宽高都为0的一个View,它默认是不可见的,只有通过调用setVisibility函数或者Inflate函数才会将其要装载的目标布局给加载出来,从而达到延迟加载的效果,这个要被加载的布局通过android:layout属性来设置。
ViewStub标签的使用

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <include layout="@layout/title_layout" />

    <ViewStub
        android:id="@+id/stub_content"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout="@layout/content_layout" />

</LinearLayout>

content_layout

<?xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/content_text"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:text="content">

</TextView>

ViewStub布局显示

        //显示ViewStub布局
        ViewStub stub = findViewById(R.id.stub_content);
        stub.inflate();

        //或者
        //stub.setVisibility(View.VISIBLE);

注意:使用ViewStub加载的布局中不能使用merge标签。

4、使用ConstraintLayout布局
ConstraintLayout可以有效地解决布局嵌套过多的问题。ConstraintLayout使用约束的方式来指定各个控件的位置和关系的,它有点类似于 RelativeLayout,但远比RelativeLayout要更强大(照抄隔壁IOS的约束布局)。所以简单布局简单处理,复杂布局ConstraintLayout很好使,提升性能从布局做起。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,393评论 5 467
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,790评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,391评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,703评论 1 270
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,613评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,003评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,507评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,158评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,300评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,256评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,274评论 1 328
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,984评论 3 316
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,569评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,662评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,899评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,268评论 2 345
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,840评论 2 339

推荐阅读更多精彩内容