viewDidAppear in iOS — wat is het, wanneer wordt het aangeroepen en voorbeelden

Wat is viewDidAppear

viewDidAppear is een methode van UIViewController die UIKit aanroept nadat de View is toegevoegd aan de vensterhiërarchie en de overgangsanimatie volledig is voltooid. Op dit moment bevindt het scherm zich in de eindtoestand: het is zichtbaar, ermee kan worden geïnterageerd, alle UIKit-animaties zijn gestopt. De ontwikkelaar overschrijft deze methode om acties uit te voeren die vereisen dat het scherm gegarandeerd voor de ogen van de gebruiker is.

In tegenstelling tot viewWillAppear, waar het scherm zich alleen voorbereidt op weergave, signaleert viewDidAppear dat de gebruiker de interface al ziet. Dit is een kritisch verschil: het starten van een animatie in viewWillAppear kan leiden tot gemiste frames, omdat UIKit nog bezig is met de overgang. In viewDidAppear is de overgang voltooid en kunnen de bronnen van de controller worden gebruikt voor het renderen van nieuwe content.

De methode ontvangt de parameter animated van het type Bool, analoog aan viewWillAppear. Indien true — ging de verschijning van het scherm gepaard met een animatie. Deze parameter kan worden gebruikt om het UI-gedrag aan te passen: bijvoorbeeld om de binnenkomende animatie over te slaan bij een niet-geanimeerde terugkeer.

Wanneer wordt viewDidAppear aangeroepen

viewDidAppear wordt aangeroepen in alle scenario's waarin het scherm het verschijningsproces heeft voltooid. Laten we de belangrijkste gevallen bekijken vanuit het perspectief van een iOS-ontwikkelaar.

Bij voltooiing van de navigatieovergang

Nadat UINavigationController de push- of pop-animatie heeft voltooid, wordt viewDidAppear aangeroepen op de doelcontroller. Voor het eerste scherm in de stack wordt het geactiveerd na de initiële openingsanimatie. Dit is het hoofdscenario en waar men zich op richt bij het plaatsen van logica in viewDidAppear.

Na dismiss van een modaal venster

Wanneer de gebruiker een modaal gepresenteerde controller sluit en terugkeert naar het vorige scherm, roept UIKit viewDidAppear aan op de terugkerende controller. De parameter animated zal overeenkomen met of de dismiss met animatie is uitgevoerd. Dit moment is belangrijk voor het bijwerken van de UI na het ontvangen van gegevens van het kindscherm.

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

Bij het wisselen van TabBar-tabbladen

UITabBarController roept viewDidAppear aan op de controller van het geselecteerde tabblad na voltooiing van de wisseling. Dit is het verschil met viewWillAppear, dat wordt geactiveerd bij het begin van de wisseling. Als er op het tabblad een welkomstanimatie is of actieve tijd moet worden gevolgd, is viewDidAppear de juiste plek.

Bij verschijning uit de achtergrond

Wanneer de applicatie terugkeert van background naar foreground, kunnen viewWillAppear en viewDidAppear worden aangeroepen op de zichtbare controller, als de levenscyclus van de View tijdelijk was onderbroken. Gebruik voor betrouwbare tracking van terugkeer uit de achtergrond apart UIApplication.willEnterForegroundNotification.

Praktische taken in viewDidAppear

viewDidAppear lost taken op die een zichtbaar scherm vereisen voor correcte uitvoering. Laten we de belangrijkste gebruiksscenario's in echte projecten bekijken.

Verzenden van analytics-gebeurtenissen

De meest voorkomende taak van viewDidAppear — tracking van schermweergave. Analytische systemen zoals Firebase Analytics, Amplitude of Mixpanel moeten gebeurtenissen alleen ontvangen nadat het scherm daadwerkelijk aan de gebruiker is getoond. Het verzenden van een gebeurtenis in viewWillAppear kan de weergavetijd verkorten en valse triggers creëren.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    Analytics.logEvent(
        name: "screen_view",
        parameters: [
            "screen_name": "ProfileScreen",
            "screen_class": String(describing: self)
        ]
    )
}

Starten van binnenkomende animaties

Animaties die moeten beginnen na verschijning van het scherm — verschijning van elementen met vertraging, parallax, tutorial — worden gestart in viewDidAppear. Op dit moment is de grafische context volledig gereed en zal de animatie vloeiend zijn, zonder frame-uitval aan het begin. Dit is vooral belangrijk voor animaties die UIViewPropertyAnimator gebruiken.

Starten van asynchrone ladingen

Zware asynchrone bewerkingen — laden van afbeeldingen met hoge resolutie, parsen van grote JSON's, initialisatie van video — kunnen beter worden gestart in viewDidAppear dan in viewDidLoad of viewWillAppear. Op het moment van aanroep ziet de gebruiker de interface al, dus kan een skeleton of loader worden getoond, zonder de verschijning van het scherm te vertragen.

Starten van timers en intervallen

Als er op het scherm elementen zijn die periodieke update vereisen — afteltimer, laadindicator, voortgangsanimatie — worden ze gestart in viewDidAppear en gestopt in viewDidDisappear. Dit voorkomt werking van timers wanneer het scherm niet zichtbaar is, wat batterij en CPU-bronnen spaart.

Starten van contentweergave

