Frysning i utveckling — essens, orsaker och förebyggande

Vad är frysning i mobil utveckling

Frysning (freeze, hang) i en mobilapp — är ett tillstånd där appen slutar bearbeta inmatningshändelser och uppdatera gränssnittet under flera sekunder eller längre. Tekniskt innebär detta att huvudtråden (main thread) är blockerad och inte kan utföra nästa runner-cykel.

Skillnad mellan frysning, lag och ANR

Lag — en fördröjning på upp till 500 ms, där användaren märker långsamhet men appen fortsätter att fungera. Frysning varar från 1 sekund till tiotals sekunder. ANR på Android — är ett specialfall av frysning som varade längre än 5 sekunder och upptäcktes av systemet. Inte varje frysning leder till ANR, men varje ANR är en av systemet dokumenterad frysning.

Konsekvenser av frysning

På Android orsakar frysning längre än 5 sekunder en ANR-dialog med förslag att stänga appen. På iOS har systemet en watchdog — om appen inte reagerar på händelser inom 10–20 sekunder avslutar Watchdog processen med kod 0x8badf00d (ate bad food). Användaren ser bara att appen plötsligt stängs och återgår till startskärmen.

Orsaker till frysning på Android och iOS

Varje operation som varar längre än 100 ms och körs i huvudtråden kan potentiellt orsaka frysning. Låt oss titta på huvudkällorna till blockering.

Synkron in-utmatning i UI-tråden

Läsning av en stor fil, nätverksbegäran utan asynkronitet, lagring av data i SharedPreferences via synkron metod apply följt av commit — alla dessa operationer blockerar huvudtråden. På Android kan synkron läsning av en 10 MB fil ta 200–500 ms beroende på flashminnets hastighet. På iOS blockerar synkron URLSession-laddning utan completionHandler UI:t under serverns svarstid.

Deadlock i flertrådad kod

När två trådar väntar på frigöring av resurser som hålls av varandra uppstår deadlock. I mobilappar är det typiska scenariot — tråd A blockerar Lock1 och väntar på Lock2, medan tråd B blockerar Lock2 och väntar på Lock1. Båda trådarna fryser för evigt. Om en av dem är huvudtråden fryser appen helt.

Oändlig loop eller rekursion

Ett logikfel — till exempel while(true) utan utgångsvillkor eller rekursion utan basfall — leder till oändlig exekvering på huvudtråden. Android upptäcker detta via ANR efter 5 sekunder, iOS — via Stackshot, som registrerar en oändligt upprepande anropsstack.

• Android — Cursor utan stängning, synkron begäran via execute() istället för enqueue(), FileInputStream.read() i UI-tråden
• iOS — performSelectorOnMainThread:withObject:waitUntilDone:YES, start av NSURLConnection sendSynchronousRequest, laddning av bild med dataWithContentsOfURL
• Cross-platform — Flutter compute utan dedikerad isolate, React Native synkron NativeModule

Hur man diagnostiserar frysning

Diagnostik av frysning kräver verktyg som kan registrera tillståndet för alla trådar vid blockeringstillfället.

ANR-loggar på Android

Vid varje ANR sparar Android-systemet filen /data/anr/traces.txt, som innehåller stackdump för varje tråd i appen. Analys av denna fil — den huvudsakliga diagnostiska metoden: hitta main-tråden och se vilken metod den stoppades på. Om stacken slutar med Thread.sleep, InputStream.read eller Lock.lock — är orsaken funnen.

Stackshot på iOS

Xcode kan vid frysning av appen (signal SIGSTOP) ta en Stackshot — en ögonblicksbild av stackarna för alla trådar. Aktivera i schemat „Logging" → „Include Stackshot Logs". Vid krasch med kod 0x8badf00d, extrahera crashloggen från Devices & Simulators och hitta tråden com.apple.main-thread med fryst stack.

Main Thread Checker i Xcode

Main Thread Checker upptäcker automatiskt UIKit-anrop från bakgrundstrådar under appens körning. Aktivera det i schemat (Diagnostics → Main Thread Checker). Varje varning är en potentiell orsak till frysning, särskilt om den förekommer i avslutningen av en completionHandler för en nätverksbegäran.

Exempel på detektering av blockering via StrictMode på 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())
    }
}

Metoder för att åtgärda UI-blockering

Åtgärd av frysning börjar med att flytta alla potentiellt långa operationer till bakgrundstrådar. Låt oss titta på specifika tekniker för varje plattform.

Structured Concurrency med korutiner

Kotlin Coroutines med viewModelScope.launch(Dispatchers.IO) garanterar att nätverksoperationen eller databasläsningen körs i en bakgrundstråd. Dispatchers.Main används endast för att uppdatera UI. Viktigt: alla suspend-funktioner måste vara strukturerade — underordnade korutiner avbryts när föräldern avbryts, vilket förhindrar trådläckage.

Asynkrona köer på iOS

Grand Central Dispatch med DispatchQueue.global(qos: .userInitiated) för bakgrundsuppgifter och DispatchQueue.main.async för UI-uppdateringar — standardmönstret. Undvik sync() på huvudkön — detta är en garanterad deadlock. Använd async/await (Swift 5.5+) för mer läsbar asynkron kod med automatisk återgång till huvudtråden via MainActor.

Undvikande av synchronized i UI-tråden

synchronized-block i Kotlin och @synchronized i Swift på huvudtråden är farliga: om en annan tråd redan har tagit detta lås kommer huvudtråden att frysa i väntan. Använd atomära typer (AtomicInteger, atomära egenskaper i Swift) eller sekventiella köer istället för lås.

Exempel på asynkron dataladdning med korutiner på 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)
        }
    }
}

Förebyggande av frysning under utveckling

Systematiskt förebyggande av frysning hjälper med en kombination av verktyg, arkitektoniska principer och kodgranskningsprocesser.

StrictMode med penaltyDeath

Konfigurera StrictMode med penaltyDeath för trådpolicyer — detta leder till omedelbar krasch av appen vid upptäckt av nätverksanrop eller disk-I/O på huvudtråden. Utvecklaren kan inte ignorera problemet. I produktionsbygget använd penaltyLog för insamling av statistik utan krascher.

Main Thread Checker i Debug-schema

På iOS, aktivera Main Thread Checker i Debug-schemat och konfigurera CI att köra tester med detta alternativ. Om testet innehåller ett UIKit-anrop från en bakgrundstråd — bör det misslyckas. Detta är det enda pålitliga sättet att upptäcka problemet innan sändning till TestFlight.

Kodgranskning med kontroll av flertrådighet

Lägg till i kodgranskningsprocessen en obligatorisk punkt: kontrollera att varje nätverksanrop, filarbete, databasfråga eller tung beräkning utförs i en bakgrundstråd. Deadlock kan upptäckas med en statisk analysator: Infer från Facebook och Thread Safety Checker från Xcode hittar potentiella blockeringar före körning.

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