Înghețarea în dezvoltare — esență, cauze și prevenire

Ce este înghețarea în dezvoltarea mobilă

Înghețarea (freeze, hang) într-o aplicație mobilă — este starea în care aplicația încetează să proceseze evenimentele de intrare și să actualizeze interfața timp de câteva secunde sau mai mult. Tehnic, aceasta înseamnă că firul principal (main thread) este blocat și nu poate executa următorul ciclu al runner-ului.

Diferența dintre înghețare, lag și ANR

Lag — este o întârziere de până la 500 ms, în care utilizatorul observă încetinirea, dar aplicația continuă să funcționeze. Înghețarea durează de la 1 secundă la zeci de secunde. ANR pe Android — este un caz particular de înghețare care a durat mai mult de 5 secunde și a fost detectat de sistem. Nu orice înghețare duce la ANR, dar fiecare ANR este o înghețare documentată de sistem.

Consecințele înghețării

Pe Android, înghețarea mai lungă de 5 secunde declanșează dialogul ANR cu propunerea de a închide aplicația. Pe iOS, sistemul are un watchdog — dacă aplicația nu reacționează la evenimente timp de 10–20 de secunde, Watchdog termină procesul cu codul 0x8badf00d (ate bad food). Utilizatorul vede doar închiderea bruscă a aplicației și revenirea la ecranul principal.

Cauzele înghețării pe Android și iOS

Orice operație care durează mai mult de 100 ms și este lansată în firul principal poate provoca înghețarea. Să analizăm principalele surse de blocări.

Intrare-ieșire sincronă în firul UI

Citirea unui fișier mare, o cerere de rețea fără asincronizare, salvarea datelor în SharedPreferences prin metoda sincronă apply urmată de commit — toate aceste operații blochează firul principal. Pe Android, citirea sincronă a unui fișier de 10 MB poate dura 200–500 ms în funcție de viteza memoriei flash. Pe iOS, încărcarea sincronă URLSession fără completionHandler blochează UI pe durata răspunsului serverului.

Deadlock în codul multi-thread

Când două fire de execuție așteaptă eliberarea resurselor deținute reciproc, apare deadlock-ul. În aplicațiile mobile, scenariul tipic — firul A blochează Lock1 și așteaptă Lock2, iar firul B blochează Lock2 și așteaptă Lock1. Ambele fire îngheață pentru totdeauna. Dacă unul dintre ele este firul principal, aplicația îngheață complet.

Buclă infinită sau recursiune

O eroare de logică — de exemplu, while(true) fără condiție de ieșire sau recursiune fără caz de bază — duce la execuția infinită pe firul principal. Android detectează acest lucru prin ANR după 5 secunde, iOS — prin Stackshot, care înregistrează stiva de apeluri care se repetă la infinit.

• Android — Cursor neînchis, cerere sincronă prin execute() în loc de enqueue(), FileInputStream.read() în firul UI
• iOS — performSelectorOnMainThread:withObject:waitUntilDone:YES, lansarea NSURLConnection sendSynchronousRequest, încărcarea imaginii cu dataWithContentsOfURL
• Cross-platform — Flutter compute fără isolate dedicat, React Native NativeModule sincron

Cum să diagnosticați înghețarea

Diagnosticarea înghețării necesită instrumente capabile să înregistreze starea tuturor firelor în momentul blocării.

Loguri ANR pe Android

La fiecare ANR, sistemul Android salvează fișierul /data/anr/traces.txt, care conține dump-ul stivei fiecărui fir al aplicației. Analiza acestui fișier — principala metodă de diagnosticare: trebuie găsit firul main și văzut pe ce metodă s-a oprit. Dacă stiva se termină cu Thread.sleep, InputStream.read sau Lock.lock — cauza a fost găsită.

Stackshot pe iOS

Xcode, la înghețarea aplicației (semnal SIGSTOP), poate face un Stackshot — o imagine a stivelor tuturor firelor. Activați în schemă „Logging" → „Include Stackshot Logs". La căderea cu codul 0x8badf00d, extrageți logul de crash din Devices & Simulators și găsiți firul com.apple.main-thread cu stiva înghețată.

