既然是DialogFragment中在onActivityCreated方法中调用了Dialog的setOnDismissListener和setOnCancelListener这两个方法导致的，那么解决方法不是很简单么？我们继承DialogFragment，然后重写onActivityCreated方法，在super之后再次将setOnDismissListener和setOnCancelListener设置为空不就可以吗？这么简单的一个小问题还要劳烦我这个高级划水师出马，真是不让人省心啊！！！
然而想法很美好，现实很残酷啊，在super.onActivityCreate()方法中默认已经调用了mDialog.setOnCancelListener(this)和mDialog.setOnDismissListener(this)。此时获取的Message有可能是消息池中的某一条消息，而这条消息刚好被一个消息循环所持有不能释放的话，那么这个内存泄漏的问题依然无法解决，所以说这只是一个治标不治本的方法。
LeakCanary提供了一种解决方案：建议第三方库一直发送空的消息，保持第三方库的消息循环消息队列一直不为空。这种方式只能是提前知道哪个第三方库创建了自己的消息循环， 才能向这个消息循环中发送空消息，这并不能覆盖到所有的第三方创建的消息循环。而且，不断的向一个阻塞线程中发消息，线程时刻处于运行状态，占用线程空间资源。因此，此方案对于客户端开发来说并不可行。
直接拷贝DialogFragment代码至LeakDialogFragment类中，放弃实现DialogInterface.OnCancelListener和DialogInterface.OnDismissListener两个接口， 将这两个接口用静态内部类加弱引用的方式实现，然后将这个静态内部类设置到对应的内部Dialog当中去。
这的确是一个治标又治本的方案，但是工程量略大，而且本来DialogFragment是有谷歌官方维护的，现在变成了由你维护，如果未来官方发现了DialogFragment中产生了bug，默默修复了，那么你复制出来的这个类如何更新同步更新呢？
我不随流
其实一路过来无论是网上的资料还是LeakCanary都是告诉我们是说是DialogFragment发生了内存泄漏，但是罪魁祸首真的是DialogFragment吗？罪魁祸首是DialogFragment内部的Dialog啊，我们为什么一直揪着DialogFragment不放呢？为什么一直想着给DialogFragment治病呢？能不能给DialogFragment它内部的Dialog治治啊？
通过查看DialogFragment的源码我们发现它内部的mDialog是通过onCreateDialog方法生成的，而且这个方法是开放的。那么我们能不能通过重写这个方法，返回一个不会对DialogFragment持有强引用的Dialog不就完事了吗？
那么我们就重写一个Dialog名为NoLeakDialog：
public class NoLeakDialog extends Dialog {
public NoLeakDialog(@NonNull Context context, int themeResId) {
super(context, themeResId);
}
@Override
public void setOnCancelListener(@Nullable OnCancelListener listener) {
// 空实现，不持有外部的引用
}
@Override
public void setOnShowListener(@Nullable OnShowListener listener) {
// 空实现，不持有外部的引用
}
@Override
public void setOnDismissListener(@Nullable OnDismissListener listener) {
// 空实现，不持有外部的引用
}
@Override
public void setCancelMessage(@Nullable Message msg) {
// 空实现，不持有外部的引用
}
@Override
public void setDismissMessage(@Nullable Message msg) {
// 空实现，不持有外部的引用
}
}
然后在我们的继承的DialogFramment的onCreateDialog方法中返回我们的NoLeakDialog即可。
至此我自己内心不得不为我这个高级划水师惊人的隐藏bug能力叹服，赶紧泡一杯枸杞喝起来准备下一轮的划水。
几杯枸杞水下肚，正准备倒计时下班时，测试带着奸笑跑过来说你这个弹窗不对啊，我点击了空白处隐藏了弹窗，跳转到别的页面后再返回，这个弹窗又自己弹出来了。。。
此时我怀着高级划水师应有的自信直接怼回去说肯定是你的操作方式有问题，一边私底下偷偷打开AS调试起来。。。。
一顿操作猛如虎之后我们发现按返回键和点击空白区域返回键只是调用了Dialog的dismiss放，并没有调用DialogFragment的dismiss方法，因为点击空白区域或者返回键需要Dialog 回调DialogFragment才会调用DialogFragment的dismiss方法，但是我们在NoLeakDialog类中将这些监听器都变成了空实现，所以也就没有了回调。
而在DialogFragment的onDismiss方法方法中我们看到了官方的注释：
@Override
public void onDismiss(@NonNull DialogInterface dialog) {
if (!mViewDestroyed) {
// Note: we need to use allowStateLoss, because the dialog
// dispatches this asynchronously so we can receive the call
// after the activity is paused. Worst case, when the user comes
// back to the activity they see the dialog again.
dismissInternal(true, true);
}
}
注释已经很清楚地说明了DialogFragmen会再次弹出
对于这个问题，我们只要在我们NoLeakDialog中重写dismiss方法，将相关事件回调给DialogFragment，然后调用DialogFragment的dismiss或者dismissAllowingStateLoss方法即可。
所以我们最终NoLeakDialog的代码应该这样：
public class NoLeakDialog extends Dialog {
private WeakReference<DialogFragment> hostFragmentReference;
public void setHostFragmentReference(DialogFragment hostFragment) {
this.hostFragmentReference = new WeakReference<>(hostFragment);
}
public NoLeakDialog(@NonNull Context context, int themeResId) {
super(context, themeResId);
}
@Override
public void setOnCancelListener(@Nullable OnCancelListener listener) {
// 空实现，不持有外部的引用
}
@Override
public void setOnShowListener(@Nullable OnShowListener listener) {
// 空实现，不持有外部的引用
}
@Override
public void setOnDismissListener(@Nullable OnDismissListener listener) {
// 空实现，不持有外部的引用
}
@Override
public void setCancelMessage(@Nullable Message msg) {
// 空实现，不持有外部的引用
}
@Override
public void setDismissMessage(@Nullable Message msg) {
// 空实现，不持有外部的引用
}
@Override
public void dismiss() {
super.dismiss();
if (null != hostFragmentReference && null != hostFragmentReference.get()) {
hostFragmentReference.get().dismissAllowingStateLoss();
}
}
}
思考
由于我们将setOnDismissListener变成空实现，导致了点击空白区域或者返回键后再次返回界面又弹窗的问题，那么我们将其他的监听器设置为空， 会不会导致其他的问题呢？如果导致了，我们有补救措施不？
由此我们将众监听器都设置为空，那么如果我们真正的使用中需要用到这些键监听怎么办？
答案不是目的，无论何时何地，锻炼自己独立思考的能力助你上青云的推力！！！
关注我，一起进步，人生不止coding！！！
本文分享自微信公众号 - 思想觉悟（ChuanFlyer）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。