viewDidDisappear: Wesen der Methode, Lebenszyklus von UIViewController und wann sie aufgerufen wird

Was ist viewDidDisappear?

viewDidDisappear ist eine Hook-Methode der UIViewController-Superklasse, die vom System aufgerufen wird, nachdem die Ansicht vollständig aus der Fensterhierarchie auf dem Bildschirm entfernt wurde. Sie ist Teil des standardmäßigen Ansichtslebenszyklus in UIKit und bietet dem Entwickler einen Punkt zur Durchführung von Abschlussoperationen.

Die Methode wird im UIViewController-Protokoll deklariert und kann in allen Unterklassen überschrieben werden. Die Methodensignatur lautet: override func viewDidDisappear(_ animated: Bool). Der Parameter animated gibt an, ob der Übergang von einer Animation begleitet wurde. Dies ermöglicht die Unterscheidung zwischen programmatischen und animierten Übergängen für eine präzisere Verhaltenssteuerung.

Im Gegensatz zu viewWillDisappear, das vor Beginn der Animation aufgerufen wird, garantiert viewDidDisappear, dass die Ansicht für den Benutzer nicht mehr sichtbar ist. Dies ist kritisch für Operationen, die erst nach dem vollständigen Ausblenden der Benutzeroberfläche ausgeführt werden dürfen — zum Beispiel das Ausblenden von Vollbild-Überlagerungselementen oder das Beenden der Videoaufzeichnung.

Signatur und Deklaration

Die Methode ist in der Basisklasse UIViewController definiert und hat folgende Signatur:

import UIKit

class MyViewController: UIViewController {
    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        // Ressourcen freigeben und abbestellen
    }
}

Der obligatorische Aufruf von super.viewDidDisappear(animated) in der ersten Zeile der Implementierung ist eine UIKit-Anforderung. Ohne ihn kann die Superklasse die internen Prozesse im Zusammenhang mit der Ansichtsdarstellung nicht korrekt abschließen. Das Ignorieren dieser Regel führt zu unvorhersehbarem Navigationsverhalten und möglichen Abstürzen.

Position von viewDidDisappear im Lebenszyklus von UIViewController

Der vollständige Lebenszyklus von UIViewController besteht aus sechs Schlüsselmethoden, die jeweils für eine bestimmte Phase der Existenz der Ansicht verantwortlich sind. viewDidDisappear schließt die Ausblendsequenz ab, nachdem viewWillDisappear aufgerufen wurde. Es ist wichtig, die Aufrufreihenfolge aller Methoden zu verstehen, um die Initialisierung und Freigabe von Ressourcen richtig zu verteilen.

Die Sequenz beim Erscheinen der Ansicht: viewDidLoad → viewWillAppear → viewDidAppear. Beim Ausblenden: viewWillDisappear → viewDidDisappear. Die letzte Phase — deinit, das aufgerufen wird, wenn das UIViewController-Objekt zerstört wird. Diese sechs Methoden bilden einen vollständigen Zyklus, der eine vorhersagbare Zustandsverwaltung gewährleistet.

Jede dieser Methoden wird genau einmal pro entsprechendem Übergang aufgerufen. Eine Ausnahme ist viewDidLoad, das erneut aufgerufen werden kann, wenn der ViewController aufgrund von Ressourcenknappheit aus dem Speicher entladen und dann wiederhergestellt wurde. In diesem Fall geht viewDidDisappear dem wiederholten viewDidLoad voraus.

Beziehung zur Übergangsanimation

Der Parameter animated in der Methodensignatur gibt an, ob der Übergang animiert war. Dies ist nützlich, um zwischen programmatischen Übergängen ohne Animation (z. B. beim Setzen von rootViewController) und vom Benutzer initiierten animierten Übergängen zu unterscheiden. Wenn der Wert false ist, wurde der Controller möglicherweise vom System zwangsweise ausgeblendet — in diesem Fall können einige zeitabhängige Operationen irrelevant sein.

Wann wird viewDidDisappear aufgerufen

