Antwoord.

Achtergrond:

Met de ontwikkeling van Objective-C en de introductie van Swift kwam bij Apple de vraag op naar automatische en veilige geheugenbeheer van applicaties zonder expliciete handelingen van de programmeur met de commando's retain/release. Swift gebruikt Automatic Reference Counting (ARC), dat het aantal verwijzingen naar objecten van klassen bijhoudt en automatisch het geheugen vrijgeeft wanneer de laatste eigenaar verdwijnt.

Probleem:

Aangezien Swift een multi-paradigma programmeertaal is, werkt het zowel met waarde-types (struct, enum) als met referentie-types (class). Voor de laatste is het belangrijk dat het geheugen tijdig wordt vrijgegeven, anders kan er geheugenlek optreden. Een complexe situatie ontstaat bij retain cycle (cyclische verwijzingen), waarbij twee objecten naar elkaar verwijzen en ARC niet in staat is om het geheugen vrij te geven.

Oplossing:

Swift past ARC alleen toe op objecten van klassen. Wanneer het aantal verwijzingen 0 wordt, wordt het geheugen vrijgegeven. Om het probleem van retain cycles op te lossen, worden de sleutelwoorden weak/unowned gebruikt.

Voorbeeldcode:

class Person {
    var name: String
    var pet: Pet?
    init(name: String) {
        self.name = name
    }
    deinit {
        print("\(name) wordt gedeinitialiseerd")
    }
}

class Pet {
    var owner: Person?
    init() {}
    deinit {
        print("Huisdier wordt gedeinitialiseerd")
    }
}

var tom: Person? = Person(name: "Tom")
var cat: Pet? = Pet()
tom!.pet = cat
cat!.owner = tom

tom = nil
cat = nil // Beide objecten worden NIET vrijgegeven, er is een retain cycle ontstaan

Belangrijke kenmerken:

• Geheugenbeheer is transparant voor de ontwikkelaar.
• Alleen klassen worden ondersteund, structuren en enums worden niet via verwijzingen gevolgd.
• Voor het oplossen van retain cycles worden weak en unowned gebruikt.

Vragen met een twist.

Kan ARC gebruikt worden voor waarde-types?

Nee, ARC houdt alleen rekening met verwijzingen naar objecten van klassen. Structuren en enums worden door waarde doorgegeven en Swift geeft hun geheugen automatisch vrij (over het algemeen bij het verlaten van de scope).

Wat gebeurt er als je geen weak/unowned gebruikt in de eigenschappen van twee wederzijds verwante objecten?

Er ontstaat een cyclische verwijzing (retain cycle), waardoor ARC het geheugen voor deze objecten nooit zal vrijgeven. Dergelijke code leidt tot geheugenlekken — gebruik altijd weak (of unowned) voor ten minste één kant van zo'n relatie.

Waar is unowned voor nodig, als er weak is?

Unowned is nodig in gevallen waar de verwijzing altijd moet bestaan tijdens de levensduur van een ander object en nooit nil mag worden. weak is een nulverwijzing, unowned is niet-nul, maar er is geen verhoging van de retain teller.

Voorbeeldcode:

class A {
    var b: B?
}
class B {
    unowned var a: A // nooit nil tijdens de levensduur van B
}

Typische fouten en anti-patronen

• Het gebruik van sterke verwijzingen waar weak/unowned nodig is.
• Vergeten over ARC bij het werken met klassen en arrays/woordenboeken die objecten bevatten.
• Pogingen om geheugen van waarde-types handmatig vrij te geven of het gebruik van weak voor struct/enums.

Voorbeeld uit het leven

Negatieve case

Twee controllers houden sterke verwijzingen naar elkaar: één via een delegaat-eigenschap, de tweede via een array van kindcontrollers. De maker gebruikt geen weak voor de delegaat.

Voordelen: Fouten zijn niet meteen zichtbaar, alles "werkt" op het eerste gezicht.

Nadelen: Met de groei van de applicatie wordt het geheugen niet vrijgegeven, er ontstaan lekken; bij het werken met een beperkte hoeveelheid geheugen zijn crashes mogelijk.

Positieve case

De delegaat en gebeurtenisobservator worden ingesteld als weak, de array van controllers wordt schoongemaakt naarmate de controllers verdwijnen. Alles is netjes gedocumenteerd.

Voordelen: Geen lekken, alle objecten worden tijdig vrijgegeven, geen prestatieverlies.

Nadelen: Verlies van de delegaat kan onverwacht optreden (als er ergens hogerop een sterke verwijzing is vergeten); vereist aandacht bij de architectuur van de applicatie.