viewWillDisappear in iOS — das Wesen der Methode und ihre korrekte Verwendung

Was ist viewWillDisappear

viewWillDisappear ist eine Methode von UIViewController, die UIKit direkt davor aufruft, dass die View des Steuerelements vom Bildschirm zu verschwinden beginnt. In diesem Moment ist der Bildschirm für den Benutzer noch sichtbar, aber der Übergang wurde bereits eingeleitet: NavigationController hat die Push/Pop-Animation gestartet, die modale Ansicht hat zu schließen begonnen, oder TabBar wechselt zu einem anderen Tab. Der Entwickler überschreibt diese Methode, um Vorgänge auszuführen, bei denen der Bildschirm noch zugänglich sein muss, sich aber auf das Ausblenden vorbereitet.

Anders als viewDidDisappear, das ausgelöst wird, nachdem der Bildschirm ausgeblendet ist, bietet viewWillDisappear die letzte Gelegenheit, Daten zu speichern und Ressourcen freizugeben, während der Benutzer die Oberfläche noch sehen kann. Dies ist für die UX von entscheidender Bedeutung — das Speichern eines Entwurfs oder das Stoppen eines Timers muss erfolgen, bevor der Benutzer zu einem anderen Bildschirm wechselt.

Die Methode akzeptiert den Parameter animated, der angibt, ob das Verschwinden animiert ist. true bedeutet, dass UIKit einen animierten Übergang durchführt, false bedeutet, dass der Bildschirm sofort verschwindet, z. B. bei einem nicht animierten dismiss oder einer programmatischen Entfernung aus der Hierarchie.

Wann wird viewWillDisappear aufgerufen

viewWillDisappear wird in allen Szenarien aufgerufen, in denen der aktuelle Bildschirm nicht mehr aktiv ist. Sehen wir uns die wichtigsten Fälle der iOS-Entwicklung an.

Beim Push eines neuen Bildschirms

Wenn UINavigationController einen neuen Controller per Push aufruft, wird viewWillDisappear beim aktuellen Controller zu Beginn der Übergangsanimation aufgerufen. In diesem Moment ist der aktuelle Bildschirm unter dem darüber gleitenden neuen Controller noch sichtbar. Dies ist das Standardszenario, bei dem viewWillDisappear mit animated = true ausgelöst wird.

Beim Pop des aktuellen Bildschirms

Wenn der Benutzer die Zurück-Taste drückt oder eine interaktive Wischbewegung nach hinten ausführt, wird viewWillDisappear beim aktuellen Controller aufgerufen. Bei einer interaktiven Geste kann dieser Aufruf abgebrochen werden, wenn der Benutzer seine Meinung ändert und den Bildschirm zurückholt. Dies ist ein wichtiges Merkmal, das beim Entwerfen des Zustandsspeicherns zu berücksichtigen ist.

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

Beim Dismiss eines Controllers

Beim Schließen einer modalen Ansicht wird viewWillDisappear beim schließenden Controller zu Beginn der Dismiss-Animation aufgerufen. An diesem Punkt können Sie Ergebnisse über einen Delegate oder Closure zurückgeben, da der Controller, der die modale Ansicht präsentiert hat, die Kontrolle noch nicht zurückerhalten hat.

Beim Wechseln von TabBar-Tabs

UITabBarController ruft viewWillDisappear beim Controller des verlassenen Tabs direkt nachdem der Benutzer einen anderen Tab berührt hat, auf. Wenn der aktuelle Tab aktive Prozesse hat — Medienwiedergabe, Dateidownload, Timer — sollten diese hier pausiert oder gestoppt werden.

Praktische Aufgaben in viewWillDisappear

viewWillDisappear löst spezifische Aufgaben im Ressourcen- und Zustandsmanagement. Sehen wir uns die wichtigsten Szenarien mit Codebeispielen an.

Benutzerdaten speichern

Die wichtigste Aufgabe von viewWillDisappear ist das Speichern von Daten, die der Benutzer auf dem aktuellen Bildschirm eingegeben oder geändert hat. Nachrichtenentwürfe, bearbeitete Formularfelder, ausgewählte Einstellungen — all dies sollte gespeichert werden, bevor der Bildschirm verschwindet. Verwenden Sie Core Data, UserDefaults oder Dateispeicher für die Persistenz.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    guard hasUnsavedChanges else { return }
    draftStorage.save(currentDraft)
}

Abmelden von Benachrichtigungen

NotificationCenter, KVO und Combine-Publisher, die Sie in viewWillAppear oder viewDidLoad abonniert haben, müssen in viewWillDisappear gekündigt werden. Andernfalls werden Benachrichtigungen auf dem ausgeblendeten Bildschirm eingehen, was zu UI-Aktualisierungen führt, die der Benutzer nicht sieht, oder — schlimmer noch — zu Abstürzen aufgrund des Zugriffs auf bereits freigegebene Objekte.

Animationen und Timer stoppen

UIView-Animationen, die in viewDidAppear gestartet wurden, und Timer, die über Timer oder DispatchSource laufen, müssen in viewWillDisappear gestoppt werden. Fortlaufende Animationen auf einem ausgeblendeten Bildschirm verschwenden GPU und Akku ohne Nutzen für den Benutzer. Stoppen Sie sie explizit durch Aufrufen von invalidate bei Timern und removeAllAnimations bei Ebenen.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    countdownTimer?.invalidate()
    countdownTimer = nil
    loadingIndicator.layer.removeAllAnimations()
}

Daten zurückgeben

Wenn ein Controller geöffnet wurde, um ein Ergebnis zu erhalten — Auswahl eines Elements, Texteingabe, Bestätigung einer Aktion — ist viewWillDisappear der letzte Moment, in dem der ursprüngliche Controller noch im Stack existiert und Daten empfangen kann. Rufen Sie den Delegate oder Closure vor dem Aufruf von deinit auf.