Das System ruft viewDidDisappear in genau zwei Szenarien auf: wenn ein ViewController aus dem Navigationsstapel entfernt wird und wenn er von einem anderen Controller überdeckt wird. In beiden Fällen signalisiert die Methode, dass die Ansicht für den Benutzer nicht mehr sichtbar ist, und der Entwickler sollte Ressourcen freigeben, die im Hintergrund nicht benötigt werden. Das Verständnis dieser Szenarien verhindert falsche Annahmen über den Anwendungszustand.

Das erste Szenario — Pop aus UINavigationController. Wenn der Benutzer die Zurück-Taste drückt, wird popViewController:animated aufgerufen. Der aktuelle Controller erhält viewDidDisappear und dann, wenn keine starken Referenzen mehr auf ihn vorhanden sind, deinit. Das zweite Szenario — present/dismiss. Bei der modalen Präsentation eines neuen Controllers erhält der presentingViewController viewDidDisappear. Beim Dismiss wird diese Methode auf dem Controller aufgerufen, der modal präsentiert wurde.

Das dritte, weniger offensichtliche Szenario — Hinzufügen eines child ViewController. Wenn ein neuer untergeordneter Controller zu einem Container-Controller (z. B. UIPageViewController oder UITabBarController) hinzugefügt wird, erhält der aktive untergeordnete Controller viewDidDisappear. Dies ist kritisch für Anwendungen mit Tabs oder Seitenkarussells — jeder Tab-Wechsel sollte die Arbeit des inaktiven Bildschirms korrekt aussetzen.

Ausnahmen und nicht offensichtliche Fälle

Es gibt eine wichtige Ausnahme: Wenn ein UIViewController in einem modalen Fenster angezeigt wird und der Benutzer es interaktiv durch Wischen nach unten schließt, kann das System viewDidDisappear bei unvollständiger Wischgeste nicht aufrufen. Dieses Verhalten trat in iOS 13 zusammen mit dem interaktiven Dismiss auf. Entwickler sollten den Zustand über UIAdaptivePresentationControllerDelegate und die didDismiss-Methode behandeln, um den garantieren Empfang des Ereignisses zu gewährleisten.

Eine weitere Besonderheit — Speicherwarnungen. Bei Speicherknappheit kann das System die Ansicht eines nicht sichtbaren Controllers entladen. In diesem Fall wird viewDidDisappear normalerweise vor dem Entladen aufgerufen, aber der Entwickler sollte kritisch wichtige Bereinigungsoperationen in didReceiveMemoryWarning als Sicherheitsnetz duplizieren. Dieser Ansatz verhindert Datenverlust in extremen Szenarien.

Typische Anwendungsfälle

viewDidDisappear wird für drei Hauptkategorien von Operationen verwendet: Anhalten von Aktivitäten, Freigeben von Ressourcen und Speichern des Zustands. Jede Kategorie hat ihre eigenen Best Practices, die von der iOS-Entwickler-Community entwickelt wurden. Betrachten wir die häufigsten Szenarien mit Implementierungsbeispielen.

• Animationen stoppen — Aufruf von layer.removeAllAnimations() für CALayer, Stoppen von UIView.animate-Blöcken
• Ressourcen freigeben — Große Bilder eliminieren, zwischengespeicherte Daten löschen, Dateideskriptoren schließen
• Benachrichtigungen abbestellen — Entfernen von Beobachtern aus NotificationCenter.default, Stoppen von KVO-Beobachtungen
• Fortschritt speichern — Entwürfe in CoreData oder UserDefaults schreiben beim Schließen des Bearbeitungsbildschirms
• Überlagerungen ausblenden — Entfernen von Ladeindikatoren, Tooltips und Popover-Elementen, die nach einem Übergang nicht bleiben sollen

Beispiel: Abbestellen von NotificationCenter

