Speicherleck: Was es ist, typische Szenarien und Diagnose

Was ist ein Speicherleck in mobilen Anwendungen?

Speicherleck — eine Situation, in der zugewiesener Speicher nicht an das System zurückgegeben wird, nachdem das Objekt vom Programm nicht mehr benötigt wird. Der Garbage Collector betrachtet ein solches Objekt als lebendig, weil eine aktive Referenzkette von einem GC Root darauf zeigt.

In Java/Kotlin arbeitet der Garbage Collector automatisch, kann aber nicht feststellen, dass ein Objekt logisch nicht mehr benötigt wird, wenn eine technische Referenz darauf existiert. Der Entwickler muss unnötige Verbindungen explizit trennen. In Swift/Objective-C zählt ARC automatisch Referenzen, aber Retain Cycles blockieren das Nullwerden des Zählers.

Die Hauptgefahr von Lecks ist der kumulative Effekt. Jedes Leck verbraucht eine kleine Menge Speicher, aber bei wiederholten Bildschirmwechseln (Bildschirmdrehung, Öffnen/Schließen von Activities) sammeln sich Lecks an, bis das Heap-Limit erschöpft ist.

Wie unterscheidet sich ein Leck von Aufblähung?

Leck — das Objekt ist für den Code unzugänglich, wird aber nicht vom GC entfernt. Aufblähung — das Objekt ist logisch erforderlich, wird aber in übermäßiger Menge gespeichert. Beispiel für Aufblähung: ein Bildercache von 100 MB bei einem Arbeitssatz von 30 MB. Beide Probleme führen zu OOM, aber die Ursachen und Behandlungsmethoden sind unterschiedlich.

Wie funktioniert der Garbage Collector und warum entstehen Lecks?

ART (Android Runtime) verwendet generationsbasierte Garbage Collection mit gleichzeitiger Kompaktierung. Der Speicher wird in junge Generation (Young), alte Generation (Old) und große Objekte (Large) unterteilt. Objekte, die mehrere GC-Zyklen überleben, werden in die Old-Generation verschoben, wo die Sammlung seltener erfolgt — dies beschleunigt normale Zyklen.

Der GC startet, wenn der Heap einen bestimmten Auslastungsschwellenwert (normalerweise 75-85%) erreicht. Während des GC werden alle Anwendungsthreads angehalten (STW — Stop The World). Je mehr lebende Objekte, desto länger die Pause. Lecks erhöhen die Anzahl der lebenden Objekte und verlängern die GC-Pausen.

Der Collector bestimmt lebende Objekte, indem er den Graphen von den GC Roots aus durchläuft: statische Felder, Stapelvariablen aktiver Threads, JNI-Referenzen. Jedes Objekt, das über Referenzen von diesen Wurzeln aus erreichbar ist, gilt als lebendig — selbst wenn der Entwickler weiß, dass es nicht mehr benötigt wird.

// Beispiel: statische Sammlung als GC Root — permanentes Leck
object GlobalHolder {
    val listeners = mutableListOf<WeakReference<Any>>()
}

class LeakingFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        GlobalHolder.listeners.add(WeakReference(this))
        // WeakReference verhindert GC nicht — korrektes Verhalten
    }
}

WeakReference löst das Problem: Der GC ignoriert schwache Referenzen bei der Bestimmung lebender Objekte. Wenn nur noch schwache Referenzen auf ein Objekt verweisen, wird es im nächsten GC-Zyklus eingesammelt.

Typische Leck-Szenarien in Android und iOS

Activity Context — das massivste Leck-Szenario in Android. Wenn ein Singleton, ein statisches Feld oder ein langlebiger Dienst eine Referenz auf einen Activity Context speichert, kann die gesamte Activity mit allen Views nicht vom GC eingesammelt werden. Lösung: Verwenden Sie Application Context für langlebige Objekte.

Handler und gesendete Nachrichten — Handler.postDelayed(runnable, delay) stellt eine Nachricht in die Warteschlange des Main Looper. Wenn die Activity vor Ablauf der Verzögerung zerstört wird, ist die Nachricht noch in der Warteschlange und hält eine Referenz über Runnable → anonyme Klasse → äußere Klasse (Activity).