Strategie zum Speichern des Zustands

Das zuverlässige Speichern des Zustands ist eine der schwierigsten Aufgaben in der iOS-Entwicklung. viewWillDisappear ist ein wichtiges, aber nicht das einzige Element der Strategie. Betrachten wir einen umfassenden Ansatz.

Stufe 1 — Speichern in viewWillDisappear. Schnelles Speichern von leichten Daten, die sofort nach der Rückkehr verfügbar sein sollten. Geeignet für UI-Zustand: Scrollposition, ausgewähltes Segment, Text in Eingabefeldern. Problem: Bei einer abgebrochenen interaktiven Pop-Geste erfolgt das Speichern, obwohl der Benutzer auf dem Bildschirm geblieben ist — Daten werden unnötigerweise überschrieben.

Stufe 2 — Speichern in viewDidDisappear. Dupliziert das Speichern der ersten Stufe, wird aber erst ausgelöst, nachdem der Bildschirm garantiert ausgeblendet ist. Dies ist ein Schutz gegen abgebrochene Gesten. Wenn Sie jedoch bereits in viewWillDisappear Benachrichtigungen abbestellt haben, hat viewDidDisappear möglicherweise keinen Zugriff auf einige Daten.

Stufe 3 — Speichern über App-Benachrichtigungen. UIApplication.willResignActiveNotification und UIApplication.didEnterBackgroundNotification fangen das Minimieren der App ab. Wenn der Benutzer die App minimiert hat, wurde viewWillDisappear möglicherweise nicht aufgerufen — aber das Speichern über diese Benachrichtigungen garantiert die Datenintegrität beim Beenden der Sitzung.

Empfehlung: Verwenden Sie eine Kombination aller drei Stufen für kritische Benutzerdaten. Für nicht kritische Zustände ist die erste Stufe ausreichend. Es ist wichtig, dieselben Daten nicht mehrfach zu speichern — verwenden Sie ein dirty-Flag, das anzeigt, dass sich Daten seit dem letzten Speichern geändert haben.

Besondere Aufmerksamkeit sollte der Strategie für CRUD-Bildschirme gewidmet werden, auf denen der Benutzer Daten eingibt. Auf solchen Bildschirmen wird nicht empfohlen, jeden Tastendruck in viewWillDisappear zu speichern — das ist übermäßig. Verwenden Sie Auto-Save mit Verzögerung (Debounce) über Timer und verwenden Sie viewWillDisappear nur für das finale erzwungene Speichern, wenn ungespeicherte Änderungen vorliegen. Dieser Ansatz balanciert Leistung und Datenintegrität.

Für Apps, die Core Data verwenden, ist eine zusätzliche Maßnahme, saveContext in viewWillDisappear nur dann aufzurufen, wenn tatsächliche Änderungen im verwalteten Objektkontext vorliegen. Die Überprüfung von context.hasChanges vor dem Speichern verhindert unnötige Schreibvorgänge im persistenten Speicher und verlängert die Akkulaufzeit des Geräts. Kombinieren Sie diese Überprüfung mit dem globalen Speichern in applicationDidEnterBackground.

Häufige Fehler in viewWillDisappear

Die falsche Verwendung von viewWillDisappear kann zu Datenverlust, Speicherlecks und instabilem App-Verhalten führen. Sehen wir uns häufige Fehler von iOS-Entwicklern an.

Erster Fehler — Daten nur in viewWillDisappear speichern. Wie oben besprochen, wird die Methode bei einer interaktiven Pop-Geste aufgerufen, auch wenn der Bildschirm nicht verschwunden ist. Wenn das Speichern Nebenwirkungen hat — Senden von Daten an den Server, Ändern des Zustands — kann dies zu falschen Auslösungen führen. Fügen Sie eine Überprüfung von isBeingDismissed oder isMovingFromParent hinzu.

Zweiter Fehler — fehlende Abmeldung vom NotificationCenter. Dies ist eines der häufigsten Speicherlecks in iOS. Wenn Sie sich in viewWillAppear für UIResponder.keyboardWillShowNotification angemeldet, aber in viewWillDisappear nicht abgemeldet haben, wird der Closure weiterhin aufgerufen. Beim Deinit des Controllers verweist der Closure auf ein freigegebenes Objekt — App-Absturz garantiert.

Dritter Fehler — Ausführung schwerer synchroner Vorgänge. Das Speichern großer Datenmengen, das Schreiben in Core Data oder das Dateisystem in viewWillDisappear blockiert den Hauptthread. Wenn der Vorgang länger dauert als die Übergangsanimation, pausiert UIKit den Thread und die Oberfläche friert ein. Verlagern Sie schwere Speichervorgänge in Hintergrundwarteschlangen.

Vierter Fehler — Vergessen, super aufzurufen. Das Unterlassen des Aufrufs von super.viewWillDisappear kann UINavigationController und UITabBarController beeinträchtigen, die diese Methode für ihre internen Zustände verwenden. Rufen Sie super immer zuerst oder zuletzt auf, gemäß der Apple-Dokumentation.

Dieses Problem wird auf iOS mit aktivem Multitasking und App-Wechseln noch verstärkt. Fünfter Fehler — Verwendung von DispatchQueue.main.async nach dem Speichern in viewWillDisappear. Wenn Sie nach dem Aufruf von super.viewWillDisappear asynchron einen Block an die Hauptwarteschlange senden, gibt es keine Garantie, dass der Controller zum Zeitpunkt der Ausfückung des Blocks noch existiert. Verwenden Sie immer schwache Referenzen [weak self] innerhalb von Closures, um den Zugriff auf freigegebenen Speicher und App-Abstürze zu verhindern.