Hackar i utveckling — vad är det, orsaker och optimeringsmetoder

Vad betyder "hackar" i mobil utveckling

Hackar — en informell term som användare använder för att beskriva subjektivt långsam app-prestanda. Till skillnad från lag, som manifesterar sig som en konstant fördröjning, är hackande oregelbundna frysningar: appen kan fungera perfekt i några sekunder och sedan "tänka" i 1–3 sekunder.

Teknisk karakteristik av fenomenet

Ur profileringssynpunkt manifesterar sig hackande som en serie missade bildrutor (jank) med toppfördröjningar över 100 ms. På FPS-grafen ser detta ut som kraftiga fall: 60 → 20 → 55 → 10 bildrutor per sekund. Till skillnad från lag med jämnt låg FPS har hackande tydlig variabilitet.

Användarens uppfattning

När appen hackar förstår användaren inte logiken bakom inbromsningarna: skärmen kan scrolla smidigt och sedan plötsligt stanna i en sekund. Detta orsakar frustration och minskar förtroendet för appen. Enligt Google lämnar 53% av användarna en webbplats eller app om laddningen tar längre tid än 3 sekunder.

Orsaker till plötsliga inbromsningar i appar

Den oregelbundna karaktären av hackande indikerar att problemet orsakas av händelsefaktorer, inte konstant överbelastning. Låt oss titta på typiska scenarier.

GC-pauser vid objektallokering

På Android i ART-miljön stoppar skräpinsamling alla appens trådar. Om många tillfälliga objekt skapas i koden — till exempel vid varje anrop av onBindViewHolder skapas en ny String genom konkatenation — startar GC oftare. Pausen kan vara 5–50 ms beroende på heap-storlek och objektgeneration. Användaren upplever detta som plötsligt "tänkande".

Synkrona SQL-frågor i UI-tråden

Room på Android och Core Data på iOS stöder asynkrona frågor, men utvecklare anropar ofta getValue() eller utför frågor via runBlocking för enkelhetens skull. En tung SELECT med joins på en tabell med 10 000 rader kan ta 200–500 ms och helt blockera UI under den tiden.

Bildavkodning utan downscale

Att ladda en kamerabild (12 Mp, 4000x3000 px) utan skalning tar upp till 200 ms att avkoda till Bitmap. Om bilder laddas asynkront men utan en begränsad trådpool kan samtidig start av 5–6 avkodningar överbelasta CPU, vilket orsakar migrerande inbromsningar.

• Android — strängkonkatenation i loopar, objektskapande i heta vägar, Bitmap utan inSampleSize
• iOS — autorelease-pooler med många objekt, imageWithContentsOfFile utan skalning, synkron URLSession
• Cross-platform — JSON-tolkning i UI-tråden, dataladdning i huvudtråden med väntan på serversvar

Hur man diagnostiserar frysningar på Android och iOS

Diagnostik av oregelbundna inbromsningar är svårare än diagnostik av konstanta lag, eftersom problemet kanske inte uppträder vid varje start. Insamling av statistik under en längre period krävs.

Memory Profiler med inspelning av GC-händelser

Android Studio Memory Profiler visar inte bara minnesanvändning utan även GC-händelser: frekvens, typ (Concurrent, Full), varaktighet. Om GC inträffar mer än 1 gång per 5 sekunder i vilotillstånd — detta är ett tecken på överdriven allokering. Inspelning av heap dump vid hackningsögonblicket gör det möjligt att se vilka objekt som upptar minne.

Xcode Instruments med Allocation Tracking

På iOS använder du mallen Allocations i Instruments för att spåra skapande och frigörande av objekt. Aktivera generationer (Generations) — de gör det möjligt att ta ögonblicksbilder av heap mellan åtgärder och se vilka objekt som finns kvar i minnet. Beständiga objekt som inte frigörs — källa till minnesackumulering och efterföljande pauser.

JankStats API på Android

JankStats — Android-bibliotek som samlar in metriker för missade bildrutor i realtid. Den knyter varje jank till det aktuella scenariot (t.ex. "listrullning", "skärmöppning"), vilket gör det möjligt att förstå vid vilken specifik åtgärd hackandet uppstår.

Exempel på JankStats-integration för att spåra frysningar på Android:

class MainActivity : AppCompatActivity() {
    private lateinit var jankStats: JankStats

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        jankStats = JankStats.create(this.window.decorView) { frameData ->
            if (frameData.isJank()) {
                Log.w("Jank", "Duration=${frameData.durationMs}ms")
            }
        }
    }
}

Metoder för att eliminera långsam prestanda

Att eliminera hackande kräver riktat arbete med varje orsak. Det finns ingen universallösning — analys av specifika prestandaprofiler krävs.

Implementera paginering via Paging 3

Om listan innehåller 1000+ element och alla laddas på en gång — detta är garanterat hackande. Paging 3 på Android och NSFetchedResultsController på iOS laddar data i portioner under rullning. Användaren ser bara de första 10–20 elementen, resten laddas i bakgrunden.

Optimera SQL-frågor och index

Room tillåter profilering av frågor via Inspection Tool i Android Studio: exekveringstid, antal returnerade rader och frågeplan syns. Att lägga till index på WHERE- och ORDER BY-kolumner kan minska frågetiden från 300 ms till 5 ms. På iOS utförs en liknande kontroll av Core Data Profiler i Instruments.

Överföring av uppgifter till WorkManager

Bakgrundssynkroniseringar, filuppladdningar, databearbetning — allt detta bör utföras via WorkManager (Android) eller Background Tasks (iOS). Om synkronisering startas i UI-tråden kommer appen att hacka under exekvering. WorkManager garanterar exekvering i bakgrundstråden med hänsyn till batteri- och nätverksstatus.

Exempel på bakgrundssynkronisering via WorkManager på Android:

class SyncWorker(context: Context, params: WorkerParameters)
    : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            Log.d("Sync", "Synkronisera data i bakgrundstråd")
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Förebyggande av hackande i utvecklingsfasen

Hackande kan förebyggas i kodningsfasen genom att följa principerna för effektivt arbete med minne och trådar.

Baseline Profiles för AOT-kompilering

Baseline Profiles — lista över klasser och metoder som Android kompilerar i förväg (AOT), inte JIT. Utan profil kompileras varje ny skärm vid första öppningen, vilket orsakar en fördröjning på 100–500 ms. Förbered Baseline Profile för viktiga skärmar och aktivera generering i Gradle via baseline-profile-gradle-plugin.

Minimera allokeringar i heta vägar

Hot path — kod som exekveras vid varje bildruta: onBindViewHolder, draw, layoutSubviews. Undvik att skapa objekt i dessa metoder: använd en objektpool, StringBuilder istället för konkatenation, cache:a formaterade strängar och formaterare. Varje extra allokering närmar nästa GC.

Profilering via Baseline Profiles i CI

Lägg till i CI-pipelinen att köra Macrobenchmark med scenario för listrullning och skärmöppning. Sätt ett tröskelvärde: 99:e percentilen av bildrutetiden får inte överstiga 16 ms. Om tröskeln överskrids — bygget avvisas tills optimering.

• Android — Baseline Profiles, Macrobenchmark, JankStats, StrictMode med penaltyDeath
• iOS — MetricKit, os_signpost, XCTMetric, Main Thread Checker i Debug-schemat
• Allmänt tillvägagångssätt — regelbunden profilering, kodgranskning med fokus på allokeringar i heta vägar