Mănâncă memorie și se umflă — ce este, cauze și cum să evităm

Ce este scurgerea de memorie și umflarea aplicației?

Scurgerea de memorie (memory leak) — situația în care un obiect care nu mai este necesar aplicației continuă să fie reținut în heap deoarece există o referință activă din setul rădăcină (GC Root). Colectorul de gunoi consideră un astfel de obiect viu și nu îl șterge.

Umflarea memoriei (memory bloat) — o problemă mai largă când aplicația consumă mai multă memorie decât este necesar pentru îndeplinirea sarcinilor curente. Cauze: cache excesiv, duplicarea obiectelor, structuri de date neoptimale și fragmentarea heap-ului.

În Android fiecărei aplicații i se alocă un heap limitat (de obicei 64-512 MB în funcție de dispozitiv și versiunea sistemului de operare). În iOS limitarea este mai puțin strictă, dar sistemul trimite un avertisment de memorie la apropierea de limită.

Conform Facebook Engineering Blog, scurgerile de memorie sunt cauza a ~15% din rapoartele de crash în aplicațiile mobile. În Android se adaugă ANR din cauza pauzelor frecvente GC la lipsa de memorie.

Modele tipice de scurgeri de memorie în Android și iOS

Referința statică la Activity — clasica scurgerilor Android. Dacă un câmp static sau un singleton stochează o referință la Activity, aceasta nu va fi colectată de GC nici după finish(), cât timp singletonul este viu. Activity este un obiect greu care conține ierarhia View, resurse și Context.

object LeakHolder {
    var activityRef: Activity ?= null // scurgere: referință statică la Activity
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ MainActivity nu va fi niciodată colectat de GC
    }
}

Clasele anonime și lambda — rețin implicit o referință la clasa exterioară. Dacă un Runnable sau Callback este transmis unui serviciu extern, iar Activity este distrus, obiectul clasei anonime încă atârnă în coadă și nu permite Activity să fie colectat de GC.

• Handler cu întârziere — dacă Activity este distrus, iar Handler.postDelayed nu a fost încă executat, Activity se scurge
• Thread și AsyncTask — la rotirea ecranului Activity este recreată, dar Thread-ul vechi continuă să rețină referința la Activity veche
• Retrofit/Callback — un Callback anonim reține referința la prezentator sau fragment
• Observatori (Observers) — abonamente LiveData sau RxJava fără dezabonare la onDestroy

În iOS problema principală sunt retain cycles: două obiecte rețin referințe puternice unul la altul, iar ARC nu poate zero contorul de referințe pentru niciunul. Caz tipic: un closure care capturează self puternic, iar self reține referința la closure.

Cum detectăm scurgerile de memorie?

LeakCanary — biblioteca de la Square pentru detectarea automată a scurgerilor în Android. După distrugerea Activity sau Fragment verifică dacă obiectul a fost colectat de GC. Dacă nu — face un heap dump și arată trace-ul scurgerii.

// LeakCanary 2.x — auto-integrare prin Application
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // LeakCanary se instalează automat în build-ul debug
        // prin ContentProvider — configurare zero cod
    }
}

// Apel de verificare forțată
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — instrumentul încorporat pentru monitorizarea memoriei în timp real. Permite înregistrarea heap dump, găsirea obiectelor suspecte (Retained Size > 1 MB) și urmărirea căii GC root până la fiecare obiect.

Pentru iOS utilizați Xcode Memory Graph Debugger. Acesta vizualizează graful obiectelor în memorie, arată retain cycles și permite detectarea instantanee a referințelor circulare. De asemenea, este disponibil Instruments > Allocations pentru monitorizare pe termen lung.

Strategii de prevenire a scurgerilor

WeakReference — mecanismul de bază pentru referințele care nu ar trebui să împiedice colectarea gunoiului. Dacă GC decide să șteargă obiectul, WeakReference returnează null. Folosit pentru callback-uri, listeneri și referințe la componente UI din firele de fundal.

Componentele Lifecycle-aware — abordarea arhitecturală implementată în Android Jetpack (Lifecycle, LiveData, Flow, coroutines). Abonamentele sunt anulate automat la onDestroy, ceea ce elimină clasa principală de scurgeri.

class MyViewModel : ViewModel() {
    private val _data = MutableLiveData<List<User>>()
    val data: LiveData<List<User>> get() = _data

    fun loadData() {
        viewModelScope.launch {
            val result = repository.fetchData()
            _data.postValue(result)
            // corutina se anulează automat la onCleared()
        }
    }
}

viewModelScope și lifecycleScope — CoroutineScope încorporate în Android care sunt anulate la evenimentul corespunzător al ciclului de viață. Aceasta elimină scurgerile prin corutine — cel mai frecvent scenariu în dezvoltarea modernă Android.

• Nu utilizați referințe statice la Context, Activity, View sau Fragment
• Anulați toate abonamentele RxJava în disposeBag / CompositeDisposable la onDestroy
• Utilizați [weak self] / [unowned self] în closure-urile iOS pentru prevenirea retain cycles
• Verificați Bitmap-urile și obiectele mari — trebuie reciclate sau anulate

Instrumente de profilare a memoriei

Memory Profiler in Android Studio — instrumentul principal pentru monitorizarea heap-ului. Afișează alocări live, instantanee heap, numărul de obiecte pe tipuri. Permite înregistrarea unui dump și analiza acestuia în MAT (Memory Analyzer Tool) pentru găsirea obiectelor suspecte.

Eclipse MAT — analizor desktop de heap dump. După încărcarea fișierului HPROF din Android Studio, MAT construiește arborele dominator, arată retain size al fiecărui obiect și oferă analiză automată a scurgerilor suspecte prin Leak Suspects Report.

Xcode Memory Graph — debugger vizual pentru retain cycles. La apăsarea butonului Memory Graph Debugger, Xcode oprește aplicația, construiește graful complet al obiectelor în memorie și evidențiază retain cycles cu roșu.

Conform Google I/O 2023, aplicațiile care folosesc LeakCanary în build-urile de debug reduc numărul de crash-uri legate de memorie cu 30-50% în primele 2 luni după implementare. Se recomandă adăugarea LeakCanary în faza de onboarding a proiectului.