原谅地址：http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html ,英文原文在翻译之后
Android 应用至少，在T-Mobile G1这个型号，就有16MB的堆内存。这个容量对于手机来说是很大了，但是对于有些开发者来说是少了些。为了全其他应用可以运行而不被系统杀掉，即使你没有打算使用完所有分配的容量，你也应该尽量少地使用这些容量。
Android能保存越多的应用，用户在切换应用的时候就会越快。我在工作中，遇到了内存泄露，它们出现的原因很多时候是因为同一个错误：保存Context持有一个生命周期很长的引用
安卓开发中，Context在很多操作中都需要，它大部分是用来加载和操作应用资源(resources). 这也是为什么一些组件会在它们的构造函数里接收一个Context参数。一般在一个安卓应用中，通常有两个种Context：Activity 和 Application. 通常大家都是把第一个Context(Activity)传给需要这个参数的方法和类：代码如下
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
setContentView(label);
}
这意味着这些视图(Views)对这整个Activity持有一个引用，因此也对这个Activity所持有的对象持有引用。这些对象通常是整个View的hierachy和它们所使用的资源(resources)。因此，一旦你的Context有内存泄露(leak:意思是你对Context引用着，导致它不能给GC回收)，意思着你会泄露很多的内存。如果你不小心，Activity的内存泄露是很容易出现的。
当屏幕的方向(orientation)改变，系统默认地，会销毁当前的activity, 然后保存状态(state)的时候，创建一个新的activity。在做这个的时候，安卓会从资源(resources)中重新加载UI。在这样做的时候，Android会重新从资源(resources)里加载UI。想像一下，你在写一个应用，有一张很大的图片(bitmap)，你不想在任何旋转操作的时候加载。 那么想要在任何旋转时，保存它，不重新加载的最简单方法就是把它声明成‘静态成员变量‘(static field):代码如下
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);
//这个代码的情况就是，TextView持有一个Activity的Context的引用，然后又因为它持有一个静态变量Drawable的引用，导致这个TextView与类的生命周期相同，从而导致Activity的Context也被长期持有，导致这个activity被人引用着而不能被GC回收
setContentView(label);
}
这份代码运行会很快，但是也是错误的。 它会泄露第一个在屏幕旋转时创建的activity。当一个Drawable对象被分配到一个view上的时候， 这个view会被设成这个drawable的回调(callback)。在上面的代码片中，这意味着drawable对象持有TextView的引用，而TextView又因为context的原因持有Activity的引用，也因此持有很多其它的引用，具体看你代码的情况。
这份代码是Context导致内存泄露的其中一个最简单的例子。
Android applications are, at least on the T-Mobile G1, limited to 16 MB of heap. It‘s both a lot of memory for a phone and yet very little for what some developers want to achieve. Even if you do not plan on using all of this memory, you should use as little as possible to let other applications run without getting them killed. The more applications Android can keep in memory, the faster it will be for the user to switch between his apps. As part of my job, I ran into memory leaks issues in Android applications and they are most of the time due to the same mistake: keeping a long-lived reference to a Context.
On Android, a Context is used for many operations but mostly to load and access resources. This is why all the widgets receive a Context parameter in their constructor. In a regular Android application, you usually have two kinds of Context, Activity andApplication. It‘s usually the first one that the developer passes to classes and methods that need a Context:
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
setContentView(label);
}
This means that views have a reference to the entire activity and therefore to anything your activity is holding onto; usually the entire View hierarchy and all its resources. Therefore, if you leak the Context ("leak" meaning you keep a reference to it thus preventing the GC from collecting it), you leak a lot of memory. Leaking an entire activity can be really easy if you‘re not careful.
When the screen orientation changes the system will, by default, destroy the current activity and create a new one while preserving its state. In doing so, Android will reload the application‘s UI from the resources. Now imagine you wrote an application with a large bitmap that you don‘t want to load on every rotation. The easiest way to keep it around and not having to reload it on every rotation is to keep in a static field:
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);
}
This code is very fast and also very wrong; it leaks the first activity created upon the first screen orientation change. When aDrawable is attached to a view, the view is set as a callback on the drawable. In the code snippet above, this means the drawable has a reference to the TextView which itself has a reference to the activity (the Context) which in turns has references to pretty much anything (depending on your code.)
This example is one of the simplest cases of leaking the Context and you can see how we worked around it in the Home screen‘s source code (look for the unbindDrawables() method) by setting the stored drawables‘ callbacks to null when the activity is destroyed. Interestingly enough, there are cases where you can create a chain of leaked contexts, and they are bad. They make you run out of memory rather quickly.
There are two easy ways to avoid context-related memory leaks. The most obvious one is to avoid escaping the context outside of its own scope. The example above showed the case of a static reference but inner classes and their implicit reference to the outer class can be equally dangerous. The second solution is to use the Application context. This context will live as long as your application is alive and does not depend on the activities life cycle. If you plan on keeping long-lived objects that need a context, remember the application object. You can obtain it easily by callingContext.getApplicationContext() or Activity.getApplication().
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 WeakReferenceto the outer class, as done in ViewRoot and its W inner class for instance
- A garbage collector is not an insurance against memory leaks