Kanion wycieku, Recykling wycieku mAdapter

Question

Zdecydowałem, że już najwyższy czas nauczyłem się używać Leak Canary do wykrywania wycieków w moich aplikacjach, i jak zawsze, starałem się zaimplementować to w moim projekcie, aby naprawdę zrozumieć, jak używać narzędzie. Wdrożenie tego było łatwe, trudną częścią było odczytanie tego, co narzędzie rzuca na mnie. Mam przewijania, które wydaje się gromadzić pamięć w menedżerze pamięci, jak przewijania w górę iw dół (nawet jeśli nie ładuje żadnych nowych danych), więc myślałem, że był to dobry obiekt kandydata do śledzenia wycieków, jest to wynik:

wygląda v7.widget.RecyclerView przecieka zasilacz, a nie mój wniosek. Ale to nie może być w porządku ... prawda?

Oto kod dla karty i korzystanie making klasa to: https://gist.github.com/feresr/a53c7b68145d6414c40ec70b3b842f1e

zacząłem bounty na to pytanie, ponieważ powrócił po dwóch latach w zupełnie innej aplikacji

Answer 1

Jeśli adapter żyje dłużej niż RecyclerView ma, musisz wyczyścić odniesienie adaptera w onDestroyView:

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

W przeciwnym razie adapter będzie zawierał odniesienie do RecyclerView, które powinno już wyjść z pamięci.

Answer 2

Przede wszystkim, Mam na myśli this file.

Wygląda jak v7.widget.RecyclerView wycieka z adaptera, a nie z mojej aplikacji. Ale to nie może być w porządku ... prawda?

To rzeczywiście karta że przecieka do RecyclerView (i to całkiem jasne, wykonane przez wykresu śladowych i tytule aktywności LeakCanary). Jednak nie jestem pewien, czy jest to "nadrzędny" RecyclerView lub zagnieżdżony w HourlyViewHolder, czy w obu. Myślę, że sprawcami są Twoje ViewHolders. Tworząc je niestatycznymi klasami wewnętrznymi, jawnie podajesz im odniesienie do otaczającej klasy adaptera, a to prawie bezpośrednio łączy adapter z widokami z recyklingu, ponieważ rodzicem każdego itemView w twoich uchwytach jest sam RecyclerView.

Moja pierwsza sugestia rozwiązania tego problemu polegałaby na oddzieleniu twoich ViewHolders i Adaptera, czyniąc je wewnętrznymi klasami. W ten sposób nie będą one odwoływać się do adaptera, więc twoje pole będzie dla nich niedostępne, a także dobrze, ponieważ odniesienia kontekstowe powinny być przekazywane i przechowywane oszczędnie (również w celu uniknięcia dużych wycieków pamięci). Gdy potrzebujesz kontekstu tylko w celu uzyskania łańcuchów, zrób to gdzie indziej, na przykład w konstruktorze adaptera, ale nie przechowuj kontekstu jako elementu. Wreszcie, DayForecastAdapter wydaje się niebezpieczny: przekazujesz jedno, to samo wystąpienie tego do każdego HourlyViewHolder, co wydaje się być błędem.

myślę, że ustalenie projektowania i oddzielenie tych klas należy pozbyć się tej pamięci wyciek

Answer 3

udało mi się rozwiązać ten problem poprzez nadpisanie RecyclerView. Dzieje się tak, ponieważ RecyclerView nigdy nie wyrejestrowuje się z AdapterDataObservable.

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

Answer 4

Nie mogę otworzyć swój obraz i zobaczyć rzeczywisty wyciek ale jeśli zdefiniować zmienną lokalną dla Twojego RecyclerView w Fragment i ustawić fragment na retainInstanceStatetrue może spowodować ewentualne przecieki z obrotu.

Używanie Fragment z retainInstance należy wyczyścić wszystkie swoje referencje ui w onDestroyView

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

Tutaj można znaleźć szczegółowe informacje z tego linku: Retained Fragments with UI and memory leaks