记一次关于Fragment的内存泄漏

最新推荐文章于 2024-06-25 14:25:15 发布

ganduwei

最新推荐文章于 2024-06-25 14:25:15 发布

阅读量1.2w

点赞数 3

CC 4.0 BY-SA版权

分类专栏： android

本文链接：https://blog.youkuaiyun.com/ganduwei/article/details/82844848

android 专栏收录该内容

37 篇文章

订阅专栏

本文分析了单Activity多Fragment架构中，LoginFragment关闭后由于FragmentManangerImpl中的mCreatedMenus引用导致的内存泄漏问题。通过使用leakcanary和AndroidProfiler工具定位问题，并提出了两种解决方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

之前使用单Activity多Fragment架构完成过一个项目，在后期维护时发现，很多Fragment在关闭之后，内存无法被回收，出现了内存泄漏问题。leakcanary显示引用链信息如下：
ganduwei
LoginFragment关闭后仍然被FragmentManangerImpl中的mCreatedMenus所引用，导致LoginFragment无法被释放。

我又使用Android Profiler工具查看了内存中的实例，步骤如下：
1、运行app，打开Android Profiler工具，然后点击MEMORY，会显示如下视图：
ganduwei
2、点击左上角的“Force garbage collection”按钮执行一次垃圾回收，再点击它旁边的“Dump Java heap”按钮便可将堆中的实例全部分析出来：

如上图我把fragment过滤出来，LoginFragment确实还在内存中，但是FragmentManangerImpl中mAdded中已经不存在LoginFragment，再看看mCreatedMenus：
ganduwei
里面包含了LoginFragment。mCreatedMenus是个什么东西呢，为什么会引用着已关闭的页面？它是FragmentManangerImpl中的属性，只能去FragmentManangerImpl中找找答案了。

在FragmentManangerImpl找到了如下一段代码：

    public boolean dispatchCreateOptionsMenu(Menu menu, MenuInflater inflater) {
        if (this.mCurState < 1) {
            return false;
        } else {
            boolean show = false;
            ArrayList<Fragment> newMenus = null;

            int i;
            Fragment f;
            for(i = 0; i < this.mAdded.size(); ++i) {
                f = (Fragment)this.mAdded.get(i);
                if (f != null && f.performCreateOptionsMenu(menu, inflater)) {
                    show = true;
                    if (newMenus == null) {
                        newMenus = new ArrayList();
                    }

                    newMenus.add(f);
                }
            }

            if (this.mCreatedMenus != null) {
                for(i = 0; i < this.mCreatedMenus.size(); ++i) {
                    f = (Fragment)this.mCreatedMenus.get(i);
                    if (newMenus == null || !newMenus.contains(f)) {
                        f.onDestroyOptionsMenu();
                    }
                }
            }

            this.mCreatedMenus = newMenus;
            return show;
        }
    }

mCreatedMenus会在dispatchCreateOptionsMenu方法中被初始化并赋值，而其他地方并没有改变或重置mCreatedMenus中的元素，所以只有dispatchCreateOptionsMenu方法会影响mCreatedMenus。
dispatchCreateOptionsMenu方法是干嘛的呢，其实从方法名就可以猜到它是用来分发创建ActionBar菜单的。的确，从代码中我们就可以看出，它遍历了mAdded中所有的元素，然后调用元素的performCreateOptionsMenu方法。既然与创建菜单有关，那就去LoginFragment看看。

LoginFragment有创建Toolbar，并把Toolbar交给Activity来创建菜单，代码如下：

	setHasOptionsMenu(true);
	((AppCompatActivity) getActivity()).setSupportActionBar(mToolbar);

而LoginFragment上一级Fragment中并没有创建Toolbar菜单。

到这里我们大致就知道原因了，有两个地方：

1、LoginFragment中有创建菜单，而它的上一级Fragment没有创建菜单，这样导致从LoginFragment返回到上一级后，AppCompatActivity中的FragmentManangerImpl没有执行dispatchCreateOptionsMenu方法，所有mCreatedMenus中还是保存了LoginFragment的实例。如果上一级Fragment有创建菜单不会有此问题；

2、((AppCompatActivity) getActivity()).setSupportActionBar(mToolbar)这句代码导致Activity中引用了Fragment的mToolbar，如果Fragment关闭后，没有去掉这个引用就会导致无法释放Fragment。

当然，如果一个Activity中只有一两个Fragment没什么关系，Activity销毁后也就随之销毁了。但是在单Activity项目中，整个App就一个Activity，被关闭的Fragment在整个App生命周期中一直存在，这样就有很大问题了。

找到原因后，分析出解决方法就比较简单了。解决办法有两个：
1、Fragment中的菜单由自己来创建，不交给Activity，代码如下：

        mToolbar.setNavigationIcon(R.drawable.ic_back);
        mToolbar.setNavigationOnClickListener(v -> {
            //TODO
        });
        mToolbar.inflateMenu(R.menu.toolbar_menu);
        mToolbar.setOnMenuItemClickListener(menuItem -> {
            //TODO
            return true;
        });

2、菜单还是交给Activity管理，如果上一级Fragment有创建菜单那不用处理，如果没有需要在上一级Fragment清除掉引用，代码如下：

        ((AppCompatActivity) getActivity()).setSupportActionBar(null);
        ( getActivity()).onCreatePanelMenu(0,null);

onCreatePanelMenu方法会使dispatchCreateOptionsMenu被调用，从而给mCreatedMenus重新赋值。

当然最好是使用第一个方法，每个Fragment中的菜单由自己来管理。