Avoiding Memory Leaks

        我们大家都知道Android应用程序被限制在16MB的堆上运行，至少在T-Mobile G1上是这样。对于手机来说，这是很大的内存了；但对于一些开发人员来说，这算是较小的了。即使我们不打算使用掉所有的内存，但是，我们也应该尽可能少地使用内存，来确保其它应用程序得以运行。Android在内存中保留更多的应用程序，对于用户来说，程序间切换就能更快。我们调查了Android应用程序的内存泄露问题，并发现这些内存泄露大多数都是由于相同的错误导致的，即：对Context拥有较长时间的引用。

        在Android上，Context常用于许多操作，更多的时候是加载和访问资源。这就是为什么所有的Widget在它们的构造函数里接受一个Context的参数。在一个正常的Android应用程序里，我们会看到两种Context类型，Activity和Application。而一般在需要一个Context的类和方法里，往往传入的是第一种：

@Overrideprotected 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。假设我们写的应用程序拥有大的位图，而我们又不想在每次旋转时重新加载它。这里有最简单的方式，那就是在一个静态的字段里进行保存：

private static Drawable sBackground;
@Overrideprotected 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);
}

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

In summary, to avoid context-related memory leaks, remember the following:

• Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself)
• Try using the context-application instead of a context-activity
• Avoid non-static inner classes in an activity if you don't control their life cycle, use a static inner class and make a weak reference to the activity inside. The solution to this issue is to use a static inner class with a WeakReference to the outer class, as done in ViewRoot and its W inner class for instance
• A garbage collector is not an insurance against memory leaks

     不要保留对Context-Activity长时间的引用（对Activity的引用的时候，必须确保拥有和Activity一样的生命周期）  
     尝试使用Context-Application来替代Context-Activity  
     如果你不想控制内部类的生命周期，应避免在Activity中使用非静态的内部类，而应该使用静态的内部类，并在其中创建一个对Activity的弱引用。这种情况的解决办法是使用一个静态的内部类，其中拥有对外部类的WeakReference，如同ViewRoot和它的Winner类那样  
     GC（垃圾回收）不能解决内存泄露问题

常见的内存泄露的

1.数据库没有关闭Cursor

try {
    Cursor c = queryCursor();
    int a = c.getInt(1);
    ......
    c.close();
} catch (Exception e) {
}
//虽然表面看起来，Cursor.close()已经被调用，但若出现异常，将会跳过close()，
//从而导致内存泄露

应加修改为finally {     c.close();   }  

2.调用registerReceiver后未调用unregisterReceiver()

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

registerReceiver(new BroadcastReceiver() {
    ...
}, filter); ...  //这是个很严重的错误，因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。

 3.未关闭InputStream/OutputStream

4. 构造adapter没有使用缓存contentview

 衍生的listview优化问题：减少创建View的对象，充分使用contentview，可以使用静态类来处理优化getView的过程

5. Bitmap对象不使用时采用recycle()释放内存

6. Activity中的对象生命周期大于Activity