Speicherlecks und Blähung — was es ist, Ursachen und wie man es vermeidet

Was ist ein Speicherleck und eine App-Blähung?

Speicherleck — eine Situation, in der ein Objekt, das die App nicht mehr benötigt, weiterhin im Heap gehalten wird, weil eine aktive Referenz aus dem GC-Root-Set noch darauf zeigt. Der Garbage Collector betrachtet ein solches Objekt als lebendig und entfernt es nicht.

Speicherblähung — ein breiteres Problem, bei dem die App mehr Speicher verbraucht als für die Ausführung ihrer aktuellen Aufgaben erforderlich ist. Ursachen: übermäßiges Caching, Objektduplizierung, suboptimale Datenstrukturen und Heap-Fragmentierung.

In Android wird jeder App ein begrenzter Heap zugewiesen (normalerweise 64–512 MB, je nach Gerät und OS-Version). In iOS ist die Grenze weniger streng, aber das System sendet eine Speicherwarnung, wenn die Grenze erreicht wird.

Laut Facebook Engineering Blog verursachen Speicherlecks ~15% der Crash-Berichte in mobilen Apps. Unter Android kommen ANRs aufgrund häufiger GC-Pausen bei Speichermangel hinzu.

Häufige Speicherleckmuster in Android und iOS

Statische Referenz auf Activity — ein klassisches Android-Leck. Wenn ein statisches Feld oder Singleton eine Referenz auf eine Activity hält, wird diese auch nach finish() nicht vom GC gesammelt, solange das Singleton lebt. Eine Activity ist ein schweres Objekt mit einer View-Hierarchie, Ressourcen und Context.

object LeakHolder {
    var activityRef: Activity ?= null // leak: static reference to Activity
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ MainActivity will never be GC'd
    }
}

Anonyme Klassen und Lambdas — halten implizit eine Referenz auf die äußere Klasse. Wenn ein Runnable oder Callback an einen externen Dienst übergeben wird und die Activity zerstört wird, bleibt das anonyme Klassenobjekt in der Warteschlange und verhindert die Garbage Collection der Activity.

• Handler mit Verzögerung — wenn die Activity zerstört wird, Handler.postDelayed aber noch nicht ausgeführt wurde, leckt die Activity
• Thread und AsyncTask — bei Bildschirmdrehung wird die Activity neu erstellt, während der alte Thread weiterhin eine Referenz auf die alte Activity hält
• Retrofit/Callback — ein anonymer Callback hält eine Referenz auf den Presenter oder das Fragment
• Beobachter — LiveData- oder RxJava-Abonnements ohne Kündigung bei onDestroy

In iOS ist das Hauptproblem Retain-Zyklen: zwei Objekte halten starke Referenzen aufeinander und ARC kann den Referenzzähler für keines von beiden auf Null setzen. Ein typischer Fall: ein Closure, das self stark erfasst, und self, das eine Referenz auf das Closure hält.

Wie erkennt man Speicherlecks?

LeakCanary — eine Bibliothek von Square zur automatischen Leckerkennung in Android. Nach der Zerstörung einer Activity oder eines Fragments wird geprüft, ob das Objekt vom GC gesammelt wurde. Wenn nicht, wird ein Heap-Dump erstellt und der Leck-Trace angezeigt.

// LeakCanary 2.x — auto-integration via Application
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // LeakCanary auto-installs in debug build
        // via ContentProvider — zero code setup
    }
}

// Force check invocation
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — ein integriertes Tool zur Echtzeit-Speicherüberwachung. Es ermöglicht die Aufnahme eines Heap-Dumps, das Auffinden verdächtiger Objekte (Retained Size > 1 MB) und die Verfolgung des GC-Root-Pfads zu jedem Objekt.

Für iOS verwenden Sie den Xcode Memory Graph Debugger. Er visualisiert den Objektgraphen im Speicher, zeigt Retain-Zyklen und ermöglicht die sofortige Erkennung zirkulärer Referenzen. Instruments > Allocations ist ebenfalls für die Langzeitüberwachung verfügbar.

Präventionsstrategien

WeakReference — ein grundlegender Mechanismus für Referenzen, die die Garbage Collection nicht beeinträchtigen sollen. Wenn der GC beschließt, ein Objekt zu sammeln, gibt WeakReference null zurück. Es wird für Callbacks, Listener und Referenzen auf UI-Komponenten aus Hintergrundthreads verwendet.

Lifecycle-aware Komponenten — ein architektonischer Ansatz, der in Android Jetpack (Lifecycle, LiveData, Flow, coroutines) implementiert ist. Abonnements werden automatisch bei onDestroy gekündigt, wodurch die Hauptklasse von Lecks eliminiert wird.

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)
            // coroutine auto-cancels on onCleared()
        }
    }
}

viewModelScope und lifecycleScope — integrierte CoroutineScope in Android, die beim entsprechenden Lebenszyklusereignis abgebrochen werden. Dadurch werden Lecks durch Coroutinen vermieden — das häufigste Szenario in der modernen Android-Entwicklung.

• Verwenden Sie keine statischen Referenzen auf Context, Activity, View oder Fragment
• Kündigen Sie alle RxJava-Abonnements in disposeBag / CompositeDisposable bei onDestroy
• Verwenden Sie [weak self] / [unowned self] in iOS-Closures, um Retain-Zyklen zu verhindern
• Prüfen Sie Bitmap und große Objekte — sie sollten recycelt oder nullifiziert werden

Speicherprofilierungswerkzeuge

Memory Profiler in Android Studio — das primäre Tool zur Heap-Überwachung. Es zeigt Live-Allocations, Heap-Snapshots und Objektzahlen nach Typ. Es ermöglicht die Aufnahme eines Dumps und dessen Analyse in MAT (Memory Analyzer Tool) zum Auffinden verdächtiger Objekte.

Eclipse MAT — ein Desktop-Heap-Dump-Analysator. Nach dem Laden einer HPROF-Datei aus Android Studio erstellt MAT einen Dominator-Baum, zeigt die Retain-Größe jedes Objekts und bietet eine automatische Analyse verdächtiger Lecks über den Leak Suspects Report.

Xcode Memory Graph — ein visueller Retain-Zyklus-Debugger. Beim Klicken auf die Memory Graph Debugger-Taste stoppt Xcode die App, erstellt einen vollständigen Objektgraphen im Speicher und hebt Retain-Zyklen rot hervor.

Laut Google I/O 2023 reduzieren Apps, die LeakCanary in Debug-Builds verwenden, speicherbedingte Abstürze in den ersten 2 Monaten nach der Einführung um 30–50%. Es wird empfohlen, LeakCanary bereits in der Onboarding-Phase des Projekts hinzuzufügen.