Утечка канарейки, утечка recyclerview mAdapter

Question

Я решил, что настало время узнать, как использовать Leak Canary для обнаружения утечек в моих приложениях, и, как я всегда это делал, я попытался реализовать его в своем проекте, чтобы действительно понять, как использовать инструмент. Реализация этого была достаточно простой, сложная часть читала то, что инструмент отбрасывает мне. У меня есть scrollview, который, похоже, накапливает память в диспетчере памяти, когда я просматриваю вверх и вниз (хотя он не загружает никаких новых данных), поэтому я подумал, что это хороший объект-кандидат для отслеживания утечек, вот результат:

похоже v7.widget.RecyclerView просачивается адаптер, а не мое приложение. Но это не может быть прав ... правильно?

Вот код для адаптера и использование класса решений этого: https://gist.github.com/feresr/a53c7b68145d6414c40ec70b3b842f1e

Я начал Баунти на этот вопрос, потому что всплыли после двух лет на совершенно другое приложение

Answer 1

Если адаптер живет дольше, чем RecyclerView, вы должны очистить ссылку на адаптер в onDestroyView:

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

В противном случае адаптер будет содержать ссылку на RecyclerView, который должен был уже потерять память.

Answer 2

Прежде всего, Я ссылаюсь на this file.

Похоже, что v7.widget.RecyclerView просачивает адаптер, а не мое приложение. Но это не может быть прав ... правильно?

Это на самом деле ваш адаптер, который протекает в RecyclerView (и это сделано довольно ясно следа графика и название LeakCanary деятельности). Однако я не уверен, является ли это «родительским» RecyclerView или вложенным в HourlyViewHolder, или и то, и другое. Я думаю, что виновниками являются ваши ViewHolders. Сделав их нестационарными внутренними классами, вы явно предоставляете им ссылку на класс адаптивного адаптера, так как это почти напрямую соединяет адаптер с переработанными представлениями, поскольку родительский элемент каждого itemView в ваших владельцах - это сам RecyclerView.

Моим первым предложением исправить эту проблему было бы разделить ваши ViewHolders и Adapter, сделав их статическими внутренними классами. Таким образом, они не содержат ссылки на адаптер, поэтому поле context будет для них недоступным, и это тоже хорошо, поскольку ссылки на контексты должны передаваться и храниться экономно (также для предотвращения больших утечек памяти). Когда вам нужен контекст только для получения строк, сделайте это в другом месте, например, в конструкторе адаптера, но не храните контекст в качестве члена. Наконец, DayForecastAdapter тоже кажется опасным: вы передаете один и тот же экземпляр его каждому HourlyViewHolder, который кажется ошибкой.

Я думаю, что фиксируя конструкцию и развязка этих классов должно избавиться от этой памяти утечки

Answer 3

я был в состоянии исправить это переопределение RecyclerView. Это происходит потому, что RecyclerView никогда не отменяет себя от AdapterDataObservable.

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

Answer 4

Я не могу открыть изображение и увидеть реальную утечку, но если определить локальную переменную для вашего RecyclerView в вашем Fragment и установить ваш осколок retainInstanceStatetrue это может вызвать возможные утечки с вращением.

При использовании Fragment с retainInstance вы должны очистить все ваши ссылки Ui в onDestroyView

@Override 
public void onDestroyView() { 
    yourRecyclerView = null; 
    super.onDestroyView(); 
} 

Здесь вы можете найти подробную информацию по этой ссылке: Retained Fragments with UI and memory leaks