泄漏金丝雀，再循环器查看泄漏的马达

Question

我决定是时候学习如何使用泄漏金丝雀来检测我的应用程序中的泄漏了，就像我一直做的那样，我尝试在我的项目中实现它，以真正了解如何使用该工具。实现它很容易，困难的部分是阅读工具向我扔回来的东西。我有一个scrollview，当我上下滚动时，它似乎在内存管理器中积累内存（即使它没有加载任何新数据），因此我认为这是跟踪泄漏的一个很好的候选对象，结果如下：

它看起来像v7。小装置。RecyclerView正在泄漏适配器，而不是我的应用程序。但那不可能是对的。。。。正当

下面是适配器和使用它的类的代码：https://gist.github.com/feresr/a53c7b68145d6414c40ec70b3b842f1e

我开始悬赏这个问题，因为两年后它在一个完全不同的应用程序上重新出现

Answer 1

首先，我引用了这个文件。

它看起来像v7。小装置。RecyclerView正在泄漏适配器，而不是我的应用程序。但那不可能是对的。。。。正当

实际上是您的适配器泄漏了RecycraView（跟踪图和LeakCanary活动的标题非常清楚）。然而，我不确定它是“父”回收视图还是HourlyViewHolder中的嵌套视图，或者两者兼而有之。我认为罪魁祸首是你的观众。通过使它们成为非静态的内部类，您显式地为它们提供了对封闭适配器类的引用，并且这几乎直接将适配器与回收的视图耦合在一起，因为持有者中每个itemView的父级都是回收视图本身。

我的第一个解决这个问题的建议是通过使ViewHolder和Adapter成为静态内部类来解耦它们。这样，它们就不会持有对适配器的引用，因此它们将无法访问您的上下文字段，这也是一件好事，因为上下文引用的传递和存储应该尽量少（也是为了避免大内存泄漏）。当您只需要上下文来获取字符串时，可以在其他地方进行，例如在适配器构造函数中，但不要将上下文存储为成员。最后，dayForecasAdapter似乎也很危险：您将一个相同的实例传递给每个HourlyViewHolder，这似乎是一个bug。

我认为修复设计和解耦这些类应该摆脱内存泄漏

Answer 2

我能够解决这个问题，通过重写回收视图。之所以发生这种情况，是因为RecyclerView从不从AdapterDataViable中注销自己。

@Override protected void onDetachedFromWindow() {
    super.onDetachedFromWindow();
    if (getAdapter() != null) {
        setAdapter(null);
    }
}

Answer 3

如果适配器的寿命比RecycraView长，则必须清除onDestRoyView中的适配器引用：

@Override
public void onDestroyView() {
    recyclerView.setAdapter(null);
    super.onDestroyView();
}

否则，适配器将保存对RecycraView的引用，该引用应该已经内存溢出。

如果屏幕涉及过渡动画，您实际上必须进一步执行此操作，并且仅在视图分离时清除适配器：

@Override
public void onDestroyView() {
    recyclerView.addOnAttachStateChangeListener(new View.OnAttachStateChangeListener() {
        @Override
        public void onViewAttachedToWindow(View v) {
            // no-op
        }

        @Override
        public void onViewDetachedFromWindow(View v) {
            recyclerView.setAdapter(null);
        }
    });
    super.onDestroyView();
}