Main Thread Checker în Xcode

Main Thread Checker detectează automat apelurile UIKit din firele de fundal în timpul funcționării aplicației. Activați-l în schemă (Diagnostics → Main Thread Checker). Fiecare avertisment este o cauză potențială de înghețare, mai ales dacă apare în închiderea completionHandler a unei cereri de rețea.

Exemplu de detectare a blocării prin StrictMode pe Android:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        StrictMode.setVmPolicy(StrictMode.VmPolicy.Builder()
            .detectLeakedSqlLiteObjects()
            .detectLeakedClosableObjects()
            .penaltyLog()
            .build())
        StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyDeath()
            .build())
    }
}

Metode de eliminare a blocărilor UI

Eliminarea înghețării începe cu mutarea tuturor operațiilor potențial lungi în firele de fundal. Să analizăm tehnicile specifice pentru fiecare platformă.

Structured Concurrency cu corutine

Kotlin Coroutines cu viewModelScope.launch(Dispatchers.IO) garantează că operația de rețea sau citirea din baza de date se execută într-un fir de fundal. Dispatchers.Main este folosit doar pentru actualizarea UI. Important: toate funcțiile suspend trebuie să fie structurate — corutinele copil sunt anulate la anularea părintelui, prevenind scurgerea de fire.

Coadă asincronă pe iOS

Grand Central Dispatch cu DispatchQueue.global(qos: .userInitiated) pentru sarcini de fundal și DispatchQueue.main.async pentru actualizarea UI — modelul standard. Evitați sync() pe coada principală — acesta este un deadlock garantat. Folosiți async/await (Swift 5.5+) pentru un cod asincron mai lizibil, cu revenire automată la firul principal prin MainActor.

Evitarea synchronized în firul UI

Blocările synchronized în Kotlin și @synchronized în Swift pe firul principal sunt periculoase: dacă un alt fir a preluat deja această blocare, firul principal va îngheța în așteptare. Folosiți tipuri atomice (AtomicInteger, proprietăți atomice în Swift) sau cozi secvențiale în loc de blocări.

Exemplu de încărcare asincronă a datelor cu corutine pe Android:

class DataViewModel : ViewModel() {
    private val _data = MutableStateFlow<List<Item>>(emptyList())
    val data: StateFlow<List<Item>> = _data.asStateFlow()

    fun loadData() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = fetchFromNetwork()
            _data.emit(result)
        }
    }
}

Prevenirea înghețării în faza de dezvoltare

Prevenirea sistematică a înghețării ajută prin combinarea instrumentelor, principiilor arhitecturale și proceselor de revizuire a codului.

StrictMode cu penaltyDeath

Configurați StrictMode cu penaltyDeath pentru politicile de fire — aceasta va duce la căderea imediată a aplicației la detectarea unui apel de rețea sau a unei operații de intrare-ieșire pe disc în firul principal. Dezvoltatorul nu va putea ignora problema. În build-ul de producție, folosiți penaltyLog pentru colectarea statisticilor fără căderi.

Main Thread Checker în schema Debug

Pe iOS, activați Main Thread Checker în schema Debug și configurați CI să ruleze testele cu această opțiune. Dacă testul conține un apel UIKit dintr-un fir de fundal — trebuie să eșueze. Aceasta este singura modalitate sigură de a detecta problema înainte de trimiterea în TestFlight.

Revizuirea codului cu verificarea multi-threading-ului

Adăugați în procesul de revizuire a codului un punct obligatoriu: verificarea că orice apel de rețea, lucru cu fișiere, baza de date sau calcule grele se execută într-un fir de fundal. Deadlock-ul poate fi detectat cu un analizator static: Infer de la Facebook și Thread Safety Checker de la Xcode găsesc blocări potențiale înainte de execuție.

• Android — StrictMode, Infer, Android Lint Multithread, Kotlin Coroutines cu viewModelScope
• iOS — Main Thread Checker, TSAN (Thread Sanitizer), Xcode Analyze, Swift async/await cu MainActor
• Cross-platform — Flutter compute isolate, React Native interaction manager cu requestAnimationFrame