Dealloc nie jest wywoływany na aplikacji ARC

Question

Mam UIViewController, który jest pchany na kontroler kontenera, a następnie wyskoczył, a przy użyciu przydziału instrumentu, widzę, że kontroler widoku jest następnie niszczony. Jednak punkt przerwania dealloc kontrolera nigdy nie zostanie osiągnięty. Czy ktoś wie, dlaczego nie nazywa się dealloc? Czy ARC może zniszczyć obiekt bez wywoływania dealloc?

Co więcej, wyłączyłem NSZombies (niektórzy twierdzą, że może spowodować, że debugowanie nie rozpocznie się).

Edit:

dealloc nie robi wiele, po prostu drukuje na konsoli, a to nigdy nie jest wywoływana:

- (void)dealloc { NSLog(@"Deallocating..."); }

nie mogę pisać kontroler-to pojemnik jest zastrzeżony i zbyt skomplikowany. Dealloc jest nazywany konsekwentnie na niektórych kontrolerach, a nie na innych. Jeśli uda mi się znaleźć czas, postaram się opublikować uproszczoną wersję, która powiela problem.

Czy istnieje sposób sprawdzenia, czy NSZombies jest wyłączony?

Edit2

jestem delegowania zrzut ekranu z instrumentów; Wydaje mi się, że prawidłowo rozdziela.

Answer 1

Jeśli dealloc nie jest wywoływana przez VC, to chciałbym postawić tam jest okrągły odniesienie gdzieś w kodzie, który jest zapobiegając łuk z wywołaniem dealloc.

Niektóre rzeczy do sprawdzenia:

1. Czy masz obiekt instancji, że odniesienia powrotem do VC?
2. Jeśli chcesz odwołać się do VC, upewnij się, że użyłeś atrybutu "__unsafe_unretained" lub "weak" (iOS5 +), aby cykl zatrzymania nie wystąpił.

Zostałem przyciśnięty w tyłek, gdy moje deklaracje delegatów nie korzystały z __unsafe_unretained.

Answer 2

Czy masz NSZombieEnabled? Zobacz na to pytanie:

Why is object not dealloc'ed when using ARC + NSZombieEnabled

Byłem zakłopotany przez to na chwilę sobie ...

Answer 3

Właśnie natknąłem podobnego problemu. Czy masz jakieś bloki, w których odnosisz się do "ja"? Miałem kilka bloków do obserwacji powiadomień w moim init, gdzie miałem na myśli "self". Pod ARC self jest zatrzymywany w blokach. Mój dealloc nie został wezwany i właśnie wtedy usunąłem obserwację.

Sztuką jest utworzenie odwołania __weak (iOS 5+) lub __unsafe_unretained (iOS 4.x) do swojego "ja" i użycie go do uzyskania dostępu do siebie lub dowolnego _iVars (spowoduje to zatrzymanie "ja" jako dobrze) w bloku. Oto przykład.

__unsafe_unretained TableViewController *weakSelf = self; 
[[NSNotificationCenter defaultCenter] addObserverForName:NSManagedObjectContextObjectsDidChangeNotification object:nil queue:nil usingBlock:^(NSNotification *note) { 
     if (weakSelf.tableView) { 
      [weakSelf.tableView reloadData]; 
     } 
    }]; 

Answer 4

Nawet z ARC można sprawdzić liczbę odwołań ręcznie:

CFIndex rc = CFGetRetainCount((__bridge CFTypeRef)myObj); 

można wiedzieć na pewno, jeśli kod jest zawieszony w cyklu pamięci.

Answer 5

Oto kolejna wskazówka (zdarzyło mi):

tl; dr: spojrzeć na swoje zmiennych instancji klasy, jak również, nie tylko właściwości klasy. Czy przydzielasz dowolną zmienną instancji w kodzie, a później nie ustawiasz jej później na nil?

Posiadałem klasę z paczką właściwości (@property (nonatomic, strong) i @property (nonatomic, weak)) w jej pliku nagłówkowym. Wyjaśniłem te właściwości jeden po drugim, aby zobaczyć, czy to coś zmieni. To nie mialo miejsca. Główna klasa wciąż nie została zwolniona. Więc problemu nie było w nieruchomościach.

Po tym, co zrobiłem, przyjrzałem się zmiennym instancji. Miałem jedną zmienną instancji (która była UIViewController), którą utworzyłem na viewDidLoad. Ten jeden nigdy został zwolniony!

Kiedy usunąłem tę zmienną, na pewno moja główna klasa nazywa się dealloc.

Ponieważ ten nie został zwolniony, moja główna klasa również nie została zwolniona. Przeniesienie tej instancji zmiennej jako właściwości rozwiązało problem dla mnie.

Pytanie: Nie jestem pewien, dlaczego tak się dzieje. Czy system operacyjny ma lepszą kontrolę nad właściwościami klasy niż zmiennymi instancji? Wydaje się nieco dziwne, że klasa nadrzędna, która zawiera zmienną instancji, nie zostaje zwolniona z powodu swojej zmiennej instancji.

Answer 6

W moim przypadku był to NSTimer. Zachowuje swój cel, więc musisz unieważnić timer, gdy skończysz z kontrolerem widoku.

Answer 7

Moim problemem byli delegaci.

Sprawdź swoich delegatów! Nieruchomość delegat powinien mieć weak określone: ​​

@property (weak, nonatomic) id<SomeProtocol> delegate;