2017-01-05 60 views
6

Jestem ciekawy, dlaczego poniżej jest wyciek pamięci, ponieważ mHandler jest tworzony na mainThread i teraz, gdy nazywa się onDestroy, po prostu zabija wątek? w jaki sposób przewodnik może istnieć po zniszczeniu działania? Nie utworzyłem nowego wątku. Czy rozumiem, że program obsługi, jeśli ma jakieś rzeczy, kolejka wiadomości pozostanie nawet po zniszczeniu wątku?Android - czy programy mainThread mogą powodować wycieki pamięci?

Odniesienie doc im czytanie jest here enter image description here

Odpowiedz

13

Handler służy głównie do publikowania wydarzeń w wątku MessageQueue. Każda instancja procedury obsługi jest powiązana z pojedynczym wątkiem i kolejką komunikatów tego wątku.

więc kiedy piszesz runnable z opóźnieniem, a wyjście z działalności, MainThread nie zostaną zniszczone, ponieważ nie są jeszcze wydarzenia w kolejka komunikatów mają być przetwarzane z opóźnieniem, więc może to spowodować memoryLeak jako twoja anonimowa klasa wewnętrzna działająca zawiera odwołanie do instancji aktywności instancję.

więc upewnij się, aby usunąć wszystkie wiadomości w OnStop() Działalności wywołując

handler.removeCallbacksAndMessages(null); 

to usunie wszystkie oczekującą wiadomość i wywołania zwrotne przed opuszczeniem swoją aktywność.

+0

Twoje przysłowie, jeśli przewodnik ma wiadomości w kolejce, musi nadal działać, nawet jeśli zakończy się działanie, które zostało utworzone, prawda? – j2emanue

+0

A w przypadku mojego przykładu handler jest powiązany z mainThread. i umieszczam runnables na głównym wątku looper. teraz, gdy działanie wywołuje funkcję Destroy, ponieważ wiadomości nadal znajdują się w kolejce looper mainThreads, GC nie będzie zbierać aktywności? czy jest to, że GC nie będzie zbierać działania z powodu odniesienia, które działa w trybie runnable? Zobacz, co mam na myśli? Powiedzmy, że działający nie ma odwołania do działania? czy nadal wyciekał? – j2emanue

+0

@ j2emanue, jeśli twój runnable nie zawiera żadnych odwołań do działania, w takim przypadku wyciek aktywności nie nastąpi, ale wątek główny pozostanie przy życiu, ponieważ musi zakończyć zdarzenia w kolejce komunikatów zaksięgowanej przez runnable. –

0

mogą one, ale nie z Handler- w Runnable, który jest delegowany. Sposób działania modułu obsługi jest związany z wątkiem. Ten wątek musi mieć Looper. Looper ma kolejkę komunikatów. Po dodaniu opcji Opróżnij, dodajesz kolejkę komunikatów Runnable to the Looper's. Wątek sam w sobie ma odniesienie do Runnable. Tak, aby runnable wyciekły, a jeśli nie są statyczne, klasa nadrzędna wycieknie.