Mediainhoud — video, audio, Lottie-animaties — wordt precies in viewDidAppear gestart, niet eerder. Als u de weergave in viewWillAppear start, mist de gebruiker de eerste seconden terwijl het scherm nog verschijnt. In viewDidAppear kunt u AVPlayer of Lottie-animatie starten met de zekerheid dat de gebruiker de content vanaf het eerste frame ziet. Dit is vooral belangrijk voor onboarding-schermen en splashscreens, waar nauwkeurige timing essentieel is.

Animaties en prestaties

Het juiste moment om een animatie te starten beïnvloedt direct de perceptie van vloeiendheid van de interface. Het verschil tussen starten in viewWillAppear en viewDidAppear kan onmerkbaar zijn bij eenvoudige animaties, maar kritisch voor complexe scènes.

Wanneer UIKit een push-overgang tussen schermen uitvoert, maakt het screenshots, animeert ze en roept tegelijkertijd viewWillAppear aan op de nieuwe controller. Als u op dit moment een zware animatie start — parallax, blur, transformatie — kan UIKit frames van de overgangsanimatie overslaan, wat een schokkerig effect creëert. viewDidAppear garandeert dat de overgangsanimatie is voltooid en u volledige controle over het renderen heeft.

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

    UIView.animate(
        withDuration: 0.6,
        delay: 0.3,
        usingSpringWithDamping: 0.8,
        initialSpringVelocity: 0.5
    ) {
        self.cardView.alpha = 1.0
        self.cardView.transform = .identity
    }
}

Gebruik vertragingen en demping om een natuurlijke cascadeverschijning van elementen te creëren. Deze aanpak verbetert de perceptie van de interface en verhoogt de dwell time — de gebruiker bestudeert de content langer, wat een positieve invloed heeft op gedragsmetrieken.

Veelvoorkomende fouten in viewDidAppear

Onjuist gebruik van viewDidAppear kan leiden tot prestatieproblemen, onverwacht gedrag van animaties en overmatige tracking. Laten we veelvoorkomende fouten bekijken.

Eerste fout — meerdere aanroepen. viewDidAppear kan in bepaalde scenario's meerdere keren worden aangeroepen: wisselen van tabbladen, terugkeer uit achtergrond, modale overgangen. Als er in de methode een zware bewerking wordt uitgevoerd zonder vlagcontrole, wordt deze gedupliceerd. Gebruik voor eenmalige acties de hasAppeared-vlag of dispatchOnce.

Tweede fout — starten van netwerkverzoeken zonder annulering bij verbergen. Als de gebruiker het scherm verlaat voordat het verzoek is voltooid, kan het resultaat worden toegepast op een reeds verborgen View. Gebruik annuleerbare URLSessionTask en beëindig ze in viewDidDisappear.

Derde fout — tracking in viewWillAppear in plaats van viewDidAppear. Sommige ontwikkelaars sturen analytics-gebeurtenissen in viewWillAppear, maar dit creëert valse triggers als het scherm niet verscheen (bijvoorbeeld bij een geannuleerde pop-gesture). viewDidAppear is de enige betrouwbare indicator dat de gebruiker het scherm daadwerkelijk heeft gezien.

Vierde fout — vergeten van super. De aanroep van super.viewDidAppear is noodzakelijk voor correcte werking van UINavigationController, UITabBarController en UISplitViewController. Zonder deze kunnen de standaard navigatie- en interface-updatemechanismen breken.

Vijfde fout — wijzigen van oriëntatie of schermgrootte zonder rekening te houden met viewDidLayoutSubviews. Als uw animatie in viewDidAppear afhankelijk is van de uiteindelijke afmetingen van de View, onthoud dan dat viewDidLayoutSubviews meerdere keren vóór viewDidAppear kan worden aangeroepen. Bij de eerste verschijning van het scherm wordt de layout voltooid vóór de aanroep van viewDidAppear, maar bij latere wijzigingen van de grootte — bijvoorbeeld bij rotatie van het apparaat — kan viewDidAppear niet worden aangeroepen en zal uw animatie niet starten. Gebruik in dergelijke gevallen viewDidLayoutSubviews met controle van de firstLayout-vlag.

Correcte implementatie vereist het bewaren van een referentie naar het animatieobject en het expliciet annuleren ervan bij het verlaten van het scherm. Zesde fout — starten van oneindige animaties zonder stopvlag. Als u in viewDidAppear een herhalende animatie start (bijvoorbeeld een pulserende indicator of een draaiende loader), maar deze niet stopt in viewDidDisappear, verbruikt de animatie GPU-bronnen, zelfs wanneer het scherm verborgen is. Bewaar altijd een referentie naar de actieve animatie en roep removeAllAnimations of setCompletion aan in de corresponderende methode voor beëindiging van de levenscyclus.

Zevende fout — negeren van viewDidDisappear voor het stoppen van activiteiten. Als u bent begonnen met het luisteren naar GPS, accelerometer of gyroscoop in viewDidAppear, stop dit dan zeker in viewDidDisappear. Anders blijven sensoren op de achtergrond werken, batterij verbruiken, zelfs als de gebruiker allang naar een ander scherm is gegaan. Gebruik gepaarde start- en stop-aanroepen in de corresponderende methoden van de levenscyclus — dit garandeert correct beheer van apparaatbronnen.