Odpowiedź.

Historia pytania:

Analiza ucieczki – termin z optymalizacji kompilatorów i zarządzania pamięcią. W Swift ma znaczenie z powodu aktywnego używania closure i ARC. Jest związana z pojęciami escaping i non-escaping closure, które określają, czy zamknięcia mogą wychodzić poza zakres widoczności funkcji.

Problem:

Nieprawidłowe określenie typu zamknięcia prowadzi do błędów w zarządzaniu pamięcią, wycieków, nieoczekiwanych przechwyceń zmiennych i spadków wydajności. Należy dokładnie rozumieć, kiedy closure "ucieka" (escapes), a kiedy nie, oraz poprawnie je oznaczać.

Rozwiązanie:

Swift wymaga wyraźnego oznaczania escaping closure atrybutem @escaping. Non-escaping closure mogą być przechwytywane tylko wewnątrz funkcji, automatycznie mają bardziej efektywne zarządzanie pamięcią i mogą używać przechwyconych zmiennych bezpieczniej.

Przykład różnicy:

// non-escaping closure (szybszy, nie przechowywany po wywołaniu)
func performSync(block: () -> Void) {
    block()
}

// escaping closure (może być przechowywany i wykonany później)
var storedCompletion: (() -> Void)?

func performAsync(block: @escaping () -> Void) {
    storedCompletion = block
}

Kluczowe cechy:

Escaping closure może być przechwytywany i wykonywany poza oryginalną funkcją, wymaga @escaping
Non-escaping closure kompiluje się szybciej, nie ma ryzyka retain cycle
Analiza ucieczki pomaga kompilatorowi optymalizować rozmieszczenie obiektów i poziom kontroli zatrzymywania pamięci

Pytania z pułapką.

Czy można zmienić closure określony jako non-escaping na escaping bez zmiany kodu źródłowego funkcji?

Nie. Atrybut @escaping musi być wyraźnie określony w sygnaturze funkcji. Jeśli closure wewnątrz funkcji jest przekazywane poza jej zakres — wymagane jest tylko escaping closure, w przeciwnym razie kompilator zgłosi błąd.

Czy bezpiecznie jest przekazywać self do escaping closure bez przechwytywania weak/unowned?

Nie. Escaping closure potencjalnie może stworzyć retain cycle, jeśli przechwytuje self silną referencją. Należy wyraźnie zarządzać przechwytywaniem:

someAsync { [weak self] in
    self?.doSomething()
}

Czy zawsze escaping closure jest globalne (pozostaje w pamięci do końca programu)?

Nie. Jego cykl życia zależy od zakresu przechowywania. Jeśli closure jest przechowywane tylko tymczasowo lub właściwość jest ustawiona na null, zostanie zwolnione, gdy tylko właściwość straci właściciela. Globalne stają się tylko te closure, które mają odniesienia do globalnych obiektów lub przechowują je w globalnych zmiennych.

Typowe błędy i antywzorce

Przechwytywanie self silną referencją w escaping closure, co prowadzi do retain cycle
Brak atrybutu @escaping w sygnaturze funkcji, która przechowuje closure
Używanie escaping closure bez potrzeby (over-engineering)

Przykład z życia

Negatywny przypadek

Wewnątrz metody klasy przechowują closure bez @escaping (błąd kompilatora), później poprawiają, zapominają o zabezpieczeniu przed retain cycle — aplikacja ma wyciek pamięci.

Plusy:

Szybka integracja zadań asynchronicznych

Minusy:

Wyciek pamięci, retain cycle, problemy z cyklem życia obiektów

Pozytywny przypadek

Programista zawsze sprawdza, gdzie wymagane jest escaping closure, przechwytuje self jako weak/unowned, unika wycieków, pracuje z pamięcią bezpiecznie.