Ein typischer Fehler ist es, Benachrichtigungen in viewDidLoad zu abonnieren und nie wieder abzubestellen. Dies führt dazu, dass der Handler auf einem freigegebenen Objekt aufgerufen wird, was einen Absturz verursacht. Der richtige Ansatz ist das Abonnieren in viewWillAppear und das Abbestellen in viewDidDisappear, was sicherstellt, dass das Abonnement nur aktiv ist, während der Controller auf dem Bildschirm angezeigt wird.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    NotificationCenter.default.addObserver(
        self,
        selector: #selector(handleKeyboardShow),
        name: UIResponder.keyboardWillShowNotification,
        object: nil
    )
}

override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)
    NotificationCenter.default.removeObserver(self)
}

Dieses Muster garantiert, dass der Benachrichtigungshandler nur aktiv ist, wenn der Controller auf dem Bildschirm sichtbar ist. Beim Navigieren zu einem anderen Bildschirm werden alle Abonnements automatisch entfernt und bei der Rückkehr wiederhergestellt. Dies erhöht die Zuverlässigkeit der Anwendung und beseitigt eine Klasse von Fehlern im Zusammenhang mit Benachrichtigungen.

Swift-Codebeispiele

Betrachten wir zwei praktische Beispiele zur Verwendung von viewDidDisappear in realen Projekten. Das erste Beispiel zeigt das Stoppen eines Timers beim Ausblenden des Bildschirms, das zweite die korrekte Beendigung der Tastaturbeobachtung. Beide Beispiele folgen dem Prinzip der Ressourcenfreigabe bei inaktivem Controller.

Stoppen eines Timers

Wenn auf dem Bildschirm ein Timer zur Aktualisierung der Benutzeroberfläche läuft (z. B. ein Countdown oder Karussell), muss er gestoppt werden, wenn der Controller ausgeblendet wird. Das Weiterlaufen des Timers im Hintergrund verbraucht nicht nur CPU-Ressourcen, sondern kann auch eine Ausnahme verursachen, wenn versucht wird, eine unsichtbare Benutzeroberfläche zu aktualisieren.

class CountdownViewController: UIViewController {
    private var countdownTimer: Timer?
    private var remainingSeconds: Int = 60

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        startTimer()
    }

    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        invalidateTimer()
    }

    private func invalidateTimer() {
        countdownTimer()?.invalidate()
        countdownTimer = nil
    }
}

Video pausieren beim Ausblenden

In vielen Apps spielt ein AVPlayer Video in einem integrierten Player ab. Wenn der Benutzer zu einem anderen Bildschirm navigiert, sollte das Video automatisch pausiert werden. Die Implementierung in viewDidDisappear stellt sicher, dass die Pause erfolgt, nachdem der Bildschirm vollständig ausgeblendet ist — dies verhindert das Flackern eines schwarzen Bildes während des Übergangs.

override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)
    if player().timeControlStatus == .playing {
        player().pause()
        playerLayer().removeFromSuperlayer()
    }
    player = nil
}

Das Eliminieren der Variable player nach dem Pausieren gibt zusätzlich den von den Videopuffern belegten Speicher frei. Dieser Ansatz ist besonders wichtig für Apps mit langen Videos, bei denen der Puffer mehrere Megabyte belegen kann. Die Kombination von Pausieren und Eliminieren von Referenzen minimiert den Footprint der App im Hintergrund.

viewDidDisappear und andere Lebenszyklusmethoden

viewDidDisappear wird oft mit viewWillDisappear und deinit verwechselt, aber jede dieser Methoden hat ihren eigenen Verantwortungsbereich. Das Verständnis der Grenzen zwischen ihnen ist der Schlüssel zu einer stabilen iOS-App-Architektur. Eine falsche Verwendung kann zur doppelten Freigabe von Ressourcen oder im Gegenteil zu Ressourcenlecks führen.

Der Hauptunterschied zwischen viewDidDisappear und viewWillDisappear ist der Aufrufzeitpunkt. viewWillDisappear wird aufgerufen, wenn die Ansicht noch sichtbar ist, sich aber auf das Verschwinden vorbereitet. Dies ist geeignet zum Speichern sichtbarer Daten (Text in Eingabefeldern). viewDidDisappear wird nach Abschluss der Animation aufgerufen, wenn die Ansicht garantiert nicht sichtbar ist — ideal zum Freigeben von Ressourcen, die nicht mit dem visuellen Zustand zusammenhängen.

