Android 之 内存管理

概述

在android的开发中，要时刻主要内存的分配和垃圾回收，因为系统为每一个dalvik虚拟机分配的内存是有限的，在google的G1中，分配的最大堆大小只有16M，后来的机器一般都为24M，实在是少的可怜。这样就需要我们在开发过程中要时刻注意。不要因为自己的代码问题而造成OOM错误。

JAVA的内存管理

大家都知道，android应用层是由java开发的，android的davlik虚拟机与jvm也类似，只不过它是基于寄存器的。因此要了解android的内存管理就必须得了解java的内存分配和垃圾回收机制。

在java中，是通过new关键字来为对象分配内存的，而内存的释放是由垃圾收集器（GC）来回收的，工程师在开发的过程中，不需要显式的去管理内存。但是这样有可能在不知不觉中就会浪费了很多内存，最终导致java虚拟机花费很多时间去进行垃圾回收，更严重的是造成JVM的OOM。因此，java工程师还是有必要了解JAVA的内存分配和垃圾回收机制。

1. 内存结构

上面这张图是JVM的结构图，它主要四个部分组成：Class Loader子系统和执行引擎，运行时方法区和本地方法区，我们主要来看下RUNTIME DATA AREA区，也就是我们常说的JVM内存。从图中可以看出，RUNTIMEDATA AREA区主要由5个部分组成：

• Method Area:被装载的class的元信息存储在Method Area中，它是线程共享的
• Heap(堆)：一个java虚拟机实例中只存在一个堆空间，存放一些对象信息，它是线程共享的
• Java栈： java虚拟机直接对java栈进行两种操作，以帧为单位的压栈和出栈（非线程共享）
• 程序计数器（非线程共享）
• 本地方法栈（非线程共享）

2. JVM的垃圾回收（GC）

JVM的垃圾原理是这样的，它把对象分为年轻代（Young）、年老代（Tenured）、持久代（Perm），对不同生命周期的对象使用不同的垃圾回收算法。

• 年轻代(Young)

年轻代分为三个区，一个eden区，两个Survivor区。程序中生成的大部分新的对象都在Eden区中，当Eden区满时，还存活的对象将被复制到其中一个Survivor区，当此Survivor区的对象占用空间满了时，此区存活的对象又被复制到另外一个Survivor区，当这个Survivor区也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制到年老代。

• 年老代（Tenured）

年老代存放的是上面年轻代复制过来的对象，也就是在年轻代中还存活的对象，并且区满了复制过来的。一般来说，年老代中的对象生命周期都比较长。

• 持久代（Perm）

用于存放静态的类和方法，持久代对垃圾回收没有显著的影响。

Android中内存泄露监测

在了解了JVM的内存管理后，我们再回过头来看看，在android中应该怎样来监测内存，从而看在应用中是否存在内存分配和垃圾回收问题而造成内存泄露情况。

在android中，有一个相对来说还不错的工具，可以用来监测内存是否存在泄露情况：DDMS—Heap

使用方法比较简单：

• 选择DDMS视图，并打开Devices视图和Heap视图
• 点击选择要监控的进程，比如：上图中我选择的是system_process
• 选中Devices视图界面上的"update heap" 图标
• 点击Heap视图中的"Cause GC" 按钮（相当于向虚拟机发送了一次GC请求的操作）

在Heap视图中选择想要监控的Type，一般我们会观察dataobject的 total size的变化，正常情况下total size的值会稳定在一个有限的范围内，也就说程序中的代码良好，没有造成程序中的对象不被回收的情况。如果代码中存在没有释放对象引用的情况，那么data object的total size在每次GC之后都不会有明显的回落，随着操作次数的增加而total size也在不断的增加。（说明：选择好data object后，不断的操作应用，这样才可以看出total size的变化）。如果totalsize确实是在不断增加而没有回落，说明程序中有没有被释放的资源引用。那么我们应该怎么来定位呢？

Android中内存泄露定位

Mat(memory analyzer tools)是我们常用的用来定位内存泄露的工具，如果你使用ADT，并且安装了MAT的eclipse插件，你需要做的是进入DDMS视图的Devices视图：

