Antwoord.

Geschiedenis van de vraag:

Escape-analyse is een term uit compileroptimalisatie en geheugbeheer. In Swift is het belangrijk vanwege het actieve gebruik van closure en ARC. Het is gerelateerd aan de concepten escaping en non-escaping closure, die bepalen of closure buiten de scope van de functie kunnen gaan.

Probleem:

Een verkeerde bepaling van het type closure leidt tot geheugenproblemen, lekken, onverwachte captures van variabelen en prestatieverlies. Het is essentieel om te begrijpen wanneer een closure "ontsnapt" (escapes) en wanneer niet, en om ze correct te markeren.

Oplossing:

Swift vereist dat escaping closure expliciet worden gemarkeerd met het attribuut @escaping. Non-escaping closure kunnen alleen binnen de functie worden vastgelegd, ze hebben automatisch een efficiënter geheugbeheer en kunnen vastgelegde variabelen veiliger gebruiken.

Voorbeeld van het verschil:

// non-escaping closure (sneller, niet opgeslagen na aanroep)
func performSync(block: () -> Void) {
    block()
}

// escaping closure (kan worden opgeslagen en later uitgevoerd)
var storedCompletion: (() -> Void)?

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

Belangrijke kenmerken:

Escaping closure kan worden vastgelegd en uitgevoerd buiten de oorspronkelijke functie, vereist @escaping
Non-escaping closure worden sneller gecompileerd, geen risico op retain cycle
Escape-analyse helpt de compiler bij het optimaliseren van objectplaatsing en het niveau van geheugenkontrole

Vragen met een valstrik.

Kan een closure die is gedefinieerd als non-escaping worden veranderd in escaping zonder de oorspronkelijke functiecode te wijzigen?

Nee. Het attribuut @escaping moet expliciet worden vermeld in de functiehandtekening. Als een closure binnen een functie buiten de functie wordt doorgegeven, is alleen een escaping closure nodig, anders zal de compiler een foutmelding geven.

Is het veilig om self binnen een escaping closure door te geven zonder weak/unowned capture?

Nee. Een escaping closure kan potentieel een retain cycle creëren als het self met een sterke referentie vastlegt. Het is noodzakelijk om het vastleggen expliciet te beheren:

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

Is een escaping closure altijd globaal (blijft in het geheugen tot het einde van het programma)?

Nee. De levenscyclus ervan hangt af van de opslagscope. Als de closure tijdelijk is opgeslagen of de eigenschap op nul is gezet, wordt deze vrijgegeven zodra de eigenschap zijn eigenaar verliest. Alleen closure die verwijzingen naar globale objecten bevatten of deze in globale variabelen opslaan, worden globaal.

Typische fouten en anti-patronen

Het vastleggen van self met een sterke referentie in een escaping closure, wat leidt tot retain cycle
Ontbreken van het attribuut @escaping in de functiehandtekening die de closure opslaat
Gebruik van escaping closure zonder noodzaak (over-engineering)

Voorbeeld uit het leven

Negatief geval

Binnen de methode van de klas wordt een closure opgeslagen zonder @escaping (compilerfout), later gecorrigeerd, maar vergeten om te beschermen tegen retain cycles — de applicatie heeft geheugenlekken.

Voordelen:

Snelle integratie van asynchrone taken

Nadelen:

Geheugenlek, retain cycle, problemen met de levenscyclus van objecten

Positief geval

De ontwikkelaar controleert altijd waar een escaping closure vereist is, legt self vast als weak/unowned, vermijdt lekken, werkt veilig met geheugen.