Hvordan optimerer du SwiftUI-performance omkring view identity og diffing?

Question

IT Interview Practice · Accepted Answer

SwiftUI kører `body` igen, hver gang observeret state ændres, og **diff'er** derefter det nye view-træ mod det gamle og opdaterer kun det, der er forskelligt. Performance-problemer kommer af at få den diff til at udføre for meget arbejde: ustabil **identity**, for bred **observation** og dyre `body`-beregninger. Ret det ved at kontrollere identity, afgrænse state og holde `body` billig.

## Hvordan diffing og identity fungerer

SwiftUI matcher views på tværs af renders efter **identity**. For lister er dette `id`; hvis id'et er ustabilt, smider SwiftUI viewet væk og genopbygger det (mister state og animationer) i stedet for at opdatere det.

```swift
// BAD: array index as id — reorders/inserts break identity, full rebuild
ForEach(items.indices, id: \.self) { i in Row(items[i]) }

// GOOD: stable identity tied to the data
ForEach(items) { item in Row(item) }      // items: Identifiable, stable id
```

## At afgrænse observation

Et `ObservableObject` re-renderer **hvert** view, der observerer det, hver gang **enhver** `@Published`-property ændres. Del store modeller op, eller gå over til **Observation-frameworket** (`@Observable`, iOS 17+), som sporer læsninger *per property*, så et view kun re-renderer, når en property, det faktisk brugte, ændres.

```swift
@Observable final class Feed {     // iOS 17: fine-grained dependency tracking
    var unreadCount = 0            // a view reading only .posts won't re-render on this
    var posts: [Post] = []
}
```

## At holde body billig

`body` kører ofte, så udfør aldrig tungt arbejde inline:

```swift
var body: some View {
    List(sortedItems) { ... }      // BAD if sortedItems sorts on every render
}
// GOOD: compute derived data in the model, not in body
```

- Udtræk subviews, så en state-ændring re-renderer et **lille** view, ikke hele skærmen.
- Brug `LazyVStack`/`List` til store samlinger, så off-screen rækker ikke bygges.
- Tilføj `.equatable()` eller `EquatableView` for at kortslutte diffing på stabile deltræer.

## Faldgruber

- `AnyView` udvisker type-identity og besejrer strukturel diffing — undgå den i hot paths.
- At sende en ny closure/array-literal ved hver render kan invalidere child-views unødvendigt.

## Hvorfor det betyder noget

På en 120Hz ProMotion-skærm har du ~8ms per frame; en `body`, der sorterer et stort array eller re-renderer en hel liste, taber frames og jank'er scrolling. Senior-interviews undersøger view identity og observation scope, fordi det er der, rigtige SwiftUI-apps bliver langsomme — og hvor et par præcise rettelser genopretter smoothness.

Hvordan diffing og identity fungerer

At afgrænse observation

At holde body billig

Faldgruber

Hvorfor det betyder noget

Relaterede spørgsmål