什么叫内存泄漏呢？
gc没有办法回收activity的内存。
那什么情况下会GC呢？
- 屏幕旋转的时候
- 内存不够用的时候。
什么情况会发生内存泄漏呢？
静态资源问题
静态变量在整个应用的内存里只保存一份，一旦创建就不会释放该变量的内存，直到整个应用都销毁才会释放static静态变量的内存.
例子：
public class MyCustomResource {
//静态变量drawable
private static Drawable drawable;
private View view；
public MyCustomResource(Context context) {
Resources resources = context.getResources();
drawable = resources.getDrawable(R.drawable.ic_launcher);
view = new View(context);
view.setBackgroundDrawable(drawable);
}
}
//查看setBackgroundDrawable的源代码：
public void setBackgroundDrawable(Drawable background) {
..........
/**此处的this就是当前View对象，而View对象又是有Context对象获得 因此，变量background持有View对象的引用，View持有Context的引用， 所有background间接持有Context对象的引用了*/
background.setCallback(this);
.......
}
分析：
此处的background.setCallback(this);的this是当前的view的对象。由于background是一个静态变量，会一直持有View对象的引用，而然View对象又是由Context对象创建出来的，因此background会间接持有Context的对象的引用。
所以：
该Context对应的Activity退出finish掉的时候其实该Activity是不能完全释放内存的。
值得注意的是：
代码是由于静态资源drawable持有View对象的引用导致内存泄漏隐患的，并不是由于context.getResource导致内存泄漏，因此如果你想通过context.getApplicaitonContext来获取getResource是解决不了内存泄漏的.
另外提一点：（使用getApplicaitonContext的错误）
android.app.Application cannot be cast to android.app.Activity
因此：在android 3.0 中：
修改了setBackgroundDrawable内部方法中的 background.setCallback(this);方法。里面的实现使用了弱引用来持有View对象的引用，从而避免了内存泄漏隐患。
总结：以后代码中避免使用静态资源，或者使用弱引用来解决相应的问题也是可以的。
单例模式导致内存泄漏（单例中的类是静态的，引用context将导致以上的问题）
public class CustomManager {
private static CustomManager sInstance;
public static CustomManager getInstance(Context context) {
if (sInstance == null) {
sInstance = new CustomManager(context);//使用context的引用。
}
return sInstance;
}
private Context mContext;
private CustomManager(Context context) {
mContext = context;
}
}
单例模式使用的是静态类的方式，让该对象在整个应用的内存中保持一份该对象，从而减少对多次创建对象带来的资源浪费。
同样的问题：
在创建该单例的时候使用了生命周期端的Context对象的引用，如果你是在Application中创建以上单例的话是木有任何问题的。因为Application的Context生命周期是整个应用，和单例的生命周期一样，因此不会导致内存泄漏。但是，如果你是在Activity中创建以上单例的话，将一样导致跟上一个一样的内存问题。
所以讲以上的代码改成：
if (sInstance == null) {
sInstance = new CustomManager(context.getApplicationContext()); }//注意这里的不同。
return sInstance;
以上全摘自：Android Context 是什么？
通过上面大家可能对Context比较模糊。请阅读：Android Context 是什么？。
记录几点：
- getApplication和getApplicationContext返回同一个
Application对象，只是里面方法调用的成员返回不同。 - 所有Context都是在应用的主线程ActivityThread中创建的
- 尽量少用Context对象去获取静态变量，静态方法，以及单例对象。以免导致内存泄漏
- 在创建与UI相关的地方，比如创建一个Dialog，或者在代码中创建一个TextView，都用Activity的Context去创建。然而在引用静态资源，创建静态方法，单例模式等情况下，使用生命周期更长的Application的Context才不会导致内存泄漏
内部类Handler类引起内存泄漏
在Activity中定义了一个内部Handler类：
public class MainActivity extends Activity {
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
//TODO handle message...
}
};
@TargetApi(11)
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler.sendMessageDelayed(Message.obtain(), 60000);//延迟一分钟执行
//just finish this activity
finish();//关闭activity
}
}
以上代码将会导致内存泄漏的问题（原因）:
- 在Java中，非静态(匿名)内部类会引用外部类对象。而静态内部类不会引用外部类对象。
当Activity finish后，延时消息会继续存在主线程消息队列中1分钟，然后处理消息。而该消息引用了Activity的Handler对象，然后这个Handler又引用了这个Activity（从以上原因可知道）。这些引用对象会保持到该消息被处理完，这样就导致该Activity对象无法被回收，从而导致了上面说的 Activity泄露。
修改：将Handler改为静态类，并使用WeakReference来保持外部的activity对象。
private Handler mHandler = new MyHandler(this);
private static class MyHandler extends Handler{
private final WeakReference<Activity> mActivity;
public MyHandler(Activity activity) {
mActivity = new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
System.out.println(msg);
if(mActivity.get() == null) {
return;
}
}
}
结论：当你在Activity中使用内部类的时候，需要时刻考虑您是否可以控制该内部类的生命周期，如果不可以，则最好定义为静态内部类。
以上摘自：内部Handler类引起内存泄露
另一种解决的方式：
在activty的onDestroy方法对handler的取消：
public void onDestroy() {
mHandler.removeMessages(MESSAGE_1);
mHandler.removeMessages(MESSAGE_2);
mHandler.removeMessages(MESSAGE_3);
mHandler.removeMessages(MESSAGE_4);
// ... ...
mHandler.removeCallbacks(mRunnable);
// ... ...
}
或者：
public void onDestroy() {
mHandler.removeCallbacksAndMessages(null);
}
Thread对象
同上：Thread的生命周期不一定是和Activity生命周期一致。
同上的解决方式为：
- 改为静态内部类
- 采用弱引用来保存
Context引用
正确的使用为：
public class ThreadAvoidActivity extends Activity {
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new MyThread(this).start();
}
private void dosomthing() {//dosomthing是ThreadAvoidActivity的方法
}
private static class MyThread extends Thread {
WeakReference<ThreadAvoidActivity> mThreadActivityRef;//弱引用
public MyThread(ThreadAvoidActivity activity) {
mThreadActivityRef = new WeakReference<ThreadAvoidActivity>(
activity);
}
@Override
public void run() {//先判断是否为null，回收掉
super.run();
if (mThreadActivityRef == null)
return;
if (mThreadActivityRef.get() != null)
mThreadActivityRef.get().dosomthing();//通过弱引用得到外部的activity来调用dosomthing方法
// dosomthing
}
}
}
以上切断两个对象的双向强引用链接
- 静态内部类：切断Activity 对于 MyThread的强引用。
- 弱引用： 切断MyThread对于Activity 的强引用
AsynTask 内部类
跟线程一样的原理。
AsyncTask内部的实现机制是运用了ThreadPoolExcutor, 该类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的。
你可能会说：AsynTask不是有cancel的方法么？对的，是有这个方法，但还是不一定能取消。通过源码可以知道：
public final boolean cancel(boolean mayInterruptIfRunning) {
mCancelled.set(true);
return mFuture.cancel(mayInterruptIfRunning);
}
问题归因于mFuture.cancel(mayInterruptIfRunning);是否能取消正在执行的任务呢？
通过线程执行者（九）执行者取消一个任务，文章不是重点，重点是评论，提出了是否能真正取消任务的质疑？
查阅：Android学习系列(37)--App调试内存泄露之Context篇(下)，这里引用官方的言语：** cancel是不一定成功的。**
总结：只要是使用线程正在进行执行任务，都不一定能够取消。大多数是使用：Thread.interrupt()进行中断，但不一定成功的。所以最好的使用静态内存类或者使用弱引用。
官方的例子：
private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> {
protected Long doInBackground(URL... urls) {
int count = urls.length;
long totalSize = 0;
for (int i = 0; i < count; i++) {
totalSize += Downloader.downloadFile(urls[i]);
publishProgress((int) ((i / (float) count) * 100));
// Escape early if cancel() is called
// 注意下面这行，如果检测到cancel，则及时退出
if (isCancelled()) break;
}
return totalSize;
}
protected void onProgressUpdate(Integer... progress) {
setProgressPercent(progress[0]);
}
protected void onPostExecute(Long result) {
showDialog("Downloaded " + result + " bytes");
}
}
在后台循环中时刻监听cancel状态，防止没有及时退出。
所以：使用cancel并不靠谱，那么如何书写呢？跟Thread的思路是一样，差不多:
/**
*
* 弱引用
* @version 1.0.0
* @author Abay Zhuang <br/>
* Create at 2014-7-17
*/
public abstract class WeakAsyncTask<Params, Progress, Result, WeakTarget>
extends AsyncTask<Params, Progress, Result> {
protected WeakReference<WeakTarget> mTarget;
public WeakAsyncTask(WeakTarget target) {
mTarget = new WeakReference<WeakTarget>(target);
}
@Override
protected final void onPreExecute() {
final WeakTarget target = mTarget.get();
if (target != null) {
this.onPreExecute(target);
}
}
@Override
protected final Result doInBackground(Params... params) {
final WeakTarget target = mTarget.get();
if (target != null) {
return this.doInBackground(target, params);
} else {
return null;
}
}
@Override
protected final void onPostExecute(Result result) {
final WeakTarget target = mTarget.get();
if (target != null) {
this.onPostExecute(target, result);
}
}
protected void onPreExecute(WeakTarget target) {
// Nodefaultaction
}
protected abstract Result doInBackground(WeakTarget target,
Params... params);
protected void onPostExecute(WeakTarget target, Result result) {
// Nodefaultaction
}
}
BroadcastReceiver对象
原因：没有取消注册。
直接：getContext().unregisterReceiver(receiver);即可.
注册与反注册：
addCallback <==> removeCallback
registerReceiver <==> unregisterReceiver
addObserver <==> deleteObserver
registerContentObserver <==> unregisterContentObserver
TimerTask对象
TimerTask对象在和Timer的schedule()方法配合使用的时候极容易造成内存泄露。
要在合适的时候进行Cancel即可。
private void cancelTimer(){
if (mTimer != null) {
mTimer.cancel();
mTimer = null;
}
if (mTimerTask != null) {
mTimerTask.cancel();
mTimerTask = null;
}
}
剩下几个小点：
- Dialog对象：使用isFinishing()判断Activity是否退出。才可以
showDialog - Bitmap没调用recycle()
- 资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们
- 构造Adapter时，没有使用缓存的 convertView
- 集合容器对象没清理造成的内存泄露(尤其是static的集合，需要clear清理)
- WebView对象没有销毁。它的destory()函数来销毁它
总结：
泄漏都是有生命周期和Activity不一定一致，导致无法进行回收。
只要是使用线程正在进行执行任务，都不一定能够取消。大多数是使用：Thread.interrupt()进行中断，但不一定成功的。所以最好的使用静态内存类**或者使用弱引用。
实战检测定位内存泄露
1. 使用MAT工具定位Android应用内存泄漏
# 使用Android studio分析内存泄露
资料：
Android Context 是什么？
# Android内存泄露之Thread
# Android内存泄露之Handler
Android App 内存泄露之资源
Android内存泄露之DDMS –> Heap工具,这个系列的文章。
Android学习系列(37)--App调试内存泄露之Context篇(下)
Android内存泄露的整理
