Android避免内存泄露：合理使用getContext()和getApplication()

先作个总结：

1.getApplicationContext()可以取到Application对象，而getContext()通常认为返回Activity对象（当然，事实上并不局限于Activity）。
2.对于Application，从Manifest文件中可以看出一个应用程序一般只有一个application节点。Application其实就是一个应用，即：当前应用程序只要还处于运行状态，那么就可以取到Application对象。
3.Application是一个长引用，Activity是短引用。Application适用于存储那些需要反复读取的对象，比如用户的用户名和密码，应用程序的当前设置等。Activity适用于当前活动窗体，比如显示一个dialog，或新建一个View，传入的context对象就应该是当前Activity，而非Application。

    

 Android应用程序限制使用的堆内存是16M（注：堆内存与设备的性能也有一定关系，性能高的设备可用堆内存可能是24M或者更高），其中电话功能会占用一部分，而开发者能够使用的则非常有限。如果你不打算用完所有内存，那么你的应用就应该尽可能少用内存，从而使其他的程序在运行时不致于被杀掉。Android系统在内存中能够持有的应用程序越多，用户在程序间进行切换时就越快。作为工作的一部分，我研究Android应用中的内存泄露问题，结果发现多数情况是同一个问题引起的：对Context持有一个过长的引用。

     在Android中，Context被用在许多操作中，但多数是为了加载或访问资源。这就是为什么所有的Widget组件都会在构造器中接收一个Context参数的原因所在。对于一般的Android应用，通常有两种Context，即Activity和Application。开发者通常需要context在类或方法间传递时会选择Activity。

    这表明Views对整个Activity有一个引用，因此你的Activity中任何东西都会被（Views）持有，一般被持有的是视图层级和它对应的资源。因此，如果你泄露了Context（泄露：即你持有一个Context引用，结果阻止GC对其进行回收），你就泄露了一些内存。如果你不细心，泄露一个Activity就会变得非常容易。
    当屏幕方向改变，系统默认会保存它的状态，销毁当前Activity并重新创建一个。为了做到这一点，Android会从资源中重新加载应用程序的UI。现在假设你开发一个应用，包含了大量位图（Bitmap），你不想每次屏幕切换时都去加载位图。那么最简单的方法是利用static静态域。

    上面的代码非常简洁，但也容易出错：第一次屏幕方向改变时，最初创建的Activity（每次屏幕改变都会重新创建Activity）就会出现内存泄漏。当一个Drawable对象被附着到View中，View就会在这个Drawable上被设定作为回调callback。上面的代码片段表明drawable对TextView有一个引用，而TextView本身又对Activity（即Context）持有引用，反过来，Activity又对许多东西持有引用（这取决于你的代码）。
    上面的例子是泄露Context最简单的一种情况，你能在Home screen的源代码（查找unbindDrawables()方法）中看到我们是怎么解决它的：当Activity被销毁时，设置被存储的drawable的回调为null。有趣的是，你创建一系列内存泄露的Context会出现许多情况，并且它们都是糟糕的。它们很快使你在运行过程时出现内存溢出。
    有两种简单的方式去避免Context相关的内存泄露。最明显的一种就是避免Context超出它的范围。上面的例子展现了静态引用的情况：内部类以及对外部类的间接引用是很危险的。第二种方案是用Application。这种Context不依赖于Activity的生命周期，而是与你的应用程序同生共死。如果你打算持有一个长期活动并且需要Context引用的对象，记得使用Application对象。你可以通过调用Context.getApplicationContext() 或者 Activity.getApplication()方法得到它。
总的来说，要避免Context相关的内存泄露，铭记以下几条：

•不要对Activity（Activity继承自Context）作长期的引用（一个指向Activity的引用与Activity本身有相同的生命周期）；
•（如果使用长引用）试着用Application代替Activity；

•如果你不能控制内部类的生命周期，避免使用非静态内部类，应该用静态内部类，并且对里面的Activity作弱引用。该问题的解决方法是：对于外部类，用WeakReference构造静态内部类，同时要在视图根完成，并且它的WeakReference内部类要有一个实例（WeakReference）。

•垃圾回收不是防止内存泄露的保险方式。

原文链接：Avoiding memory leaks