Antwort.

In Swift können Closures Werte und Referenzen aus dem umgebenden Kontext „einfangen“. Wenn der eingefangene Wert ein Werttyp (struct, enum) ist, kopiert das Closure die Daten. Wenn ein Verweis (zum Beispiel eine Klasse) erfasst wird, speichert das Closure den Verweis auf die Instanz der Klasse, was zu einem Retain Cycle führen kann, wenn man nicht [weak self] oder [unowned self] verwendet.

Der Capturing-Mechanismus ermöglicht die Umsetzung von asynchronen Aufgaben und Callbacks, jedoch kann eine falsche Verwendung die Speicherverwaltung beeinträchtigen.

Beispiel:

class MyClass {
    var value = 10

    func doSomething() {
        let closure = { [weak self] in
            print(self?.value ?? "nil")
        }
        closure()
    }
}

In diesem Beispiel wird [weak self] verwendet, um einen starken Referenzzyklus zu vermeiden, da dies asynchron geschieht.

Fangfrage.

Frage: "Garantiert die Verwendung von [weak self] immer das Fehlen von Speicherlecks beim Capturing von self in Closures?"

Antwort: Nein, wenn im Inneren des Closures eine starke Referenz entsteht (zum Beispiel durch Zwischenvariablen), kann man auch mit [weak self] einen Retain Cycle erfahren. Zum Beispiel:

let closure = { [weak self] in
    let strongSelf = self
    strongSelf?.doSomething()
}

Wenn man das Closure an ein langlebiges Objekt (zum Beispiel NotificationCenter) bindet, kann man einen Retain Cycle erhalten, wenn es andere Verweise auf self gibt.

Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas.

---

Geschichte 1

In einem iOS-Anwendungsprojekt vergaß der Entwickler, [weak self] anzugeben, als er das Closure für eine Netzwerkabfrage übergab. Infolgedessen wurde das View-Controller-Objekt während der Ausführung der Anfrage nicht freigegeben, selbst wenn der Benutzer den Bildschirm schloss. Dies führte zu Speicherlecks bei intensiver Nutzung von Netzwerkoperationen.

---

Geschichte 2

In einem komplexen Abonnementsystem für einen Timer setzte das Objekt, das sich über ein Closure ohne Verwendung von weak angemeldet hatte, seine Aktionen fort, selbst nachdem der Bildschirm aus dem Speicher entfernt wurde. Dies führte zu wiederholten Aufrufen von UI-Elementen, die nicht mehr in der Hierarchie vorhanden waren, was zu Abstürzen der Anwendung führte.

---

Geschichte 3

Bei der Implementierung der Datencaching erfasste das Closure einen Verweis auf self ohne [unowned self] in einem langlebigen Cache-Objekt. Nach der Zerstörung des originalen Objekts führte der Versuch, auf self aus dem Closure zuzugreifen, zu einem Zugriff auf bereits freigegebenen Speicher und zum Absturz der Anwendung.