首页 > 代码库 > android 内存问题

android 内存问题

借鉴:大苞米的博客(http://blog.csdn.net/a396901990

一.内存溢出(OOM--out of memory)

(1)内存溢出引发的问题展现:

1.程序卡顿,响应速度慢(内存占用高时JVM虚拟机会频繁触发GC)

2.莫名消失(当你的程序所占内存越大,它在后台的时候就越可能被干掉。反之内存占用越小,在后台存在的时间就越长)

3.直接崩溃(OutOfMemoryError)

(2)内存溢出的原因

因为app的每个进程或者每个虚拟机有个最大内存限制,如果申请的内存资源超过这个限制,系统就会抛出OOM错误。OOM跟整个设备的剩余内存没太大关系,跟系统运行内存有一定关系。比如比较早的android系统的一个虚拟机最多16M内存,当一个app启动后,虚拟机不停的申请内存资源来装载图片,当超过内存上限时就出现OOM。

android的内存组成:

APP内存由 dalvik内存 和 native内存 2部分组成,dalvik也就是java堆,创建的对象就是就是在这里分配的,而native是通过c/c++方式申请的内存,Bitmap就是以这种方式分配的。(android3.0以后,系统都默认通过dalvik分配的,native作为堆来管理)。这2部分加起来不能超过android对单个进程,虚拟机的内存限制。

(3)android系统为什么要设定app的内存限定

1.迫使开发者更合理的分配内存。限制每个应用的可用内存上限,可以放置某些应用程序恶意或者无意的使用过多的内存。而导致其它应用无法正常运行。Android是有多进程的,如果一个进程(就是一个应用)耗费过多的内存,其他应用就无法运行了。因为有了限制,使得开发者必须好好利用有限资源,优化资源的使用。

2.屏幕显示内容有限。即使有万千图片千万数据需要使用到,但在特定时刻需要展示给用户看的总是有限的,因为屏幕显示就那么大,上面可以放的信息就是很有限的。大部分信息都是处于准备显示状态,所以没必要给予太多heap内存。也就是说出现 OOM现象,绝大部分原因是我们的程序设计上有问题,需要优化 。优化方法很多,比如通过时间换空间,不停的加载要用的的图片,不停的回收不用的图片,把大图片解析成适合手机屏幕大小的图片等。

3.davlik虚拟机的设计。android上的app使用独立虚拟机运行,每开一个应用就会打开至少一个独立的虚拟机。这样可以避免虚拟机崩溃导致整个系统崩溃,同时代价就是需要浪费更多的内存。这样设计保证了android的稳定性。

二.GC自动回收内存

Android的gc会按照特定的算法回收程序不用的内存资源,避免app的内存申请约积越多,但是gc一般回收的资源是那些无主的对象内存或者软引用的资源,或者更软引用的引用资源。

(1)优点:

1.减轻编程负担,提高效率

c、c++中的内存回收都是程序员手动操作,否则其中的资源将消耗,造成资源的浪费甚至崩溃。但手工回收内存往往是一项复杂而艰巨的工作。而java语言采用一种动态存储管理技术,它自动地释放不再被程序引用的对象,按照特定的垃圾收集算法来实现资源自动回收的功能。当一个对象不再被引用的时候,内存回收它占领的空间,以便空间被后来的新对象使用。

2.消除堆内存控件碎片

由于创建对象和垃圾收集器释放丢弃对象所占的内存空间,内存会出现碎片。碎片是分配给对象的内存块之间的空闲内存洞。碎片整理将所占用的堆内存移到堆的一端,JVM将整理出的内存分配给新的对象。

(2)缺点

占用资源,不可预知,不可确定,不可操作。大学老师说了一句很生动形象的话,“只拉不收拾”。这是一个很不好的习惯,在编程过程中,还是应该有一定的编程素养。用了什么,在不需要的时候就及时销毁。

三.查看app内存分配情况

 1.通过DDMS中的heap选项卡监视内存情况:

Heap视图中部有一个叫做data object, 即数据对象,也就是我们的程序中大量存在的类类型的对象。

在data object一行中有一列是"Total Size", 其值就是当前进程中所有Java数据对象的内存总量。如果代码中存在没有释放对象引用的情况,则data object的"Total Size"值在每次gc后不会有美线的回落。随着操作次数的增加"Total Size"的值会越来越大。直到到达一个上限 后导致进程被kill掉。

2.在App里面我们可以通过totalMemory与freeMemory

3.adb shell dumpsys meminfo com.android.demo

 

 

未完,待续。。。

android 内存问题