Android 后台任务（八）内存泄露
Android 后台任务（七）内存泄露
翻译自：http://www.androiddesignpatterns.com/2013/04/activitys-threads-memory-leaks.html
转载请注明：http://blog.csdn.net/liaoqianchuan00/article/details/23950023
该文章以Thread为例，但是同样适用于AsyncTask
要再Activity的生命周期处理好一个长时间运行的任务而不导致内存泄露是有难度的。设想有下面的Activity代码，在一个线程中不断循环的处理一些事情。
/**
* Exampleillustrating how threads persist across configuration
* changes(which cause the underlying Activity instance to be
* destroyed).The Activity context also leaks because the thread
* isinstantiated as an anonymous class, which holds an implicit
* reference tothe outer Activity instance, therefore preventing
* it frombeing garbage collected.
*/
public class MainActivity extends Activity {
@Override
protectedvoid onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
exampleOne();
}
private voidexampleOne() {
newThread() {
@Override
publicvoid run() {
while(true) {
SystemClock.sleep(1000);
}
}
}.start();
}
}
当configuration 变化的时候（比如转屏），整个Activity被销毁并且被重新创建，我们可能认为Android会释放掉和之前Activity相关的内存和他里面的线程。但是，事实上不是这样的。在这个例子中，这两个都会导致泄露，并且再也不会被回收了。
Activity Leak是如何发生的
如果你读了我之前的文章，第一个内存泄露问题可以很快就被发现。在Java里面，非静态的匿名内部类保持了一个对outer class的引用。如果你不够小心，持有了这个引用，那么将导致这个Activity一直保留（本应该被垃圾回收器回收）。Activity对象保持了对整个View结构和所有这些Resources的引用，所以你LeakActivity，也就Leak了很多的内存。
在configuration不断变化的时候，即不断的销毁，再创建Activity的时候。比如，运行上面的代码，在旋转了10次屏幕之后，我们可以看见（使用Eclipse Memory Analyzer）每个Activity对象事实上都保存在内存中没有被释放掉:
在每次转屏后，Android系统创建一个新的Activity，然后老的Activity又没有被垃圾回收器回收（因为线程中保持了一个对Activity的引用）。结果就造成Activity泄漏，所有和Activity相关的资源都不会被释放掉。
要解决这个问题，我们可以声明线程为私有的静态内部类。
public class MainActivity extends Activity {
@Override
protectedvoid onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
exampleTwo();
}
private voidexampleTwo() {
newMyThread().start();
}
privatestatic class MyThread extends Thread {
@Override
public voidrun() {
while(true) {
SystemClock.sleep(1000);
}
}
}
}
Thread Leak是如何发生的
第二个问题就是每个新的Activity都创建了一个线程，并且这些线程永远不会呗回收掉。在Java里线程位于GC的roots，而Dalvik Virtual Machine（DVM）保持对系统中所有活动线程的引用，这就导致这些一直活动的线程永远不会被回收。对于这种情况，你需要记住的就是适当的时候取消线程的运行！下面的例子讲解了怎么来做：
/**
* Same asexample two, except for this time we have implemented a
* cancellationpolicy for our thread, ensuring that it is never
* leaked!onDestroy() is usually a good place to close your active
* threadsbefore exiting the Activity.
*/
public class MainActivity extends Activity {
privateMyThread mThread;
@Override
protectedvoid onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
exampleThree();
}
private voidexampleThree() {
mThread =new MyThread();
mThread.start();
}
/**
* Staticinner classes don't hold implicit references to their
* enclosingclass, so the Activity instance won't be leaked across
*configuration changes.
*/
privatestatic class MyThread extends Thread {
privateboolean mRunning = false;
@Override
public voidrun() {
mRunning= true;
while (mRunning) {
SystemClock.sleep(1000);
}
}
public voidclose() {
mRunning= false;
}
}
@Override
protectedvoid onDestroy() {
super.onDestroy();
mThread.close();
}
}
在上面的代码中，在Activity的onDestroy里面关闭线程，这样就不会导致Thread Leak了。如果你想在转屏的时候保持住一个线程（而不用关闭掉之前的线程再重新创建一个），考虑使用retained。可以查看这篇文章。
总结：
这里总结了一些要点来防止处理耗时操作的时候导致内存泄露。
1. 多使用静态内部类而不是非静态的。每个非静态内部类都保持了一个对outer Activity实例的引用。这个引用可能导致Activity不被垃圾回收器回收。如果你的静态内部类需要引用一个Activity，那么你可以使用WeakReference来保证这个Activity不会泄露。
2. 不要认为Java会为你清理runningthread。在上面的例子中，我们会很容易的就想象当用户离开这个Activity的时候，Activity实例会被垃圾回收器回收，所有在这个Activity中开启的running thread也会被清理掉。事实上不是这样的。Java线程将会一直存在，直到他们被显示的关闭或者处理结束，或者被杀掉整个进程。所以，你需要完成可被取消的线程机制，在Activity的生命周期的某个地方做适当的处理。
3. 考虑你是否需要使用Thread。Android应用程序框架提供了很多类来处理后台线程。比如，考虑使用Loader替代Thread来处理短时间的异步任务。同时，如果后台线程并没有和Activity有紧密的联系，可以考虑使用Service，用BroadcastReceiver来更新UI。最后，这篇文章讨论的所有关于Thread的问题，也同样会发生在AsyncTask上面。但是，假设AsyncTask只使用在一些短时间的任务上（只有几秒），Activity或者Thread的Leak将不会是很大的问题。因为最终在这个Thread处理完任务之后，Activity和Thread都会被释放掉。