Android下常见的内存泄漏

因为Android使用Java作为开发语言，很多人在使用会不注意内存的问题。
于是有时遇到程序运行时不断消耗内存，最终导致OutOfMemery，程序异常退出，这就是内存泄露(“泄露”指你保留了一个引用，阻止了GC的垃圾回收)导致的。
我们现在就来总结一下可能导致内存泄露的情况：

1、查询数据库而没有关闭Cursor
在Android中，Cursor是很常用的一个对象，但在写代码是，经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。
通常，在Activity中，我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。
但需要注意的是，当Activity结束后，Cursor将不再可用！
若操作Cursor的代码和UI不同步（如后台线程），那没需要先判断Activity是否已经结束，或者在调用OnDestroy前，先等待后台线程结束。

除此之外，以下也是比较常见的Cursor不会被关闭的情况：

try {    Cursor c = queryCursor();      int a = c.getInt(1);      ......      c.close();      } catch (Exception e) {   }

虽然表面看起来，Cursor.close()已经被调用，但若出现异常，将会跳过close()，从而导致内存泄露。
所以，我们的代码应该以如下的方式编写：

Cursor c = queryCursor();  try {          int a = c.getInt(1);      ......      } catch (Exception e) {     ...    } finally {      c.close(); //在finally中调用close(), 保证其一定会被调用 } 

2、调用registerReceiver后未调用unregisterReceiver().
在调用registerReceiver后，若未调用unregisterReceiver，其所占的内存是相当大的。
而我们经常可以看到类似于如下的代码：

registerReceiver(new BroadcastReceiver(){         ...      }, filter); 

这是个很严重的错误，因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。

3、未关闭InputStream/OutputStream

在使用文件或者访问网络资源时，使用了InputStream/OutputStream也会导致内存泄露

4、Bitmap使用后未调用recycle()

根据SDK的描述，调用recycle并不是必须的。但在实际使用时，Bitmap占用的内存是很大的，所以当我们不再使用时，尽量调用recycle()以释放资源。Bitmap对象在不使用时,我们应该先调用recycle()，然后才它设置为null。

5、 构造adapter没有使用缓存contentview
   衍生的listview优化问题：减少创建View的对象，充分使用contentview，可以使用静态类来处理优化getView的过程

6、Activity中的对象生命周期大于Activity（Context泄露）
这是一个很隐晦的内存泄露的情况。
先让我们看一下以下代码：

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);  } 

        在这段代码中，我们使用了一个static的Drawable对象。这通常发生在我们需要经常调用一个Drawable，而其加载又比较耗时，不希望每次加载Activity都去创建这个Drawable的情况。此时，使用static无疑是最快的代码编写方式，但是其也非常的糟糕。当一个Drawable被附加到View时，这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。这就意味着，这个Drawable拥有一个TextView的引用，而TextView又拥有一个Activity的引用，这就会导致Activity在销毁后，内存不会被释放。

外文译文表述：

        这段代码效率很快，但同时又是极其错误的；在第一次屏幕方向切换时它泄露了一开始创建的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相关的内存泄露，记住以下事情：
  1、 不要保留对Context-Activity长时间的引用（对Activity的引用的时候，必须确保拥有和Activity一样的生命周期）
  2、尝试使用Context-Application来替代Context-Activity
  3、 如果你不想控制内部类的生命周期，应避免在Activity中使用非静态的内部类，而应该使用静态的内部类，并在其中创建一个对Activity的弱引用。这种情况的解决办法是使用一个静态的内部类，其中拥有对外部类的WeakReference，如同ViewRoot和它的Winner类那样。

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