android避免内存泄露（原因+解决）

1、   数据库的cursor没有关闭
2、 构造adapter没有使用缓存contentview
   衍生的listview优化问题：减少创建View的对象，充分使用contentview，可以使用静态类来处理优化getView的过程
3、Bitmap对象不使用时采用recycle()释放内存
4、Activity中的对象生命周期大于Activity
调式方法：DDMS->HEAPSIZE->adtaobject->total size
 
 
Android应用程序被限制在16MB的堆上运行，至少在T-Mobile G1上是这样。对于手机来说，这是很大的内存了；但对于一些开发人员来说，这算是较小的了。即使你不打算使用掉所有的内存，但是，你也应该尽可能少地使用内存，来确保其它应用程序得以运行。Android在内存中保留更多的应用程序，对于用户来说，程序间切换就能更快。作为我（英文作者）工作的一部分，我调查了Android应用程序的内存泄露问题，并发现这些内存泄露大多数都是由于相同的错误导致的，即：对Context拥有较长时间的引用。

在Android上，Context常用于许多操作，更多的时候是加载和访问资源。这就是为什么所有的Widget在它们的构造函数里接受一个Context的参数。在一个正常的Android应用程序里，你会看到两种Context类型，Activity和Application。而一般在需要一个Context的类和方法里，往往传入的是第一种：
Java代码 
@Override   
   
protected void onCreate(Bundle state) {   
   
  super.onCreate(state);   
   
    
   
  TextView label = new TextView(this);   
   
  label.setText("Leaks are bad");   
   
    
   
  setContentView(label);   
   
}   
 
这意味着，View拥有对整个Activity的引用以及Activity自身拥有的所有内容；一般是整个的View层次和它的所有资源。因此，如果你“泄露”了Context（“泄露”指你保留了一个引用，阻止了GC的垃圾回收），你将泄露很多的内存。如果你不够仔细的话，很容易就能泄露一个Activity。

当屏幕的方向发生改变时，一般系统会销毁当前的Activity并创建一个新的，并保存它的状态。当系统这样做时，Android会从资源中重新加载应用程序的UI。假设你写的应用程序拥有大的位图，而你又不想在每次旋转时重新加载它。这里有最简单的方式，那就是在一个静态的字段里进行保存：
Java代码 
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拥有了更多的对象引用（依赖于你的代码）。

这是最容易泄露Context的例子之一，你可以看看Home Screen源代码里是如何处理的（搜索unbindDrawables()方法）：当Activity销毁时，设定存储的Drawable的callback为null。有趣的是，还有很多一连串的Context泄露情况，并且是非常糟糕的。这些情况会使得应用程序很快耗尽内存。

这里，有两种简单的方式可以避免与Context相关的内存泄露。最显而易见的一种方式是避免将Context超出它自己的范围。上面的例子代码给出的静态引用，还有内部类和它们对外部类的隐式引用也是很危险的。第二种解决方案是使用Application这种Context类型。这种Context拥有和应用程序一样长的生命周期，并且不依赖Activity的生命周期。如果你打算保存一个长时间的对象，并且其需要一个Context，记得使用Application对象。你可以通过调用Context.getApplicationContext()或Activity.getApplication()轻松得到Application对象。

概括一下，避免Context相关的内存泄露，记住以下事情：

   不要保留对Context-Activity长时间的引用（对Activity的引用的时候，必须确保拥有和Activity一样的生命周期）

   尝试使用Context-Application来替代Context-Activity

   如果你不想控制内部类的生命周期，应避免在Activity中使用非静态的内部类，而应该使用静态的内部类，并在其中创建一个对Activity的弱引用。这种情况的解决办法是使用一个静态的内部类，其中拥有对外部类的WeakReference，如同ViewRoot和它的Winner类那样

   GC（垃圾回收）不能解决内存泄露问题

 

-------------------------------------预防android内存泄露的方法-----------------------------------

对于很多处理图形相关的Android开发者来说，大的Bitmap对象可能直接导致软件崩溃，Android平台如何防止内存泄露呢? 目前来说Android设备的RAM可能差距比较大，很多低端配置的256MB RAM或512MB RAM由于运行了太多的后台任务或htc Sense这样的主题导致了处理一些高像素的图片，比如500w或800w像素的照片很容易崩溃。

1. 判断目标设备Dalvik VM内存情况 通过 Java.lang.Runtime类的 long freeMemory() 方法可以获取当前进程的RAM可用情况，Runtime类需要 getRuntime() 方法来实例化。 比如获取最大可用RAM 为 Runtime.getRuntime().maxMemory();

 2. Bitmap对象在打开时可以考虑先缩小图片 通过减少工作区域可以有效的降低RAM使用，由于在内存中是DIB方式，可以想象ARGB的图像占用内存为 4*height*width，比如500万像素的图片，占用内存就是500x4=2000万字节就是19MB左右。同时Java VM的异常处理机制和绘图方法可能在内部产生副本，最终消耗的运行内存是十分庞大的，对于图片打开时就进行缩小可以使用 android.graphics.BitmapFactory的相关方法来处理，这里参考Android123早期文章，Android缩略图类源代码 即可

3. 及时的显示执行Bitmap的recycle方法，以及是当时可以调用Runtime的gc方法，提示虚拟机尽快释放掉内存

 

转载于:https://www.cnblogs.com/xiangtongpeng/archive/2011/12/25/2300786.html