关于Android性能优化,该从哪些方面入手?

Android设备作为一种移动设备,无论是内存还是CPU的性能都受到了很大的限制,这导致Android程序的性能问题异常突出,对于性能优化提出了更高的要求。本篇文章根据Android开发中一些有效的性能优化方法,贴出一些关于性能优化方面的技术文章,为Android开发中有关性能优化方面的学习提供一个参考。

一、Android性能优化的方面

参考:《Android开发艺术探索》

针对Android的性能优化,主要有以下几个有效的优化方法:

1.布局优化

2.绘制优化

3.内存泄漏优化

4.响应速度优化

5.ListView/RecycleView及Bitmap优化

6.线程优化

7.其他性能优化的建议

下面我们具体来介绍关于以上这几个方面优化的具体思路及解决方案。

二、布局优化

关于布局优化的思想很简单,就是尽量减少布局文件的层级。这个道理很浅显,布局中的层级少了,就意味着Android绘制时的工作量少了,那么程序的性能自然就提高了。

如何进行布局优化?

①删除布局中无用的控件和层次,其次有选择地使用性能比较低的ViewGroup。

关于有选择地使用性能比较低的ViewGroup,这就需要我们开发就实际灵活选择了。

例如:如果布局中既可以使用LinearLayout也可以使用RelativeLayout,那么就采用LinearLayout,这是因为RelativeLayout的功能比较复杂,它的布局过程需要花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup,因此可以考虑使用它们,但是很多时候单纯通过一个LinearLayout或者FrameLayout无法实现产品效果,需要通过嵌套的方式来完成。这种情况下还是建议采用RelativeLayout,因为ViewGroup的嵌套就相当于增加了布局的层级,同样会降低程序的性能。

②采用<include>标签,<merge>标签,ViewStub。

<include>标签主要用于布局重用。

<merge>标签一般和<include>配合使用,可以降低减少布局的层级。

ViewStub提供了按需加载的功能,当需要时才会将ViewStub中的布局加载到内存,提高了程序初始化效率。

关于它们的使用方法,参考:Android布局优化之include、merge、ViewStub的使用

③避免多度绘制

过度绘制(Overdraw)描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 UI 结构里面,如果不可见的 UI 也在做绘制的操作,会导致某些像素区域被绘制了多次,同时也会浪费大量的 CPU 以及 GPU 资源。

如下所示,有些部分在布局时,会被重复绘制。


关于过度绘制产生的一般场景及解决方案,参考:Android 过度绘制优化

三、绘制优化

绘制优化是指View的onDraw方法要避免执行大量的操作,这主要体现在两个方面:

①onDraw中不要创建新的局部对象。

因为onDraw方法可能会被频繁调用,这样就会在一瞬间产生大量的临时对象,这不仅占用了过多的内存而且还会导致系统更加频繁gc,降低了程序的执行效率。

②onDraw方法中不要做耗时的任务,也不能执行成千上万次的循环操作,尽管每次循环都很轻量级,但是大量的循环仍然十分抢占CPU的时间片,这会造成View的绘制过程不流畅。

按照Google官方给出的性能优化典范中的标准,View的绘制频率保证60fps是最佳的,这就要求每帧绘制时间不超过16ms(16ms = 1000/60),虽然程序很难保证16ms这个时间,但是尽量降低onDraw方法中的复杂度总是切实有效的。

四、内存泄漏优化

内存泄漏是开发过程中的一个需要重视的问题,但是由于内存泄露问题对开发人员的经验和开发意识有较高的要求,因此也是开发人员最容易犯的错误之一。

内存泄露的优化分为两个方面:

①在开发过程中避免写出有内存泄漏的代码

②通过一些分析工具比如MAT来找出潜在的内存泄露,然后解决。

对应于两种不同情况,一个是了解内存泄漏的可能场景以及如何规避,二是怎么查找内存泄漏。

1.那么我们就先了解什么是内存泄漏?这样我们才能知道如何避免。

大家都知道,java是有垃圾回收机制的,这使得java程序员比C++程序员轻松了许多,存储申请了,不用心心念念要加一句释放,java虚拟机会派出一些回收线程兢兢业业不定时地回收那些不再被需要的内存空间(注意回收的不是对象本身,而是对象占据的内存空间)。

Q1:什么叫不再被需要的内存空间?

答:Java没有指针,全凭引用来和对象进行关联,通过引用来操作对象。如果一个对象没有与任何引用关联,那么这个对象也就不太可能被使用到了,回收器便是把这些“无任何引用的对象”作为目标,回收了它们占据的内存空间。

Q2:如何分辨为对象无引用?

答:2种方法

引用计数法直接计数,简单高效,Python便是采用该方法。但是如果出现 两个对象相互引用,即使它们都无法被外界访问到,计数器不为0它们也始终不会被回收。为了解决该问题,java采用的是b方法。

可达性分析法这个方法设置了一系列的“GC Roots”对象作为索引起点,如果一个对象 与起点对象之间均无可达路径,那么这个不可达的对象就会成为回收对象。这种方法处理 两个对象相互引用的问题,如果两个对象均没有外部引用,会被判断为不可达对象进而被回收(如下图)。


