Zacina się w programowaniu — co to jest, przyczyny i metody optymalizacji

Co znaczy „zacina się” w programowaniu mobilnym

Zacina się — nieformalny termin, którym użytkownicy opisują subiektywnie wolne działanie aplikacji. W przeciwieństwie do laga, który objawia się jako stałe opóźnienie, zacięcie to nieregularne zawieszanie: aplikacja może działać idealnie przez kilka sekund, a następnie „zamyślić się” na 1–3 sekund.

Charakterystyka techniczna zjawiska

Z punktu widzenia profilowania, zacina się objawia się jako seria pominiętych klatek (jank) z szczytowymi opóźnieniami powyżej 100 ms. Na wykresie FPS wygląda to jak gwałtowne spadki: 60 → 20 → 55 → 10 klatek na sekundę. W przeciwieństwie do laga z równomiernie niskim FPS, zacięcie ma wyraźną zmienność.

Postrzeganie przez użytkownika

Gdy aplikacja się zacina, użytkownik nie rozumie logiki spowolnień: ekran może przewijać się płynnie, a następnie nagle zatrzymać się na sekundę. Powoduje to frustrację i obniża zaufanie do aplikacji. Według Google, 53% użytkowników opuszcza stronę lub aplikację, jeśli ładowanie trwa dłużej niż 3 sekundy.

Przyczyny nagłych spowolnień w aplikacjach

Nieregularny charakter zacięć wskazuje, że problem jest spowodowany czynnikami zdarzeniowymi, a nie stałym przeciążeniem. Rozważmy typowe scenariusze.

Pauzy GC podczas alokacji obiektów

Na Android w środowisku ART zbieranie śmieci zatrzymuje wszystkie wątki aplikacji. Jeśli w kodzie tworzonych jest wiele tymczasowych obiektów — na przykład przy każdym wywołaniu onBindViewHolder tworzony jest nowy String przez konkatenację — GC uruchamia się częściej. Pauza może trwać 5–50 ms w zależności od rozmiaru sterty i pokolenia obiektów. Użytkownik odczuwa to jako nagłe „zamyślenie”.

Synchroniczne zapytania SQL w wątku UI

Room na Android i Core Data na iOS obsługują zapytania asynchroniczne, ale programiści często wywołują getValue() lub wykonują zapytanie przez runBlocking dla uproszczenia. Ciężki SELECT z joinami na tabeli z 10 000 wierszy może zająć 200–500 ms, całkowicie blokując UI na ten czas.

Dekodowanie obrazu bez downscale

Załadowanie obrazu z aparatu (12 Mp, 4000x3000 px) bez skalowania zajmuje do 200 ms na dekodowanie do Bitmap. Jeśli obrazy są ładowane asynchronicznie, ale bez puli wątków z ograniczeniem, jednoczesne uruchomienie 5–6 dekodowań może przeciążyć CPU, powodując migrujące spowolnienia.

• Android — konkatenacja stringów w pętlach, tworzenie obiektów w gorących ścieżkach, Bitmap bez inSampleSize
• iOS — pule autorelease z dużą liczbą obiektów, imageWithContentsOfFile bez skalowania, synchroniczne URLSession
• Cross-platform — parsowanie JSON w wątku UI, ładowanie danych w głównym wątku z oczekiwaniem na odpowiedź serwera

Jak diagnozować zawieszanie się na Android i iOS

Diagnostyka nieregularnych spowolnień jest trudniejsza niż diagnostyka stałych lagów, ponieważ problem może nie występować w każdym uruchomieniu. Wymagane jest zbieranie statystyk przez dłuższy okres.

Memory Profiler z zapisem zdarzeń GC

Android Studio Memory Profiler pokazuje nie tylko użycie pamięci, ale także zdarzenia GC: częstotliwość, typ (Concurrent, Full), czas trwania. Jeśli GC występuje częściej niż 1 raz na 5 sekund w stanie spokojnym — to oznaka nadmiernej alokacji. Zapis heap dump w momencie zacięcia pozwala zobaczyć, które obiekty zajmują pamięć.

Xcode Instruments z Allocation Tracking

