您的位置 首页 发布

Android内存办理之道

相信一步步走过来的Android从业者,每个人都会遇到OOM的情况。如何避免和防范OOM的出现,对于每一个程序员来说确实是一门必不可少的能力。今天我们

信任一步步走过来的Android从业者,每个人都会遇到OOM的状况。怎么防止和防备OOM的呈现,关于每一个程序员来说确实是一门必不可少的才干。今日咱们就谈谈在Android平台下内存的办理之道,开端今日的主题之前,先再次回忆两个概念。

内存走漏:目标在内存heap堆中中分配的空间,当不再运用或没有引证指向的状况下,仍不能被GC正常收回的状况。大都呈现在不合理的编码状况下,比方在Activity中注册了一个播送接收器,可是在页面封闭的时分进行unRegister,就会呈现内存溢出的现象。通常状况下,许多的内存走漏会形成OOM。

OOM:即OutOfMemoery,望文生义便是指内存溢出了。内存溢出是指APP向体系恳求超越最大阀值的内存恳求,体系不会再分配剩余的空间,就会形成OOM error。在咱们Android平台下,大都状况是呈现在图片不妥处理加载的时分。

内存办理之道嘛,无非便是先了解并找出内存走漏的原因,再依据这些反式去合理的编码,去防备然后防止内存开支过大的景象。学习怎么合理的办理内存,最好先了解内存分配的机制和原理。只要深层次的了解了内部的原理,才干真实防止OOM的产生。可是本文就不介绍Jvm/Davilk内存分配的机制了,如有爱好,请检查前史音讯,曾经做过题为《JVM运转时数据区域剖析》的共享。

Android APP的所能恳求的最大内存巨细是多少,有人说是16MB,有人又说是24MB。这种工作,仍是亲自用自己的手机测验下比较靠谱。测验办法也比较简略,Java中有个Runtime类,首要用作APP与运转环境交互,APP并不会为咱们创立Runtime的实例,可是Java为咱们供给了单例获取的办法Runtime.getRuntime()。经过maxMemory()办法获取体系可为APP分配的最大内存,totalMemory()获取APP当时所分配的内存heap空间巨细。我手上有两部手机,一部Oppo find7,运转Color OS,实测最大内存分配为192MB;一部天语v9,运转小米体系,实测最大内存分配为100MB。这下看出点端倪了吧,因为Android是开源体系,不同的手机厂商其实是具有修正这部分权限才干的,所以就形成了不同品牌和不同体系的手机,关于APP的内存支撑也是不相同的,和IOS的长久100MB是不同的。一般来说,手机内存的装备越高,厂商也会调大手机支撑的内存最大阀值,特别是现在旗舰机满天发布的状况下。可是开发者为了考虑开宣布的APP的内存兼容性,无法保证APP运转在何种手机上,只能从编码视点来优化内存了。

下面咱们逐条来剖析Android内存优化的要害点。

1、万恶的static

static是个好东西,声明赋值调用便是那么的简略便利,可是随同而来的还有功能问题。因为static声明变量的生命周期其实是和APP的生命周期相同的,有点相似与Application。假如许多的运用的话,就会占有内存空间不开释,集腋成裘也会形成内存的不断开支,直至挂掉。static的合理运用一般用来润饰根本数据类型或许轻量级目标,尽量防止修正调集或许大目标,常用作润饰大局装备项、东西类办法、内部类。

2、无关引证

许多状况下,咱们需求用到传递引证,可是咱们无法保证引证传递出去后能否及时的收回。比方比较有代表性的Context走漏,许多状况下当Activity 结束掉后,因为仍被其他的目标指向导致一向迟迟不能收回,这就形成了内存走漏。这时能够考虑第三条主张。

3、善用SoftReference/WeakReference/LruCache

Java、Android中有没有这样一种机制呢,当内存吃紧或许GC扫过的状况下,就能及时把一些内存占用给开释掉,然后分配给需求分配的当地。答案是必定的,java为咱们供给了两个处理方案。假如对内存的开支比较重视的APP,能够考虑运用WeakReference,当GC收回扫过这块内存区域时就会收回;假如不是那么重视的话,能够运用SoftReference,它会在内存恳求缺乏的状况下自动开释,相同也能处理OOM问题。一起Android自3.0今后也推出了LruCache类,运用LRU算法就开释内存,相同的能处理OOM,假如兼容3.0一下的版别,请导入v4包。关于第二条的无关引证的问题,咱们传参能够考虑运用WeakReference包装一下。

4、慎重handler

在处理异步操作的时分,handler + thread是个不错的挑选。可是信任在运用handler的时分,我们都会遇到正告的景象,这个便是lint为开发者的提示。handler运转于UI线程,不断处理来自MessageQueue的音讯,假如handler还有音讯需求处理可是Activity页面现已结束的状况下,Activity的引证其实并不会被收回,这就形成了内存走漏。处理方案,一是在Activity的onDestroy办法中调用

handler.removeCallbacksAndMessages(null);撤销一切的音讯的处理,包含待处理的音讯;二是声明handler的内部类为static。

5、Bitmap终极杀手

Bitmap的不妥处理极或许形成OOM,绝大大都状况都是因这个原因呈现的。Bitamp位图是Android中名副其实的胖小子,所以在操作的时分当然是非常的当心了。因为Dalivk并不会自动的去收回,需求开发者在Bitmap不被运用的时分recycle掉。运用的过程中,及时开释是非常重要的。一起假如需求答应,也能够去BItmap进行必定的缩放,经过BitmapFactory.Options的inSampleSize特点进行操控。假如只是只想取得Bitmap的特点,其实并不需求依据BItmap的像素去分配内存,只需在解析读取Bmp的时分运用BitmapFactory.Options的inJustDecodeBounds特点。最终主张我们在加载网络图片的时分,运用软引证或许弱引证并进行本地缓存,引荐运用android-universal-imageloader或许xUtils,牛人出品,必属精品。前几天在讲《自定义控件(三) 承继控件》的时分,也收拾一个,我们能够去Github下载看看。

6、Cursor及时封闭

在查询SQLite数据库时,会回来一个Cursor,当查询结束后,及时封闭,这样就能够把查询的成果集及时给收回掉。

7、页面布景和图片加载

在布局和代码中设置布景和图片的时分,假如是纯色,尽量运用color;假如是规矩图形,尽量运用shape画图;假如略微复杂点,能够运用9patch图;假如不能运用9patch的状况下,针对几种干流分辨率的机型进行切图。

8、ListView和GridView的item缓存

关于移动设备,特别硬件良莠不齐的android生态,页面的制作其实是很耗时的,findViewById也是蛮慢的。所以不重用View,在有列表的时分就尤为明显了,常常会呈现滑动很卡的现象。详细参照前史文章《说说ViewHolder的另一种写法》

声明:本文内容来自网络转载或用户投稿,文章版权归原作者和原出处所有。文中观点,不代表本站立场。若有侵权请联系本站删除(kf@86ic.com)https://www.86ic.net/changshang/fabu/321634.html

为您推荐

联系我们

联系我们

在线咨询: QQ交谈

邮箱: kf@86ic.com

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

返回顶部