点击"dump HPROF file"按钮，然后使用MAT分析下载下来的文件。

 

下面列出了存在的问题，点击detail进去，会列出详细的，可能会存在问题的代码：

 

关于MAT的使用可以参考：http://www.blogjava.net/rosen/archive/2010/06/13/323522.html

这位兄弟写的比较详细。

总结

不管是java还是android，都应该了解内存分配和垃圾回收机制，工程师要做到写的代码中没有bad code很难，关键是在出现问题的时候该怎么去排查。

避免Android内存泄露

Android的应用被限制为最多占用16m的内存，至少在T-Mobile G1上是这样的（当然现在已经有几百兆的内存可以用了——译者注）。它包括电话本身占用的和开发者可以使用的两部分。即使你没有占用全部内存的打算，你也应该尽量少的使用内存，以免别的应用在运行的时候关闭你的应用。Android能在内存中保持的应用越多，用户在切换应用的时候就越快。作为我的一项工作，我仔细研究了Android应用的内存泄露问题，大多数情况下它们是由同一个错误引起的，那就是对一个上下文（Context）保持了长时间的引用。

在Android中，上下文（Context）被用作很多操作中，但是大部分是载入和访问资源。这就是所有的widget都会在它们的构造函数中接受一个上下文（Context）参数。在一个合格的Android应用中，你通常能够用到两种上下文（Context）：活动（Activity）和应用（Application）。活动（Activity）通常被传递给需要上下文（Context）参数的类或者方法：

Source code

[java] view plaincopy

