viewDidAppear în iOS — ce este, când este apelat şi exemple

Ce este viewDidAppear

viewDidAppear este o metodă UIViewController pe care UIKit o apelează după ce View a fost adăugată în ierarhia ferestrelor şi animația de tranziție s-a încheiat complet. În acest moment ecranul se află în starea finală: este vizibil, se poate interacționa cu el, toate animațiile UIKit sunt oprite. Dezvoltatorul suprascrie această metodă pentru a efectua acțiuni care necesită ca ecranul să fie garantat în fața utilizatorului.

Spre deosebire de viewWillAppear, unde ecranul doar se pregăteşte pentru afişare, viewDidAppear semnalează că utilizatorul vede deja interfața. Aceasta este o diferență critică: pornirea animației în viewWillAppear poate duce la cadre pierdute, deoarece UIKit încă procesează tranziția. În viewDidAppear tranziția este finalizată, iar resursele controlerului pot fi utilizate pentru randarea conținutului nou.

Metoda primeşte parametrul animated de tip Bool, similar cu viewWillAppear. Dacă true — apariția ecranului a fost însoțită de animație. Acest parametru poate fi folosit pentru adaptarea comportamentului UI: de exemplu, pentru a sări peste animația de intrare la o revenire neanimată.

Când este apelat viewDidAppear

viewDidAppear este apelat în toate scenariile în care ecranul a finalizat procesul de apariție. Să examinăm cazurile principale din perspectiva dezvoltatorului iOS.

La finalizarea tranziției de navigare

După ce UINavigationController a finalizat animația push sau pop, pe controlerul țintă este apelat viewDidAppear. Pentru primul ecran din stivă, acesta se activează după animația inițială de deschidere. Acesta este scenariul principal și este cel la care se face referire la plasarea logicii în viewDidAppear.

După dismiss-ul ferestrei modale

Când utilizatorul închide controlerul prezentat modal şi revine la ecranul anterior, UIKit apelează viewDidAppear la controlerul care revine. Parametrul animated va corespunde cu faptul dacă dismiss-ul a fost executat cu animație sau nu. Acest moment este important pentru actualizarea UI după primirea datelor de pe ecranul copil.

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

La comutarea filelor TabBar

UITabBarController apelează viewDidAppear pe controlerul filei selectate după finalizarea comutării. Aceasta este diferența față de viewWillAppear, care se activează la începutul comutării. Dacă pe filă există o animație de bun venit sau este necesară urmărirea timpului activ, viewDidAppear este locul potrivit.

La apariția din fundal

Când aplicația revine din background în foreground, la controlerul vizibil pot fi apelate viewWillAppear şi viewDidAppear, dacă ciclul de viață al View a fost temporar suspendat. Cu toate acestea, pentru urmărirea fiabilă a revenirii din fundal, utilizați separat UIApplication.willEnterForegroundNotification.

Sarcini practice în viewDidAppear

viewDidAppear rezolvă sarcini care necesită un ecran vizibil pentru execuția corectă. Să examinăm scenariile cheie de utilizare în proiecte reale.

Trimiterea evenimentelor de analytics

Cea mai frecventă sarcină a viewDidAppear — urmărirea vizualizării ecranului. Sistemele analitice precum Firebase Analytics, Amplitude sau Mixpanel trebuie să primească evenimente doar după ce ecranul a fost efectiv arătat utilizatorului. Trimiterea evenimentului în viewWillAppear poate subestima timpul de vizualizare şi poate crea declanşări false.

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

Lansarea animațiilor de intrare

Animațiile care trebuie să înceapă după apariția ecranului — apariția elementelor cu întârziere, paralaxa, tutorialul — se lansează în viewDidAppear. În acest moment contextul grafic este complet pregătit, iar animația va fi lină, fără pierdere de cadre la start. Acest lucru este deosebit de important pentru animațiile care utilizează UIViewPropertyAnimator.

Pornirea încărcărilor asincrone

Operațiile asincrone grele — încărcarea imaginilor de înaltă rezoluție, parsarea JSON-urilor mari, inițializarea video — este mai bine să fie lansate în viewDidAppear, nu în viewDidLoad sau viewWillAppear. În momentul apelării metodei, utilizatorul vede deja interfața, aşa că se poate afişa un schelet sau un loader, fără a întârzia apariția ecranului.

Pornirea timerelor şi intervalelor

Dacă pe ecran există elemente care necesită actualizare periodică — timer de numărătoare inversă, indicator de încărcare, animație de progres — acestea se lansează în viewDidAppear şi se opresc în viewDidDisappear. Aceasta previne funcționarea timerelor când ecranul nu este vizibil, economisind bateria şi resursele CPU.

Pornirea redării conținutului

