LeakCanary提示` policy.HwPhoneWindow$1.this$0`的泄漏分析

最新在华为手机GEM=703L android6.0发现的问题,在AsyncTask执行ProgressDialog的显示或隐藏,然后退出activity会发生泄漏。泄漏提示
GC ROOT com.android.internal.policy.HwPhoneWindow$1.this$0

开始分析

首先上mat的分析图

LeakCanary提示` policy.HwPhoneWindow$1.this$0`的泄漏分析_第1张图片
Paste_Image.png

其中提示了两个未清除的引用,都指向了HwPhoneWindow,貌似其内部类引用了它,这是什么东东?
凭我有限的小脑分析,涉及Window类在我的app只有两种:Activity,Dialog。Activity我已经完美的解决了泄漏问题,那先从Dialog下手。

在Dialog类中可以看到可以看到mWindow,mDecor

  final Window w = new PhoneWindow(mContext);
        mWindow = w;

...
mDecor = mWindow.getDecorView();

想到了什么,是不是跟Activity很像,原来Dialog自己拥有WIndow并维护,但是新建的时候使用Activity的上下文,在Activity销毁的时候,Dialog不销毁就会有泄漏风险,而且Dialog的生命周期会跟Activity产生不同步。

尝试1

原来写法

 progressDialog = new ProgressDialog(Activity.this);
 progressDialog.setProgress(ProgressDialog.STYLE_SPINNER);
 progressDialog.setTitle("加载通讯录中...");

并在Activity的onDestory执行super之前销毁

@Override
    protected void onDestroy() {
        if(progressDialog != null ){
            progressDialog.dismiss();
            progressDialog = null;
        }
        super.onDestroy();
    }

结果:
还是存在泄漏

尝试2

修改原来的写法,使用FragmentDialog改造,利用Fragment维护Dialog的生命周期
改造后:

public class ProgressFragmentDialog extends DialogFragment {
 @Override
    public Dialog onCreateDialog(Bundle savedInstanceState) {
        AlertDialog.Builder progressDialog = new AlertDialog.Builder(this.getActivity());
        progressDialog.setView(getActivity().getLayoutInflater().inflate(R.layout.dialog_progress,null));
        progressDialog.setCancelable(false);


        //取消返回键
        progressDialog.setOnKeyListener(new DialogInterface.OnKeyListener() {
            @Override
            public boolean onKey(DialogInterface dialog, int keyCode, KeyEvent event) {

                return true;
            }
        });
        AlertDialog dialog = progressDialog.create();
        dialog.setCanceledOnTouchOutside(false); //取消点击外关闭

        return dialog;
    }
}

//显示Dialog
 progressFragmentDialog = new ProgressFragmentDialog();
        progressFragmentDialog.show(this.getFragmentManager(),"ProgressFragmentDialog");

结果:

还是存在泄漏

what fuck! 分析到这,我已经黔驴技穷了,干脆不用Dialog,自己实现弹出框

尝试3

思路就是拿到根节点decorView,new一个View adddecorView上,前提是在Activity的setContentView()之后执行
上代码

public class ProgressViewDialog {

    /**
     * 上下文,存储activity信息
     */
   // private Context context;
    private ViewGroup decorView; //decorView
   // private ViewGroup activityRootView;//内容区域的根视图
    private ViewGroup dialogView;//我的根视图


    /**
     * 构造函数
     * @param context
     */
    public ProgressViewDialog(Context context)
    {
        //获得一个xml布局加载器
        LayoutInflater layoutInflater = LayoutInflater.from(context);

        //获得decorView
        decorView = (ViewGroup)((Activity)context).getWindow().getDecorView();
        //Log.d("decorView count", decorView.getChildCount()+"") ;
        //获得内容区域根视图
        //activityRootView = (ViewGroup)decorView.findViewById(android.R.id.content);
        //Log.d("activityRootView count", activityRootView.getChildCount()+"") ;

        //获得我的根视图
        dialogView = (ViewGroup)layoutInflater.inflate(R.layout.dialog_progress,null);
        //Log.d("rootView count", rootView.getChildCount() + "") ;

        //屏蔽下层触摸
        dialogView.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.d("lessonOneActivity","点击了本层");
            }
        });
        //屏幕返回键
        dialogView.setOnKeyListener(new View.OnKeyListener() {
            @Override
            public boolean onKey(View v, int keyCode, KeyEvent event) {
                return true;
            }
        });


    }
    public void show(){
        if(dialogView.getParent() == null){
            decorView.addView(dialogView);
            dialogView.setVisibility(View.VISIBLE);
        }
        else{
            //decorView.addView(rootView);
            dialogView.setVisibility(View.VISIBLE);
        }
    }

    public void dismiss(){
        dialogView.setVisibility(View.GONE);
    }

}

还是发现了上个泄漏问题,分析到这里,我已经没辙了,然后换台手机,魅族mx3,神奇的事情发生了,竟然没有泄漏了。黑人问号脸。

总结

继续查资料,发现很多人给出了讨论或者解决方案,倾向于Android输入法的漏洞,在15<=API<=23中都存在。
知乎用户十三太饱给出的解释是:
**
InputMethodManager的相关对象(mServedView等)没有传递下去的话,通过工具的检测的确会发现前一个Activity出现内存泄漏。但是实际上,InputMethodManager对象并不是完全归前一个Activity持有,只是暂时性的指向了它,InputMethodManager的对象是被整个APP循环的使用。另外,InputMethodManager是通过单例实现的,不会造成内存的叠加,所以个人觉得InputMethodManager并不会造成实质的内存泄漏。
**
个人选择不再解决,下面列一些blog供大家研究,有什么问题可以随时讨论,以上。

Android InputMethodManager 导致的内存泄露及解决方案
Leakcanary部分泄露警报无需修复

待研究参考资料:

Android非UI线程使用View.post()方法一处潜在的内存泄漏

注意事项:

  1. Dialog销毁一定要在activity销毁之前

你可能感兴趣的:(LeakCanary提示` policy.HwPhoneWindow$1.this$0`的泄漏分析)