1. <ol><li class="li1 odd"><div class="de1">@Override</div></li><li class="li1 even"><div class="de1"><span class="kw1">protected</span> <span class="kw4">void</span> onCreate<span class="br0">(</span>Bundle state<span class="br0">)</span> <span class="br0">{</span></div></li><li class="li1 odd"><div class="de1">  <span class="kw1">super</span>.<span class="me1">onCreate</span><span class="br0">(</span>state<span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 even"><div class="de1"> </div></li><li class="li1 odd"><div class="de1">  TextView label <span class="sy0">=</span> <span class="kw1">new</span> TextView<span class="br0">(</span><span class="kw1">this</span><span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 even"><div class="de1">  label.<span class="me1">setText</span><span class="br0">(</span><span class="st0">"Leaks are bad"</span><span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 odd"><div class="de1"> </div></li><li class="li1 even"><div class="de1">  setContentView<span class="br0">(</span>label<span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 odd"><div class="de1"><span class="br0">}</span></div></li></ol>  

这就意味着那个View有一个对整个活动（Activity）的引用并且对这个活动（Activity）中保持的所有对象有保持了引用；通常它们包括整个View的层次和它的所有资源。因此，如果你“泄露”了上下文（Context）（这里“泄露”的意思是你保持了一个引用并且组织GC收集它），你将造成大量的内存泄露。如果你不够小心的话，“泄露”一整个活动（Activity）是件非常简单的事情。

当屏幕的方向改变时系统会默认的销毁当前的活动（Activity）并且创建一个新的并且保持了它的状态。这样的结果就是Android会从资源中重新载入应用的UI。现在想象一下，你写了一个应用，有一个非常大的位图，并且你并不想在每次旋转时都重新载入。保留它并且每次旋转不重新加载的最简单的办法就是把它保存在一个静态字段上：

Source code

[java] view plaincopy

1. <ol><li class="li1 odd"><div class="de1"><span class="kw1">private</span> <span class="kw1">static</span> Drawable sBackground<span class="sy0">;</span></div></li><li class="li1 even"><div class="de1"> </div></li><li class="li1 odd"><div class="de1">@Override</div></li><li class="li1 even"><div class="de1"><span class="kw1">protected</span> <span class="kw4">void</span> onCreate<span class="br0">(</span>Bundle state<span class="br0">)</span> <span class="br0">{</span></div></li><li class="li1 odd"><div class="de1">  <span class="kw1">super</span>.<span class="me1">onCreate</span><span class="br0">(</span>state<span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 even"><div class="de1"> </div></li><li class="li1 odd"><div class="de1">  TextView label <span class="sy0">=</span> <span class="kw1">new</span> TextView<span class="br0">(</span><span class="kw1">this</span><span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 even"><div class="de1">  label.<span class="me1">setText</span><span class="br0">(</span><span class="st0">"Leaks are bad"</span><span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 odd"><div class="de1"> </div></li><li class="li1 even"><div class="de1">  <span class="kw1">if</span> <span class="br0">(</span>sBackground <span class="sy0">==</span> <span class="kw2">null</span><span class="br0">)</span> <span class="br0">{</span></div></li><li class="li1 odd"><div class="de1">    sBackground <span class="sy0">=</span> getDrawable<span class="br0">(</span>R.<span class="me1">drawable</span>.<span class="me1">large_bitmap</span><span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 even"><div class="de1">  <span class="br0">}</span></div></li><li class="li1 odd"><div class="de1">  label.<span class="me1">setBackgroundDrawable</span><span class="br0">(</span>sBackground<span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 even"><div class="de1"> </div></li><li class="li1 odd"><div class="de1">  setContentView<span class="br0">(</span>label<span class="br0">)</span><span class="sy0">;</span></div></li><li class="li1 even"><div class="de1"><span class="br0">}</span></div></li></ol>  

这段代码非常快，同时也错的够离谱。它泄露了当第一次屏幕角度改变时创建的第一个活动（Activity）。当一个Drawable被附加到一个View，这个View被设置为drawable的一个回调。在上面的代码片断中，这意味着这个Drawable对TextView有一个引用，同时这个TextView对Activity（Context对象）保持着引用，同时这个Activity对很多对象又有引用（这个多少还要看你的代码了）。

这个例子是造成Context泄露的最简单的一个原因，你可以看一下我们在主屏幕源码（查看unbindDrawables()方法）中是通过在Activity销毁时设置保存过的Drawable的回调为空来解决这个问题的。更为有趣的是，你可以创建一个context泄露的链，当然这非常的糟糕。它们可以让你飞快的用光所有的内存。

有两种简单的方法可以避免与context相关的内存泄露。最明显的一个就是避免在context的自身的范围外使用它。上面的例子展示了在类内部的一个静态的引用和它们对外部类的间接引用是非常危险的。第二个解决方案就是使用Application Context。这个context会伴随你的应用而存在，并且不依赖Activity的的生命周期。如果你计划保持一个需要context的长生命周期的对象，请记得考虑Application对象。你可以非常方便的通过调用Context.getApplicationContext() 或者 Activity.getApplication()获取它。

总之，为了避免涉及到context的内存泄露，请记住如下几点：

1. 不要对一个Activity Context保持长生命周期的引用（一个对Activity的引用应该与Activity自身的生命周期相同）
2. 尝试使用应用上下文（context-application）代替活动上下文（context-activity）
3. 如果你不能控制它们的生命周期，在活动（Activity）中避免使用不是静态的内部类，使用静态类并且使用弱引用到活动（Activity）的内部。对于这个问题的解决方法是使用静态的内部类与一个弱引用（WeakReference）的外部类。就像ViewRoot和它的W内部类那么实现的。
4. 垃圾回收器对于内存泄露来说并不是百分百保险的。

原文地址：Avoiding memory leaks

本文出自:http://blog.csdn.net/xyz_lmn/article/details/7108011

1、   数据库的cursor没有关闭
2、 构造adapter没有使用缓存contentview
   衍生的listview优化问题：减少创建View的对象，充分使用contentview，可以使用静态类来处理优化getView的过程
3、Bitmap对象不使用时采用recycle()释放内存
4、Activity中的对象生命周期大于Activity
调式方法：DDMS->HEAPSIZE->adtaobject->total size
 
 
Android应用程序被限制在16MB的堆上运行，至少在T-MobileG1上是这样。对于手机来说，这是很大的内存了；但对于一些开发人员来说，这算是较小的了。即使你不打算使用掉所有的内存，但是，你也应该尽可能少地使用内存，来确保其它应用程序得以运行。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的例子之一，你可以看看HomeScreen源代码里是如何处理的（搜索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（垃圾回收）不能解决内存泄露问题