Conținutul media — video, audio, animații Lottie — se lansează exact în viewDidAppear, nu mai devreme. Dacă începeți redarea în viewWillAppear, utilizatorul va pierde primele secunde în timp ce ecranul încă apare. În viewDidAppear puteți lansa AVPlayer sau animația Lottie cu certitudinea că utilizatorul vede conținutul din primul cadru. Acest lucru este deosebit de important pentru ecranele de onboarding şi splash screen-uri, unde sincronizarea exactă contează.

Animații şi performanță

Momentul potrivit de lansare a animației influențează direct percepția fluidității interfeței. Diferența dintre lansarea în viewWillAppear şi viewDidAppear poate fi imperceptibilă la animații simple, dar critică pentru scene complexe.

Când UIKit execută o tranziție push între ecrane, creează capturi de ecran, le animează şi în acelaşi timp apelează viewWillAppear pe noul controler. Dacă în acest moment se lansează o animație grea — paralaxă, blur, transformare — UIKit poate sări peste cadrele animației de tranziție, creând un efect de sacadare. viewDidAppear garantează că animația de tranziție este finalizată şi aveți control complet asupra randării.

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
    }
}

Utilizați întârzieri şi amortizare pentru a crea o apariție naturală în cascadă a elementelor. Această abordare îmbunătățește percepția interfeței şi creşte dwell time-ul — utilizatorul studiază conținutul mai mult timp, ceea ce influențează pozitiv metricile comportamentale.

Erori tipice în viewDidAppear

Utilizarea incorectă a viewDidAppear poate duce la probleme de performanță, comportament neaşteptat al animațiilor şi urmărire excesivă. Să examinăm erorile frecvente.

Prima eroare — apeluri multiple. viewDidAppear poate fi apelat de mai multe ori în anumite scenarii: comutarea filelor, revenirea din fundal, tranziții modale. Dacă în metodă se execută o operație grea fără verificarea unui steag, aceasta se va duplica. Pentru acțiuni unice, utilizați steagul hasAppeared sau dispatchOnce.

A doua eroare — lansarea cererilor de rețea fără anulare la ascundere. Dacă utilizatorul părăseşte ecranul înainte de finalizarea cererii, rezultatul poate fi aplicat unui View deja ascuns. Utilizați URLSessionTask anulabile şi finalizați-le în viewDidDisappear.

A treia eroare — urmărirea în viewWillAppear în loc de viewDidAppear. Unii dezvoltatori trimit evenimente analytics în viewWillAppear, dar acest lucru creează declanşări false dacă ecranul nu a apărut (de exemplu, la un gest pop anulat). viewDidAppear este singurul indicator fiabil că utilizatorul a văzut efectiv ecranul.

A patra eroare — super-ul uitat. Apelul super.viewDidAppear este necesar pentru funcționarea corectă a UINavigationController, UITabBarController şi UISplitViewController. Fără el, mecanismele standard de navigare şi actualizare a interfeței se pot strica.

A cincea eroare — schimbarea orientării sau dimensiunii ecranului fără a ține cont de viewDidLayoutSubviews. Dacă animația dumneavoastră în viewDidAppear depinde de dimensiunile finale ale View, rețineți că viewDidLayoutSubviews poate fi apelat de mai multe ori înainte de viewDidAppear. La prima apariție a ecranului, layout-ul se finalizează înainte de apelarea viewDidAppear, dar la modificările ulterioare de dimensiune — de exemplu, la rotirea dispozitivului — viewDidAppear poate să nu fie apelat, iar animația dumneavoastră nu va porni. în astfel de cazuri, utilizați viewDidLayoutSubviews cu verificarea steagului firstLayout.

Implementarea corectă presupune păstrarea referinței la obiectul animației şi anularea sa explicită la părăsirea ecranului. A şasea eroare — lansarea animațiilor infinite fără un steag de oprire. Dacă în viewDidAppear lansați o animație repetitivă (de exemplu, un indicator pulsatoriu sau un loader rotitor), dar nu o opriți în viewDidDisappear, animația va consuma resurse GPU chiar şi când ecranul este ascuns. Păstrați întotdeauna o referință la animația activă şi apelați removeAllAnimations sau setCompletion în metoda corespunzătoare de finalizare a ciclului de viață.

A şaptea eroare — ignorarea viewDidDisappear pentru oprirea activităților. Dacă ați început ascultarea GPS, accelerometrului sau giroscopului în viewDidAppear, opriți-o neapărat în viewDidDisappear. În caz contrar, senzorii vor continua să funcționeze în fundal, consumând bateria, chiar şi dacă utilizatorul a trecut de mult pe un alt ecran. Utilizați apeluri pereche start şi stop în metodele corespunzătoare ale ciclului de viață — aceasta garantează gestionarea corectă a resurselor dispozitivului.