Q3:有了回收机制,放心大胆用不会有内存泄漏?

答:答案当然是No!

虽然垃圾回收器会帮我们干掉大部分无用的内存空间,但是对于还保持着引用,但逻辑上已经不会再用到的对象,垃圾回收器不会回收它们。这些对象积累在内存中,直到程序结束,就是我们所说的“内存泄漏”。
当然了,用户对单次的内存泄漏并没有什么感知,但当泄漏积累到内存都被消耗完,就会导致卡顿,崩溃。

下面这张图可以帮助我们更好地理解对象的状态,以及内存泄漏的情况



左边未引用的对象是会被GC回收的,右边被引用的对象不会被GC回收,但是未使用的对象中除了未引用的对象,还包括已被引用的一部分对象,那么内存泄漏久发生这部分已被引用但未使用的对象。

2.Android一般在什么情况下会出现内存泄漏?

①集合类泄漏
②单例/静态变量造成的内存泄漏
③匿名内部类/非静态内部类
④资源未关闭造成的内存泄漏

大概可以分为以上几类,还有一些经常会听到的Hanlder,AsyncTask引起内存泄漏,都属于上述③中的情况。

那么上述四种情况是怎么造成的内存泄漏,具体是什么原因,以及Android中一些知名的引起内存泄漏的原因,以及解决方法是怎么样的?

关于这部分内容,看了一些较好的文章,向大家推荐一下:

[译]Android内存泄漏的八种可能(上)
[译]Android防止内存泄漏的八种方法(下)
Android 内存泄漏总结

3.Android怎么分析内存泄漏?

上面介绍了内存泄漏的场景,对应的有一些解决方案。

那么在内存泄漏已经发生的情况下,我们该如何解决呢?

我们可以通过MAT(Memory Analyzer Tool),或者 LeakCanary来检测Android中的内存泄漏。

上面的文章:Android 内存泄漏总结 也介绍了如何使用MAT,或者 LeakCanary来检测Android中的内存泄漏。

这篇文章Android 性能优化之使用MAT分析内存泄露问题详细介绍了使用MAT来检测Android中的内存泄漏。

五、响应速度优化

响应速度优化的核心思想就是避免在主线程中做耗时操作

如果有耗时操作,可以开启子线程执行,即采用异步的方式来执行耗时操作。

如果在主线程中做太多事情,会导致Activity启动时出现黑屏现象,甚至ANR。


Android规定,Activity如果5秒钟之内无法响应屏幕触摸事件或者键盘输入事件就会出现ANR,而BroadcastReceiver如果10秒钟之内还未执行完操作也会出现ANR。

为了避免ANR,可以开启子线程执行耗时操作,但是子线程不能更新UI,所以需要子线程与主线程进行通信来解决子线程执行耗时任务后,通知主线程更新UI的场景。关于这部分,需要掌握Handler消息机制,AsyncTask,IntentService等内容。

可以看以下内容:
Android消息机制的原理及源码解析
Android中的线程状态之AsyncTask详解
Android多线程全面解析:IntentService用法&源码

然而,在实际开发中,ANR仍然不可避免的发生了,而且很难从代码上发现,这时候就要用到ANR日志分析。当一个进程发生了ANR之后,系统会在/data/anr目录下创建一个文件traces.txt,通过分析这个文件就能定位出ANR的原因。

六、ListView/RecycleView及Bitmap优化


ListView/RecycleView的优化思想主要从以下几个方面入手:

①使用ViewHolder模式来提高效率

②异步加载:耗时的操作放在异步线程中

③ListView/RecycleView的滑动时停止加载和分页加载

具体优化建议及详情,参考:ListView的优化

Bitmap优化


主要是对加载图片进行压缩,避免加载图片多大导致OOM出现。

具体图片压缩方案,参考:彻底理解Bitmap的高效加载策略

七、线程优化

线程优化的思想就是采用线程池,避免程序中存在大量的Thread。线程池可以重用内部的线程,从而避免了线程的创建和销毁锁带来的性能开销,同时线程池还能有效地控制线程池的最大并法术,避免大量的线程因互相抢占系统资源从而导致阻塞现象的发生。因此在实际开发中,尽量采用线程池,而不是每次都要创建一个Thread对象。

关于线程池详解及使用,参考:Java线程池详解

八、其他性能优化建议

①避免过度的创建对象

②不要过度使用枚举,枚举占用的内存空间要比整型大

③常量请使用static final来修饰

④使用一些Android特有的数据结构,比如SparseArray和Pair等

⑤适当采用软引用和弱引用

⑥采用内存缓存和磁盘缓存

⑦尽量采用静态内部类,这样可以避免潜在的由于内部类而导致的内存泄漏。

以上是关于Android性能优化方面,我们一些入手点。从这些方面,我们可以在平时的开发中注意,避免类似错误,提高Android程序的性能,但是其中一些方面的要求则需要我们不断的学习,以及平时良好的意识与习惯。由于自己开发经验几乎为0,没办法根据实际经验来说明,只能写下这篇文章来提醒自己以后开发的时候需要注意和培养的地方。

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

推荐阅读更多精彩内容