Na iOS użyj szablonu Allocations w Instruments do śledzenia tworzenia i zwalniania obiektów. Włącz generacje (Generations) — pozwalają one na robienie zrzutów sterty między akcjami i widzenie, które obiekty pozostają w pamięci. Persistent objects, które nie są zwalniane — źródło gromadzenia pamięci i późniejszych pauz.

JankStats API na Android

JankStats — biblioteka Androida, która zbiera metryki pominiętych klatek w czasie rzeczywistym. Wiąże każdy jank z bieżącym scenariuszem (np. „przewijanie listy”, „otwieranie ekranu”), co pozwala zrozumieć, przy której konkretnie czynności występuje zacięcie.

Przykład integracji JankStats do śledzenia zawieszeń na 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("Zacinanie", "Duration=${frameData.durationMs}ms")
            }
        }
    }
}

Metody eliminowania wolnego działania

Eliminacja zacięć wymaga celowej pracy z każdą przyczyną. Nie ma uniwersalnego rozwiązania — potrzebna jest analiza konkretnych profili wydajności.

Wprowadzenie paginacji przez Paging 3

Jeśli lista zawiera 1000+ elementów i wszystkie są ładowane od razu — to gwarantowane zacięcie. Paging 3 na Android i NSFetchedResultsController na iOS ładują dane porcjami podczas przewijania. Użytkownik widzi tylko pierwsze 10–20 elementów, reszta jest ładowana w tle.

Optymalizacja zapytań SQL i indeksów

Room pozwala profilować zapytania przez Inspection Tool w Android Studio: widać czas wykonania, liczbę zwróconych wierszy i plan zapytania. Dodanie indeksów na kolumny WHERE i ORDER BY może skrócić czas zapytania z 300 ms do 5 ms. Na iOS analogiczne sprawdzenie wykonuje Core Data Profiler w Instruments.

Przeniesienie zadań do WorkManager

Synchronizacje w tle, ładowanie plików, przetwarzanie danych — wszystko to powinno być wykonywane przez WorkManager (Android) lub Background Tasks (iOS). Jeśli synchronizacja jest uruchamiana w wątku UI, aplikacja będzie się zacinać na czas wykonania. WorkManager gwarantuje wykonanie w wątku tła z uwzględnieniem stanu baterii i sieci.

Przykład synchronizacji w tle przez WorkManager na Android:

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

    override suspend fun doWork(): Result {
        return try {
            Log.d("Sync", "Synchronizacja danych w wątku tła")
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Profilaktyka zacięć na etapie programowania

Zapobiec zacięciom można na etapie pisania kodu, przestrzegając zasad efektywnej pracy z pamięcią i wątkami.

Baseline Profiles do kompilacji AOT

Baseline Profiles — to lista klas i metod, które Android kompiluje z góry (AOT), a nie JIT. Bez profilu każdy nowy ekran jest kompilowany przy pierwszym otwarciu, powodując opóźnienie 100–500 ms. Przygotuj Baseline Profile dla kluczowych ekranów i włącz generację w Gradle przez baseline-profile-gradle-plugin.

Minimalizacja alokacji w gorących ścieżkach

Hot path — to kod, który wykonuje się przy każdej klatce: onBindViewHolder, draw, layoutSubviews. Unikaj tworzenia obiektów w tych metodach: używaj puli obiektów, StringBuilder zamiast konkatenacji, cache'uj sformatowane stringi i formaty. Każda dodatkowa alokacja przybliża następny GC.

Profilowanie przez Baseline Profiles w CI

Dodaj do pipeline'u CI uruchomienie Macrobenchmark ze scenariuszem przewijania listy i otwierania ekranu. Ustaw próg: 99. percentyl czasu klatki nie powinien przekraczać 16 ms. Jeśli próg jest przekroczony — build jest odrzucany do czasu optymalizacji.

• Android — Baseline Profiles, Macrobenchmark, JankStats, StrictMode z penaltyDeath
• iOS — MetricKit, os_signpost, XCTMetric, Main Thread Checker w schemacie Debug
• Ogólne podejście — regularne profilowanie, code review z naciskiem na alokacje w gorących ścieżkach