OutOfMemoryError în dezvoltarea aplicațiilor: ce este, cauzele și metode de prevenire

Ce este OutOfMemoryError

OutOfMemoryError (OOM) — este o excepție din familia VirtualMachineError în Java/Kotlin care semnalează imposibilitatea de a aloca memorie pentru un obiect nou. Spre deosebire de excepțiile checked, OOM este o eroare (Error) și nu necesită gestionare prin catch — deși tehnic poate fi prinsă. După apariția OOM, aplicația se află de obicei într-o stare instabilă și se recomandă să fie închisă.

Pe Android, fiecare aplicație are o limită Heap stabilită de producătorul dispozitivului. Pentru smartphone-urile moderne cu 6+ GB RAM, limita este de 256–512 MB, pentru dispozitivele bugetare — 128–192 MB. Când volumul total al tuturor obiectelor active depășește această limită, ART aruncă OutOfMemoryError.

Important de înțeles: OOM nu înseamnă întotdeauna că memoria fizică a dispozitivului s-a terminat. Înseamnă că aplicația și-a epuizat limita Heap stabilită de sistem. Alte aplicații pot avea memorie liberă, dar aplicația ta nu o poate folosi din cauza izolării proceselor în Android.

Principalele cauze ale OutOfMemoryError

Cinci scenarii duc în mod regulat la OOM în aplicațiile mobile. Fiecare scenariu este legat de un anumit tip de date sau operație.

Bitmap fără scalare

Bitmap — principalul consumator de memorie în aplicațiile Android. Încărcarea unei imagini FullHD (1920 × 1080) în dimensiunea originală ocupă 8.3 MB în format ARGB_8888. Dacă în RecyclerView sunt 50 de astfel de imagini — aceasta înseamnă 415 MB, ceea ce depășește Heap-ul oricărui dispozitiv. Încărcarea imaginilor fără inSampleSize — OOM garantat pe dispozitivele slabe.

Folosește Glide sau Coil pentru scalare automată. Aceste biblioteci încarcă imagini la o dimensiune corespunzătoare View-ului, nu rezoluției originale. Pentru utilizarea directă a BitmapFactory.Options, aplică inSampleSize: calculează-l ca putere a lui doi, astfel încât dimensiunea finală să nu depășească 2048 × 2048 pixeli. Suplimentar, folosește RGB_565 în loc de ARGB_8888 pentru imagini fără transparență — aceasta reduce consumul de memorie la jumătate.

fun loadScaledBitmap(path: String, reqWidth: Int): Bitmap? {
    val opts = BitmapFactory.Options().apply {
        inJustDecodeBounds = true
    }
    BitmapFactory.decodeFile(path, opts)
    opts.inSampleSize = calculateSampleSize(opts.outWidth, reqWidth)
    opts.inJustDecodeBounds = false
    return BitmapFactory.decodeFile(path, opts)
}

Scurgeri de memorie (acumulare)

O scurgere de câțiva KB nu va cauza OOM. Dar zeci de scurgeri pe fiecare ecran se acumulează: fiecare tranziție la un ecran adaugă o scurgere, GC nu poate elibera obiectele, Heap se umple. Modelul tipic: utilizatorul deschide și închide ecranul de profil de 20 de ori → Heap crește cu 200 MB → aplicația crapă cu OOM.

Instalează LeakCanary în proiect pentru detectarea automată a scurgerilor. Acesta va arăta fiecare obiect scurs cu un stack trace exact. După remedierea tuturor scurgerilor, consumul Heap devine stabil: după închiderea ecranului, memoria revine la nivelul de bază.

Fișiere mari în memorie

Încărcarea fișierelor în totalitate în byte[] — calea directă către OOM. Un fișier JSON de 50 MB la parsare va crea un șir de aceeași dimensiune plus modelul DOM. Fișierele video încărcate în memorie, bufferele audio și seturile mari de date protobuf — toate pot depăși limita Heap într-o singură operație.

Procesează datele mari cu fluxuri: InputStream cu buffer de 4–8 KB, parser JSON streaming (Jackson sau Gson cu JsonReader), MediaCodec pentru video. Nu apela niciodată File.readBytes() pe fișiere mai mari de 10% din Heap-ul disponibil.

Crearea multor obiecte în buclă

Crearea intensivă de obiecte în buclă fără GC intermediar poate duce la OOM, în special pe dispozitive cu Heap mic. Exemplu: generarea a 100.000 de obiecte într-o buclă for care nu încap în Heap până când GC apucă să le colecteze. Aceasta este mai frecventă în jocuri și editoare grafice.

Folosește Object Pool pentru obiectele care sunt create și distruse în masă. Pentru date numerice, folosește tipuri primitive (FloatArray în loc de List<Float>). RecyclerView cu ViewHolder Pool rezolvă această problemă pentru componentele UI.

