Android 内存溢出(Out Of Memory)的总结

内存溢出主要由以下几种情况引起:

1.数据库的cursor没有关闭。

2.构造adapter没有使用缓存contentview。

3.调用registerReceiver后未调用unregisterReceiver()。

4.未关闭InputStream/OutputStream。

5.Bitmap使用后未调用recycle()。

6.Context泄漏。

前5种情况容易发现和解决,只要把该关的及时关闭,该调用的方法及时调用,就不会有太多问题,另外java里还有软引用帮助管理内存:

SoftReference<Bitmap> bitmap;
bitmap = new SoftReference<Bitmap>(pBitmap);
if(bitmap != null){

if(bitmap.get() != null && !bitmap.get().isRecycled()){
bitmap.get().recycle();
bitmap = null;
}
}

下面着重介绍Context泄漏。

这是一个很隐晦的内存泄露的情况。先看一个Android官网提供的例子:

private static Drawable sBackground;

@Override
protected void onCreate(Bundle state) {
  super.onCreate(state);

  TextView label = new TextView(this);
  label.setText("Leaks are bad");

  if (sBackground == null) {
    sBackground = getDrawable(R.drawable.large_bitmap);
  }
  label.setBackgroundDrawable(sBackground);

  setContentView(label);
}

这段代码效率很快,但同时又是极其错误的;在第一次屏幕方向切换时它泄露了一开始创建的Activity。当一个Drawable附加到一个View上时,View会将其作为一个callback设定到Drawable上。上述的代码片段,意味着Drawable拥有一个TextView的引用,而TextView又拥有Activity(Context类型)的引用,换句话说,Drawable拥有了更多的对象引用。即使Activity被销毁,内存仍然不会被释放。

另外,对Context的引用超过它本身的生命周期,也会导致Context泄漏。所以尽量使用Application这种Context类型。这种Context拥有和应用程序一样长的生命周期,并且不依赖Activity的生命周期。如果你打算保存一个长时间的对象,并且其需要一个Context,记得使用Application对象。你可以通过调用Context.getApplicationContext()或Activity.getApplication()轻松得到Application对象。

最近遇到一种情况引起了Context泄漏,就是在Activity销毁时,里面有其他线程没有停。

总结一下避免Context泄漏应该注意的问题:

1.使用Application这种Context类型。

2.注意对Context的引用不要超过它本身的生命周期。

3.慎重的使用“static”关键字。

4.Context里如果有线程,一定要在onDestroy()里及时停掉。

时间: 2025-01-02 11:00:37

Android 内存溢出(Out Of Memory)的总结的相关文章

Android 内存溢出管理与测试

今天发现正在做的项目,时不时的会报错:dalvikvm heap out of memory on a 7458832-byte allocation (堆分配的内存溢出) 为什么会内存溢出呢?我以前从未遇见这种情况.后来在网上查了查资料,还是挺多的. 怎么说呢?因为Android开发基本上是以java语言为基础,那么程序是在java虚拟机上运行的.而虚拟机不允许单个程序中的Bitmap占用超过8M的内存,从报错的日志可以看出:7458832-byte大约就是7M多的样子,基本吻合上述数据.在我

【Android】Android内存溢出问题---用自行开辟的空间进行对内存管理