deinit wird im Gegensatz zu viewDidDisappear nur aufgerufen, wenn das UIViewController-Objekt im Speicher zerstört wird. Wenn der Controller lediglich ausgeblendet ist (z. B. von einem modalen Fenster überdeckt), wird deinit nicht aufgerufen. In dieser Situation ist viewDidDisappear der einzige Punkt zur Durchführung von Abschlussoperationen. Die vollständige Ressourcenbereinigung sollte in deinit erfolgen, aber viewDidDisappear übernimmt die temporäre Freigabe bis zum nächsten Erscheinen.

Wann welche Methode verwenden

• viewWillDisappear — Speichern von Eingabedaten, Senden von Analysen zum Übergangsbeginn
• viewDidDisappear — Stoppen von Animationen, Abbestellen von Benachrichtigungen, Ausblenden von Überlagerungselementen
• deinit — Endgültige Freigabe großer Ressourcen, Schließen von Netzwerkverbindungen

Bei der Entwicklung mit SwiftUI wird die Methode viewDidDisappear nicht verwendet — sie wird durch den Modifikator .onDisappear ersetzt, der ähnlich funktioniert. Allerdings fehlt SwiftUI die direkte Lebenszykluskontrolle, und Entwickler verlassen sich auf Combine und State-Objekte für die Ressourcenverwaltung. Für UIKit-Apps bleibt viewDidDisappear das primäre Werkzeug zur Verwaltung des Bildschirmverschwindens.

Häufige Implementierungsfehler

Selbst erfahrene iOS-Entwickler machen Fehler bei der Arbeit mit viewDidDisappear. Betrachten wir die fünf häufigsten Probleme und Möglichkeiten zu deren Vermeidung. Die Kenntnis dieser Anti-Patterns hilft, schwer zu findende Fehler im Zusammenhang mit dem Controller-Lebenszyklus zu vermeiden.

• Fehlendes super.viewDidDisappear — der Aufruf von super ist für die korrekte Funktion von UIKit obligatorisch; sein Fehlen kann den internen Zustand des Controllers stören
• Schwere Operationen in viewDidDisappear — synchrones Schreiben großer Daten in viewDidDisappear blockiert den Hauptthread und beeinträchtigt die Übergangsanimation
• Vergessenes Abbestellen von Benachrichtigungen — wenn removeObserver nicht in viewDidDisappear aufgerufen wird, kann der Handler auf einem Zombie-Objekt ausgelöst werden, was EXC_BAD_ACCESS verursacht
• Doppeltes Abbestellen — das Entfernen eines Beobachters, der bereits an anderer Stelle entfernt wurde, führt zu NSInternalInconsistencyException
• Abhängigkeit von der Aufrufreihenfolge — in verschachtelten Containern ist die Aufrufreihenfolge von viewDidDisappear für untergeordnete und übergeordnete Controller nicht garantiert

Besondere Aufmerksamkeit ist der Threadsicherheit zu widmen. Wenn viewDidDisappear im Hauptthread aufgerufen wird (was von UIKit garantiert wird), aber die Ressourcenbereinigung asynchrone Operationen umfasst, muss der Zugriff auf gemeinsam genutzte Daten synchronisiert werden. Die Verwendung von DispatchQueue.main.async innerhalb von viewDidDisappear zur Aktualisierung der Benutzeroberfläche nach Abschluss einer asynchronen Aufgabe ist ein häufiger, aber korrekter Ansatz.

Ein weiteres wichtiges Anti-Pattern — Aufrufen von Delegatenmethoden innerhalb von viewDidDisappear, die einen neuen Übergang oder eine modale Präsentation auslösen können. Dies erzeugt einen Zyklus, in dem viewDidDisappear erneut aufgerufen werden kann, bevor der erste Aufruf abgeschlossen ist. Apple empfiehlt, modale Präsentationen innerhalb von Lebenszyklusmethoden zu vermeiden und sie in separate Ereignisbehandler auszulagern.