Hogyan optimalizálod a SwiftUI teljesítményét a view-identitás és a diffing körül?

Question

IT Interview Practice · Accepted Answer

A SwiftUI újra lefuttatja a `body`-t, valahányszor a megfigyelt állapot megváltozik, majd **összehasonlítja (diff)** az új view-fát a régivel, és csak azt frissíti, ami eltér. A teljesítményproblémák abból erednek, hogy ez a diff túl sok munkát végez: instabil **identitás**, túl széles körű **megfigyelés** és költséges `body`-számítások. Javítsd az identitás kontrollálásával, az állapot szűkítésével és a `body` olcsón tartásával.

## Hogyan működik a diffing és az identitás

A SwiftUI a renderelések között **identitás** alapján párosítja a view-kat. Listáknál ez az `id`; ha az id instabil, a SwiftUI eldobja és újraépíti a view-t (elveszítve az állapotot és az animációkat) ahelyett, hogy frissítené.

```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
```

## A megfigyelés szűkítése

Egy `ObservableObject` **minden** őt megfigyelő view-t újrarenderel, valahányszor **bármelyik** `@Published` tulajdonsága megváltozik. Bontsd szét a nagy modelleket, vagy térj át az **Observation keretrendszerre** (`@Observable`, iOS 17+), amely *tulajdonságonként* követi az olvasásokat, így egy view csak akkor renderelődik újra, ha egy ténylegesen használt tulajdonsága változik.

```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] = []
}
```

## A body olcsón tartása

A `body` gyakran fut, ezért soha ne végezz benne közvetlenül nehéz munkát:

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

- Emelj ki alview-kat, hogy egy állapotváltozás egy **kis** view-t rendereljen újra, ne az egész képernyőt.
- Használj `LazyVStack`/`List`-et nagy gyűjteményekhez, hogy a képernyőn kívüli sorok ne épüljenek fel.
- Adj hozzá `.equatable()`-t vagy `EquatableView`-t, hogy rövidre zárd a diffelést a stabil részfákon.

## Buktatók

- Az `AnyView` eltörli a típusidentitást, és meghiúsítja a strukturális diffelést — kerüld a gyakran futó (hot) útvonalakon.
- Ha minden rendereléskor új closure-t/tömb-literált adsz át, az feleslegesen érvénytelenítheti a gyerek view-kat.

## Miért fontos

Egy 120Hz-es ProMotion kijelzőn ~8 ms jut egy képkockára; egy `body`, amely egy nagy tömböt rendez vagy egy egész listát renderel újra, képkockákat ejt el, és akadozóvá teszi a görgetést. A senior interjúk azért firtatják a view-identitást és a megfigyelés hatókörét, mert a valós SwiftUI-alkalmazások itt válnak lassúvá — és itt állít vissza néhány pontos javítás a simaságot.

Hogyan működik a diffing és az identitás

A megfigyelés szűkítése

A body olcsón tartása

Buktatók

Miért fontos

Kapcsolódó kérdések