public static Bitmap readBitmap(String path) { BitmapFactory.Options options = new BitmapFactory.Options(); options.inPreferredConfig = Bitmap.Config.RGB_565; options.inPurgeable = true; options.inInputShareable = true; options.inSampleSize = compute

android 内存溢出的一些想法

对于android内存溢出这个问题,小编很是头痛!在这里说下小编自己的想法! 首先内存引用分为强引用,弱引用,软引用,虚引用! 强引用是一个实例引用,根据java的gc原理,如果存在引用,就无法自动回收,所以强引用必须在用完后使其=null ex:Object object = new Object(); object = null; 软引用是在强引用的基础上引用,使用Softreference进行引用,它是除非系统内存不足时才会回收,其它时候均不会回收,适合做cache: ex: Object

【转载】Android 内存溢出如何发生的。

且谈Android内存溢出 前言 关于android的内存溢出在创新文档库中也有不少,网络上也有很多这方面的资料.所以这遍文章不算是正真意义上的创新,仅仅只是对xxx源码中出现的一些android开发中容易犯错的代码习惯一次总结. 1.  Android的内存溢出是如何发生的 Android的虚拟机是基于寄存器的Dalvik,它的最大堆大小一般是16M,有的机器为24M.因此我们所能利用的内存空间是有限的.如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误. 原因主要有两个:

各路搜集,分析Android内存溢出

叙述不当之处,欢迎指正. Android主要应用在嵌入式设备当中,而嵌入式设备由于一些众所周知的条件限制,通常都不会有很高的配置,特别是内存是比较有限的.如果我们编写的代 码当中有太多的对内存使用不当的地方,难免会使得我们的设备运行缓慢,甚至是死机.为了能够使得Android应用程序安全且快速的运行,Android 的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行,它是由Zygote服务进程孵化出来的,也就是说每个应用程序都是在属于自己的进程中运行的.一方面,如果程序在运行过程中出现

android 内存溢出问题分析

最近的项目中,内存一直再增长,但是不知道是什么问题,导致内存溢出,在网上看到了这么一篇关于内存分析与管理的文章,解决了部分问题,感觉这篇文 章还不错,就转帖到我的blog上了,希望对大家有所帮助.如果哪里有不好的地方,给留下言,然后我们大家继续完善内存泄露的问题,对大家都会有所帮助 的,呵呵 一.概述 1 二.Android(Java)中常见的容易引起内存泄漏的不良代码 1 (一) 查询数据库没有关闭游标 2 (二) 构造Adapter时,没有使用缓存的 convertView 3 (三) Bi

android内存溢出问题

最近的项目中,内存一直再增长,但是不知道是什么问题,导致内存溢出,在网上看到了这么一篇关于内存分析与管理的文章,解决了部分问题,感觉这篇文章还不错,就转帖到我的blog上了,希望对大家有所帮助.如果哪里有不好的地方,给留下言,然后我们大家继续完善内存泄露的问题,对大家都会有所帮助的,呵呵 一.概述 1 二.Android(Java)中常见的容易引起内存泄漏的不良代码 1 (一) 查询数据库没有关闭游标 2 (二) 构造Adapter时,没有使用缓存的 convertView 3 (三) Bitm

Android 内存溢出解决方案(OOM)

众所周知,每个Android应用程序在运行时都有一定的内存限制,限制大小一般为16MB或24MB(视平台而定).因此在开发应用时需要特别关注自身的内存使用量,而一般最耗内存量的资源,一般是图片.音频文件.视频文件等多媒体资源:由于Android系统对音频.视频等资源做了边解析便播放的处理,使用时并不会把整个文件加载到内存中,一般不会出现内存溢出(以下简称OOM)的错误,因此它们的内存消耗问题暂不在本文的讨论范围.本文重点讨论的是图片的内存消耗问题,如果你要开发的是一款图片浏览器应用,例如像And

Android 内存溢出解决方案(OOM) 整理总结

标签:Android加载大 Android 移动开发 在最近做的工程中发现加载的图片太多或图片过大时经常出现OOM问题,找网上资料也提供了很多方法,但自己感觉有点乱,特此,今天在不同型号的三款安卓手机上做了测试,因为有效果也有结果,今天小马就做个详细的总结,以供朋友们共同交流学习,也供自己以后在解决OOM问题上有所提高,提前讲下,片幅有点长,涉及的东西太多,大家耐心看,肯定有收获的,里面的很多东西小马也是学习参考网络资料使用的,先来简单讲下下: 一般我们大家在遇到内存问题的时候常用的方式网上也有