class SafeActivity : AppCompatActivity() {
    private val mainHandler = Handler(Looper.getMainLooper())
    private val callback = Runnable { /* update UI */ }

    override fun onResume() {
        super.onResume()
        mainHandler.postDelayed(callback, 5000)
    }

    override fun onPause() {
        mainHandler.removeCallbacks(callback) // erforderlich: Warteschlange leeren
        super.onPause()
    }
}

Innere Klassen — eine nicht-statische innere Klasse hat eine implizite Referenz auf die Instanz der äußeren Klasse. Wenn die äußere Klasse eine Activity ist und die innere Klasse nach außen übergeben wird (z.B. an RecyclerView.Adapter), kann die Activity nicht eingesammelt werden.

• TimerTask und ScheduledExecutorService — vor der Zerstörung der Activity geplante Aufgaben
• BroadcastReceiver — nicht in onPause/onDestroy abgemeldet, hält weiterhin den Context
• ViewModel mit View-Referenz — ViewModel überlebt die Activity, Referenz auf die View führt zu Leck
• Retrofit Call — wenn Call nicht abgebrochen wird, kommt die Antwort bei zerstörtem Fragment an

Diagnosetools für Speicherlecks

Android Studio Memory Profiler — integriertes Tool für Echtzeit-Heap-Überwachung. Zeigt ein Diagramm des belegten Speichers, die Anzahl der Allokationen und Objekte nach Typ. Ermöglicht die Aufnahme eines Heap Dumps und den Export im HPROF-Format für die Analyse in MAT.

Eclipse MAT (Memory Analyzer Tool) — Desktop-Analyzer für Heap Dumps. Erstellt automatisch Leak Suspects Reports, die Objekte mit der größten retained size hervorheben und für jedes verdächtige Objekt eine vermutete GC-Root-Chain vorschlagen.

Xcode Memory Graph Debugger — für iOS. Hält die Anwendung an und visualisiert den Objektgraphen. Retain Cycles werden rot hervorgehoben; Sie können auf jedes Objekt klicken, um seine Retain Count und Referenzen zu sehen.

Laut Uber Engineering Blog reduziert die Integration von automatischem Speicher-Profiling (LeakCanary + Heap-Dump-Analyse) in die CI/CD-Pipeline speicherbezogene Vorfälle in der Produktion innerhalb von 3 Monaten um 60%.

Methoden zur Beseitigung von Lecks

Context ersetzen — wenn ein Objekt die Activity überlebt, verwenden Sie applicationContext. Alle langlebigen Objekte (Singletons, Repositories, Datenbank-Helfer) sollten Application Context erhalten, nicht Activity Context. Ausnahme: UI-Komponenten, die Zugriff auf das theme oder Activity-spezifische Ressourcen benötigen.

Lifecycle-aware Komponenten — die Verwendung von LifecycleObserver, DefaultLifecycleObserver oder reaktiven Erweiterungen bricht Abonnements automatisch bei onDestroy ab. Android Jetpack bietet lifecycleScope und viewModelScope, die durch das entsprechende Lebenszyklusereignis bereinigt werden.

Statische innere Klasse — wenn die innere Klasse keinen Zugriff auf die Felder der äußeren Klasse benötigt, machen Sie sie static. Eine statische innere Klasse hat keine implizite Referenz auf die äußere Klasse. Wenn Zugriff benötigt wird, verwenden Sie WeakReference für die explizite Referenz.

class MyActivity : AppCompatActivity() {

    // ❌ Nicht-statische innere Klasse — implizite Referenz auf MyActivity
    inner class BadListener : SomeListener {
        override fun onEvent() { /*...*/ }
    }

    // ✅ Statische innere Klasse — keine implizite Referenz
    class GoodListener(private val activityRef: WeakReference<MyActivity>) : SomeListener {
        override fun onEvent() { /*...*/ }
    }
}

Verwenden Sie in iOS Capture Lists: [weak self] in Closures, die ihren Ersteller überleben können. Für Delegates verwenden Sie schwache Referenzen (weak var delegate). Für Closures, die garantiert nur während der Lebensdauer von self aufgerufen werden, kann [unowned self] verwendet werden, aber mit Vorsicht — der Zugriff auf ein freigegebenes Objekt führt zu einem Absturz.