Hoe optimaliseer je SwiftUI-performance rond view-identiteit en diffing?

Question

IT Interview Practice · Accepted Answer

SwiftUI voert `body` opnieuw uit wanneer geobserveerde state verandert, en **vergelijkt** dan de nieuwe view-tree met de oude en werkt alleen bij wat verschilt. Performanceproblemen komen voort uit het die diff te veel werk laten doen: onstabiele **identiteit**, te brede **observatie**, en dure `body`-berekeningen. Los het op door identiteit te beheersen, state te beperken en `body` goedkoop te houden.

## Hoe diffing en identiteit werken

SwiftUI koppelt views over renders heen op basis van **identiteit**. Voor lijsten is dit de `id`; als de id onstabiel is, gooit SwiftUI de view weg en herbouwt hem (waarbij state en animaties verloren gaan) in plaats van hem bij te werken.

```swift
// FOUT: array-index als id — herordenen/invoegen breekt identiteit, volledige herbouw
ForEach(items.indices, id: \.self) { i in Row(items[i]) }

// GOED: stabiele identiteit gekoppeld aan de data
ForEach(items) { item in Row(item) }      // items: Identifiable, stabiele id
```

## Observatie beperken

Een `ObservableObject` rendert **elke** view die hem observeert opnieuw wanneer **welke** `@Published`-property dan ook verandert. Splits grote modellen op, of ga over op het **Observation framework** (`@Observable`, iOS 17+), dat *per-property* reads bijhoudt zodat een view alleen opnieuw rendert wanneer een property die hij daadwerkelijk gebruikte verandert.

```swift
@Observable final class Feed {     // iOS 17: fijnmazige dependency tracking
    var unreadCount = 0            // een view die alleen .posts leest, rendert hierdoor niet opnieuw
    var posts: [Post] = []
}
```

## body goedkoop houden

`body` draait vaak, dus doe nooit zwaar werk inline:

```swift
var body: some View {
    List(sortedItems) { ... }      // FOUT als sortedItems bij elke render sorteert
}
// GOED: bereken afgeleide data in het model, niet in body
```

- Extraheer subviews zodat een state-wijziging een **kleine** view opnieuw rendert, niet het hele scherm.
- Gebruik `LazyVStack`/`List` voor grote collections zodat off-screen rijen niet worden gebouwd.
- Voeg `.equatable()` of `EquatableView` toe om diffing op stabiele subtrees kort te sluiten.

## Valkuilen

- `AnyView` wist type-identiteit uit en verslaat structureel diffing — vermijd het in hot paths.
- Bij elke render een nieuwe closure/array-literal doorgeven kan child-views onnodig invalideren.

## Waarom het belangrijk is

Op een 120Hz ProMotion-scherm heb je ~8ms per frame; een `body` die een grote array sorteert of een hele lijst opnieuw rendert, laat frames vallen en veroorzaakt schokkerig scrollen. Senior interviews peilen view-identiteit en observatie-omvang omdat dat is waar echte SwiftUI-apps traag worden — en waar een paar precieze fixes de soepelheid herstellen.

Hoe diffing en identiteit werken

Observatie beperken

body goedkoop houden

Valkuilen

Waarom het belangrijk is

Gerelateerde vragen