Fragmentarea Heap

Fragmentarea — starea în care memoria liberă este suficientă în total, dar nu există un bloc continuu pentru un obiect nou. ART compactează Heap-ul în timpul GC, dar nu întotdeauna cu succes. Tablourile mari (Bitmap, byte[]) sunt cele mai sensibile la fragmentare.

ART pe Android 8+ folosește Generational GC, care reduce fragmentarea prin separarea obiectelor tinere și vechi. Cu toate acestea, evită alocarea de fragmente de dimensiuni diferite în aceeași zonă — încearcă să folosești buffere pre-alocate de dimensiune fixă.

Limitele Heap în Android

Limita Heap în Android nu este o constantă — depinde de producător, modelul dispozitivului și versiunea OS. Google stabilește cerințele minime prin Compatibility Definition Document (CDD), dar producătorii stabilesc valorile reale.

Poți solicita o limită mărită prin android:largeHeap="true" în manifest. Folosește-l cu prudență: creșterea Heap nu rezolvă problema scurgerilor și poate înrăutăți experiența utilizatorului dacă sistemul este forțat să ucidă alte aplicații pentru a elibera memorie pentru a ta. Pentru Wear OS, limita Heap este minimă — doar 32–64 MB, aici largeHeap nu este disponibil, iar economisirea memoriei este dublu de critică.

Diagnosticarea OutOfMemoryError

Diagnosticarea OOM necesită analiza Heap Dump și înțelegerea care obiecte consumă memorie. Android Studio oferă toate instrumentele necesare.

Pasul 1: Prinde momentul OOM. În Android Memory Profiler, apasă Record memory allocations și execută scenariul care cauzează crash-ul. Profilerul va arăta saltul de alocări înainte de OOM. Dacă OOM nu se reproduce, reduce Heap-ul prin android:smallHeap în build-ul de debug sau folosește DDMS cu apel manual GC.

Pasul 2: Fă un Heap Dump în momentul de sarcină maximă (înainte de OOM). Deschide Dump-în Android Studio: fila Classes sortată după Retained Size. Cele mai mari obiecte — Bitmap, byte[], String. Pentru fiecare Bitmap, verifică dimensiunea (width × height × 4 octeți) și calea de încărcare prin Stack Trace.

Pasul 3: Analizează numărul de obiecte repetate. Dacă vezi 200 de Fragment sau Activity identice — este o scurgere. Dacă 500 de Bitmap cu aceeași dimensiune — problemă de cache a imaginilor. MAT (Memory Analyzer Tool) oferă o analiză mai profundă cu Dominator Tree, arătând care obiecte rețin 80% din Heap.

// Comanda pentru Heap Dump prin adb
adb shell am dumpheap com.example.app /data/local/tmp/dump.hprof
adb pull /data/local/tmp/dump.hprof.

Strategii de prevenire a OOM

O strategie complexă de prevenire a OOM include cinci niveluri de protecție: de la soluții arhitecturale până la monitorizare în producție.

Soluții arhitecturale

ViewModel + Repository — modelul separă datele de UI și previne reținerea View-ului la rotirea ecranului. ViewModel supraviețuiește Activity, datele sale nu se pierd, iar View poate fi recreat fără duplicarea datelor în memorie. Folosește StateFlow în loc de LiveData pentru gestionarea explicită a stărilor.

Gestionarea Bitmap și a imaginilor

Glide — biblioteca obligatorie pentru lucrul cu imagini. Aceasta scalează automat, face cache (disc + memorie) și reciclează Bitmap. Configurează diskCacheStrategy și skipMemoryCache pentru liste mari. Pentru imagini animate, folosește Glide cu GIF/WebP — ocupă mai puțină memorie decât o secvență de Bitmap.

Monitorizare în producție

Firebase Performance Monitoring urmărește consumul de memorie în timp real. Setează o alertă la ocuparea Heap de peste 80% din limită — acesta este un semnal de verificare. Crashlytics colectează OOM ca excepție și arată ultima stare cunoscută a Heap-înainte de crash. Pentru Android 11+, folosește ApplicationExitInfo pentru detectarea terminărilor OOM.

Testarea pe dispozitive slabe

Testează obligatoriu aplicația pe dispozitive cu Heap minim (128–192 MB). Emulatorul cu ecran mic și Heap mic simulează un dispozitiv bugetar. Dacă aplicația funcționează pe un astfel de dispozitiv, pe flagship-uri nu vor fi probleme cu OOM. Folosește Firebase Test Lab cu dispozitive reale din diferite categorii de preț.

// Verificarea Heap-ului disponibil înainte de o operație grea
fun canAllocate(requiredBytes: Long): Boolean {
    val runtime = Runtime.getRuntime()
    val free = runtime.freeMemory()
    return free > requiredBytes * 2 // rezervă 50%
}