iOS: Jak sprawdzić, czy sterowniki UIViewControllers są rozładowywane? (Swift)

Question

Używam UISplitViewController za każdym razem, gdy klikam wiersz w Master VC Widzę, że viewDidLoad() jest uruchamiany w VC szczegółów.

Czy to oznacza, że ​​tworzę nowe wystąpienie detalu VC w każdym wierszu?

Jeśli tak, to w jaki sposób mogę sprawdzić, czy VC szczegółów są prawidłowo rozładowywane i czy nie tylko tworzę coraz więcej nowych szczegółowych VC?

Jestem trochę zagubiony w Swift. Wcześniej mogłem NSLog w dealloc() i zobacz prawidłowo rozładunek UIViewController.

I tutaj Swift posiada funkcję deinit ale to nigdy nie nazywa się:

deinit { 
    println("\(__FILE__.lastPathComponent)) : \(__FUNCTION__)") 
    NSNotificationCenter.defaultCenter().removeObserver(self) 
} 

1) Gdzie należy być usunięcie moich obserwatorów?

2) Kiedy patrzę w nawigatorze debugowania w Xcode, zużycie pamięci stale rośnie i nigdy nie spada.

Aktualizacja: Szczegóły VC jest nazywany następująco:

if segue.identifier == "addEvent" { 
    if let controller = (segue.destinationViewController as UINavigationController).topViewController as? ManageViewController { 
     controller.manageEvent = nil 
     controller.navigationItem.leftBarButtonItem = self.splitViewController?.displayModeButtonItem() 
     controller.navigationItem.leftItemsSupplementBackButton = true 
    } 
} 

Nie robię niczego innego niż wiele przykładów widziałem, ale jestem zaniepokojony deinit nie miano

aktualizacja: Działa teraz - problem był z delegatem zatrzymanie deinit jest o nazwie (patrz poniżej odpowiedzi)

Mój oryginalny kod nieprodukcyjnym było:

protocol ManageViewDelegate { 
    func pressedButton(sender: AnyObject) 
} 

class ManageView: UIView { 
    var delegate: ManageViewDelegate? = nil 
    ... 
} 

kod Nowa robocza:

protocol ManageViewDelegate: class { 
    func pressedButton(sender: AnyObject) 
} 

class ManageView: UIView { 
    weak var delegate: ManageViewDelegate? = nil 
    ... 
} 

Answer 1

Masz widok z właściwością delegate która odwołuje się z powrotem do kontrolera widoku. Spowoduje to uzyskanie silnego cyklu odniesienia (wcześniej znanego jako cykl zatrzymywania), ponieważ kontroler widoku utrzymuje silne odniesienie do widoku najwyższego poziomu, który z kolei utrzymuje silne odniesienie do kontrolera widoku.

W Rozwiązywanie Cycles wyraźne odniesienie między wystąpieniami klasy odcinek The Swift Programming Language: Automatic Reference Counting, Apple opisuje w jaki sposób rozwiązać ten:

Swift oferuje dwa sposoby rozwiązywania silnych cykli odniesienia podczas pracy z właściwościami typu klasy: słabe referencje i niezatwierdzone referencje.

Odwołania słabe i nie powiodło się umożliwiają jednej instancji w cyklu odniesienia odwoływanie się do drugiej instancji bez trzymania jej mocno. Instancje mogą się wtedy odnosić do siebie bez tworzenia silnego cyklu odniesienia.

Użyj odniesienia weak, gdy jest ono ważne dla tego odniesienia, aby stać się nil w pewnym momencie podczas jego trwania. I odwrotnie, użyj odniesienia unowned, gdy wiesz, że odniesienie nigdy nie będzie nil po ustawieniu podczas inicjalizacji.

sposób można rozwiązać silny cyklu odniesienia przy określaniu delegate być weak:

weak var delegate: ManageViewDelegate? 

za to do pracy, musisz podać swój protokół być protokół klasa:

protocol ManageViewDelegate: class { 
    // your protocol here 
} 

To rozwiąże silny cykl odniesienia i wyeliminuje konieczność ręcznego nil the delegate w celu rozwiązania silnego cyklicznego odniesienia mi.

Answer 2

Także jeśli używasz bloki trzeba dodać [słabą siebie], w przeciwnym razie widok nie zostanie zniszczona

setupObserve(postID) { 
     [weak self] chatRequest in 
    self?.update() 
} 

Funkcja deinit powinna wypracować