一个无用的对象，被另一个对象所持有应用，造成该对象在虚拟机的堆中占有的内存无法释放，而导致内存空间的浪费，这种情况就是内存泄漏。
情况1: 单例持有Context
如下代码：
public class TestManager {
private static TestManager mInstance;
private Context mContext;
public static TestManager getInstance(Context context) {
if (mInstance == null) {
mInstance = new TestManager(context);
}
return mInstance;
}
private TestManager(Context context) {
mContext = context;
}
}
分析： 上述代码中，如果传入Activity的Context，此时TestManager就持有了Activity的引用，因为mInstance是个静态对象，生命周期和整个应用一样长，所以如果Activity退出，Activity对象占有的内存并不能被回收，就会导致内存泄漏。
方案： 此时应该传入全局的上下文Application Context，就能避免内存泄漏。
情况2: 匿名内部类
匿名内部类默认持有外部类的引用，如果匿名内部类生命周期长于外部类，就会导致内存泄漏，经典的例子就是Handler。
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
if (msg.what == 1) {
// 做相应逻辑
}
}
};
分析： 因为Handler在post消息时，会将自己本身作为成员变量保存在发送的Msg中，目的是方便去识别哪个Handler去处理消息。即message持有handler的引用，handler持有外部类（可能是Activity）的引用，而message是在MessageQueue中等待Looper轮询处理的，有可能Activity退出，而Message并没有被处理，就会导致Activity间接被Message引用，从而造成内存泄漏。
方案1：使用静态内部类 + 弱引用组合
因为静态内部类不持有外部类应用，所以如果想更新外部类，可以弱引用。代码如下：
public static class MyHandler extends Handler {
private WeakReference<MainActivity> reference;
public MyHandler (Activity activity) {
reference = new WeakReference<> (activity);
}
public void handlerMessage(Message msg) {
MainActivity activity = reference.get();
// 通过activity调用外部类方法
}
}
方案2: 在Activity退出时，清空所有Handler发生出去的消息。
@Override
public void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
}
情况3: 广播注册后未取消
情况4: Time和TimerTask的使用，未及时取消
很多情况写一些定时器或者轮询任务时，会用到Timer，参考如下代码：
public void timerTest() {
mTimer = new Timer();
mTimerTask = new TimerTask {
@Override
public void run() {
// do something
}
}
mTimer.schedule(mTimerTask, 3000,3000);
}
分析： task是个匿名内部类，同样默认持有外部类引用，而且task是定时执行的，所以Activity退出时，有可能task并没有被执行，就会导致内存泄漏。
方案： 在Activity退出时，及时取消掉Task；
@Override
public void onDestroy() {
super.onDestroy();
mTimer.cancel();
mTimer = null;
mTimerTask.cancel();
mTimerTask = null;
}
情况5: 资源未及时关闭，使用 IO、File 流或者 Sqlite、Cursor时，通常都会使用缓存，如果不及时关闭，缓存对象就会一直被占用，导致内存泄漏；
情况6: 动画未及时取消。Activity中使用了属性动画Animator，动画中有引用控件，而控件引用Activity，若销毁时没有及时cancel，会导致Activity一直被引用，无法回收，从而造成内存泄漏；
情况7: WebView 的内存泄露，因为 WebView 在加载网页后会长期占用内存而不能被释放，因此我 们在 Activity 销毁后要调用它的 destory()方法来销毁它以释放内存。
====================== 续 ========================
情况8： DialogFragment引起的内存泄漏。
在写弹框时，官方推荐使用DialogFragment，但是在弹框消失时，会报DialogFragment内存泄漏，且引用链的上一级是onCancelListener，LeakCanary报错如下：
┬───
│ GC Root: Java local variable
│
├─ android.os.HandlerThread thread
│ Leaking: UNKNOWN
│ Thread name: 'OkHttpProfiler'
│ ↓ HandlerThread.<Java Local>
│ ~~~~~~~~~~~~
├─ android.os.Message instance
│ Leaking: UNKNOWN
│ ↓ Message.obj
│ ~~~
├─ androidx.fragment.app.DialogFragment$2 instance
│ Leaking: UNKNOWN
│ Anonymous class implementing android.content.DialogInterface$OnCancelListener
│ ↓ DialogFragment$2.this$0
│ ~~~~~~
╰→ ***.PrivacyPolicyDialogFragment instance
Leaking: YES (ObjectWatcher was watching this because
***.PrivacyPolicyDialogFragment
分析： DialogFragment被泄漏，引用链上一条在于onCancelListener，看源码：
// DialogFragment.java
DialogInterface.OnCancelListener mOnCancelListener = new DialogInterface.OnCancelListener() {
@Override
public void onCancel(@Nullable DialogInterface dialog) {
if (mDialog != null) {
// 匿名内部类，持有对外部类DialogFragment的引用
DialogFragment.this.onCancel(mDialog);
}
}
};
// DialogFragment.java
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
// 省略代码
mDialog.setOnCancelListener(mOnCancelListener);
mDialog.setOnDismissListener(mOnDismissListener);
}
//Dialog.java
public void setOnCancelListener(@Nullable OnCancelListener listener) {
// 省略代码
if (listener != null) {
/**
* 划重点： listener带有DialogFragment的引用，此时创建mCancelMessage，
* 使用obtainMessage方法，在对象池中获取Message，并将listener赋值给msg的obj属性，
* 所以此时mCancelMessage持有了DialogFragment的引用
*/
mCancelMessage = mListenersHandler.obtainMessage(CANCEL, listener);
} else {
mCancelMessage = null;
}
}
此时的引用链为：
Dialog.mCancelMessage -> DialogFragment. mCancelListener -> DialogFragment 。
所以只能是mCancelMessage泄漏了，才能引发DialogFragment泄漏。
根据leakCanary截图显示，是HandlerThread持有了Message。
问：mCancelMessage是如何被HandlerThread持有的？
答：mCancelMessage被创建之前。
看看划重点的地方，Message是在对象池中拿到的，在Message对象被Handler处理之后，会被recycle，放入对象池。但是，如果此时是最后一个Message，由于Looper获取Message的方法，是一个阻塞方法，Looper会一直阻塞，并持有msg的引用。
即：
阻塞状态的Looper，一定会持有最后一个Message的引用
看代码：
// Looper.java
public static void loop() {
//省略代码
for (;;) {
/**
* 如果没有消息，next()方法会一直阻塞在这里，而此时上一个msg，
* 会一直被Looper持有，Looper被HandlerThread持有
*/
Message msg = queue.next(); // might block
}
// 省略代码
}
所以，及时Message被回收放入了对象池，也会被HandlerThread持有。此时的引用链为：
HanlderThread -> Looper -> mCancelMessage ->DialogFragment. mCancelListener -> DialogFragment
一切都真相大白了。
方案：等等哈
