LazyVStack: cosa sono, stack verticali e orizzontali in SwiftUI

Cosa sono LazyVStack e LazyHStack?

LazyVStack e LazyHStack sono contenitori di layout in SwiftUI che creano e visualizzano viste figlie solo quando necessario, quando diventano visibili nell'area scorrevole. LazyVStack dispone gli elementi verticalmente (dall'alto verso il basso), mentre LazyHStack li dispone orizzontalmente (da sinistra a destra).

Entrambi gli stack sono stati introdotti da Apple in SwiftUI 2.0 (iOS 14, macOS 11, watchOS 7, tvOS 14) insieme a LazyVGrid e LazyHGrid. Prima dell'avvento degli stack pigri, gli sviluppatori dovevano utilizzare UITableView e UICollectionView tramite UIViewRepresentable per lavorare efficientemente con liste grandi. LazyVStack ha eliminato questa necessità fornendo un'interfaccia SwiftUI nativa con caricamento pigro automatico.

Secondo la WWDC Session 10031 di Apple (2020), gli stack pigri utilizzano un meccanismo di creazione differita delle viste: SwiftUI memorizza i dati di origine (ad esempio, un array di modelli) e crea istanze di vista immediatamente prima del rendering sullo schermo. Durante lo scorrimento, gli stack riutilizzano le viste già create, evitando nuove allocazioni — questo riduce il carico sull'allocatore di memoria e sul garbage collector di Swift.

Per lavorare con stack pigri, posizionali sempre all'interno di una ScrollView — senza scorrimento, gli elementi che si estendono oltre i limiti dello schermo verranno semplicemente tagliati, non creati pigramente.

Come funziona il caricamento pigro

Il meccanismo di caricamento pigro in LazyVStack si basa sulla geometria: SwiftUI traccia la posizione di ogni vista figlia rispetto al contenitore ScrollView. Quando un elemento supera il limite dell'area visibile (con un piccolo buffer di alcuni punti), il sistema chiama il suo inizializzatore e renderizza il contenuto. Quando un elemento lascia lo schermo, SwiftUI distrugge la vista ma preserva lo stato tramite @State se è contrassegnato come preservabile.

Questo approccio differisce da VStack, dove tutte le viste figlie vengono create immediatamente all'inizializzazione del contenitore, indipendentemente dalla loro visibilità. Per una lista di 10.000 elementi, VStack creerà 10.000 istanze di vista in memoria, mentre LazyVStack creerà solo quelle che cabono sullo schermo (di solito 8–15).

Dimensioni e allineamento

LazyVStack accetta tre parametri di configurazione: alignment (HorizontalAlignment — leading, center, trailing), spacing (CGFloat — spaziatura tra elementi), e pinnedViews (PinnedScrollableViews — fissaggio delle intestazioni di sezione). LazyHStack utilizza gli stessi parametri, ma alignment accetta VerticalAlignment (top, center, bottom).

Differenze tra LazyVStack e VStack: prestazioni e memoria

La principale differenza tra LazyVStack e VStack è la strategia di creazione degli elementi figli. VStack (stack eager) calcola la dimensione e la posizione di tutte le viste figlie al momento del rendering, rendendolo inadatto per liste dinamiche grandi. LazyVStack (stack lazy) rimanda la creazione fino a quando l'elemento diventa visibile.

Confrontiamo il comportamento usando una lista di 1000 righe di testo. VStack caricherà tutte le 1000 righe in memoria immediatamente, chiamando l'inizializzatore di ogni riga e allocando memoria per essa. Ciò porta a un degrado delle prestazioni su dispositivi deboli (iPhone SE, iPad mini) e aumenta il tempo di avvio dello schermo. LazyVStack caricherà solo le 10–12 righe visibili, creando il resto durante lo scorrimento.

Un test pratico (usando Xcode Instruments, profilo Allocations) mostra: su un iPhone 12 mini, una lista di 5000 elementi con LazyVStack consuma 3–5 MB di memoria, mentre VStack con lo stesso contenuto consuma 150–250 MB — 50 volte di più. Nel frattempo, il tempo di rendering iniziale per LazyVStack è di ~50 ms contro ~800 ms per VStack sullo stesso dispositivo.

Scegli VStack per liste statiche o corte (fino a 10–15 elementi) e LazyVStack per qualsiasi lista dinamica o potenzialmente lunga. Apple raccomanda di usare LazyVStack per impostazione predefinita se non sei sicuro della dimensione massima della lista.

Quando VStack è ancora necessario

VStack rimane la scelta migliore per interfacce statiche: schermata del profilo, modulo di accesso, scheda prodotto — dove il numero di elementi è noto e non supera 10–15. VStack funziona più velocemente nel rendering iniziale per tali quantità perché non spreca risorse nel tracciamento della geometria e nel caricamento pigro. Inoltre, VStack funziona correttamente al di fuori di ScrollView (ad esempio, all'interno di ZStack o Group), mentre LazyVStack senza ScrollView perde il suo scopo.

Quando usare LazyVStack e LazyHStack

Gli stack pigri sono ottimali per scenari con un numero grande o imprevedibile di elementi: feed di social media, cataloghi di prodotti, liste chat, librerie di file multimediali, registri eventi, pannelli di amministrazione con migliaia di record.

Casi d'uso specifici: elenco messaggi in un messenger (decine di migliaia di messaggi), carosello di immagini in un'app galleria, feed di notizie con caricamento infinito, elenco ordini in un negozio online. LazyHStack è particolarmente utile per caroselli orizzontali — ad esempio, Storie Instagram o banner promozionali.

Controindicazioni: interfacce con animazioni di comparsa elementi (gli stack pigri non supportano transizioni tra stati di eliminazione elementi senza logica aggiuntiva), casi in cui tutti gli elementi dovrebbero essere visibili contemporaneamente (una breve lista di checkbox) e quando hai bisogno di un controllo preciso sul riutilizzo delle celle (in questo caso List o Table potrebbero essere preferibili).

Esempi di codice: lista, griglia e sezioni

Esempio 1: Lista verticale semplice con LazyVStack

Un esempio di base visualizza 1000 elementi con consumo minimo di memoria. Elementi chiave: ScrollView come contenitore di scorrimento, LazyVStack per il caricamento pigro, ForEach con un identificatore per l'iterazione dei dati.

import SwiftUI

struct LazyListExample: View {
    let items = Array(0..<1000)

    var body: some View {
        ScrollView {
            LazyVStack(spacing: 8) {
                ForEach(items, id: \.self) { index in
                    Text("Elemento #\(index)")
                        .font(.body)
                        .frame(maxWidth: .infinity, alignment: .leading)
                        .padding()
                        .background(Color.gray.opacity(0.1))
                        .cornerRadius(8)
                }
            }
            .padding()
        }
    }
}

Il codice crea una ScrollView contenente un LazyVStack con spaziatura di 8pt tra gli elementi. ForEach itera sull'array items e crea un Text per ogni indice. Grazie al caricamento pigro, di 1000 elementi solo i 10–12 visibili sono in memoria alla volta.

Esempio 2: Sezioni con pinnedViews

Questo esempio mostra il raggruppamento di elementi per sezioni con intestazioni fissate, simile ai contatti iOS. Section definisce l'intestazione e il contenuto, pinnedViews: .sectionHeaders fissa l'intestazione nella parte superiore dello schermo durante lo scorrimento.

import SwiftUI

struct SectionedList: View {
    let cities = ["Mosca", "Londra", "Tokyo", "New York", "Parigi"]
    let countries = ["Russia", "Regno Unito", "Giappone", "USA", "Francia"]

    var body: some View {
        ScrollView {
            LazyVStack(pinnedViews: .sectionHeaders) {
                Section(header: Text("Città").font(.title).bold()) {
                    ForEach(cities, id: \.self) { city in
                        Text(city).padding(8)
                    }
                }
                Section(header: Text("Paesi").font(.title).bold()) {
                    ForEach(countries, id: \.self) { country in
                        Text(country).padding(8)
                    }
                }
            }
        }
    }
}

Le intestazioni fissate (.sectionHeaders) si comportano come gli section header di UITableView: scorrendo una sezione, l'intestazione "si attacca" al bordo superiore dello schermo finché l'intera sezione non scompare, dopodiché viene sostituita dall'intestazione della sezione successiva. pinnedViews possono essere combinati: .sectionHeaders e .sectionFooters simultaneamente.

Esempio 3: Carosello orizzontale con LazyHStack

LazyHStack viene utilizzato per lo scorrimento orizzontale — caroselli di immagini, elenchi orizzontali di categorie. Il parametro alignment: .top allinea gli elementi al bordo superiore.

import SwiftUI

struct HorizontalCarousel: View {
    let colors: [Color] = [.red, .blue, .green, .orange, .purple, .pink]

    var body: some View {
        ScrollView(.horizontal, showsIndicators: false) {
            LazyHStack(spacing: 16, alignment: .top) {
                ForEach(0..<100, id: \.self) { index in
                    RoundedRectangle(cornerRadius: 12)
                        .fill(colors[index % colors.count])
                        .frame(width: 150, height: 200)
                        .overlay(Text("\(index + 1)").foregroundColor(.white).bold())
                }
            }
            .padding(.horizontal)
        }
        .frame(height: 220)
    }
}

Il codice crea una ScrollView orizzontale con LazyHStack. Di 100 rettangoli, solo 2–3 vengono visualizzati contemporaneamente (a seconda della larghezza dello schermo e della dimensione degli elementi). Scorrendo a sinistra, i nuovi elementi vengono caricati pigramente. L'altezza del contenitore è fissa (220pt) per evitare un'altezza infinita nello scorrimento orizzontale.

PinnedViews e sezioni negli stack pigri

PinnedScrollableViews è un'opzione di configurazione per LazyVStack e LazyHStack che controlla il fissaggio di intestazioni e piè di pagina delle sezioni durante lo scorrimento. Due valori sono supportati: sectionHeaders (le intestazioni si attaccano all'inizio del contenitore) e sectionFooters (i piè di pagina si attaccano alla fine).

Il meccanismo delle viste fissate funziona solo all'interno di un contenitore Section annidato in LazyVStack. Ogni Section ha un'intestazione e/o un piè di pagina che ottengono automaticamente il comportamento di attaccamento. SwiftUI traccia la posizione di ogni sezione rispetto ai limiti di ScrollView e commuta la visibilità dell'elemento fissato durante la transizione tra sezioni.

Importante: pinnedViews aumentano la complessità del calcolo del layout perché SwiftUI deve ricalcolare costantemente quale intestazione è attualmente fissata. Usa pinnedViews solo quando la funzionalità è effettivamente necessaria — per liste semplici senza sezioni, è meglio omettere questo parametro. Apple nella sua documentazione (Human Interface Guidelines, 2024) raccomanda di usare intestazioni fissate per indici alfabetici e raggruppamento per date.

Suggerimenti per ottimizzare gli stack pigri

L'uso corretto degli identificatori è il fattore di prestazioni più importante per LazyVStack. Ogni elemento in ForEach deve avere un id univoco e stabile. L'uso di \.self con primitivi (Int, String) è accettabile, ma per i modelli di dati implementa sempre il protocollo Identifiable. ID instabili (ad esempio, UUID generato ogni volta) costringono SwiftUI a ricreare tutte le viste ad ogni aggiornamento.

Evita calcoli pesanti all'interno del body di ogni elemento dello stack. Se un elemento contiene layout complesso o elaborazione dati — estrai la logica in una struttura di vista separata con il proprio caricamento pigro. Usa EquatableView per prevenire ridisegni non necessari quando i dati dell'elemento non sono cambiati.

Per le immagini all'interno di LazyVStack, usa sempre caricamento asincrono (AsyncImage) o caching tramite Kingfisher/Nuke. Ogni elemento non deve caricare un'immagine in modo sincrono quando appare sullo schermo — ciò causerà scatti nello scorrimento. Secondo WWDC Session 10031, la dimensione ottimale del buffer di prefetch è di 3–5 schermi avanti e indietro dalla posizione corrente.

Misura le prestazioni usando Xcode Instruments con il profilo SwiftUI. Fai attenzione alle metriche: body evaluations, allocazioni e frame rate (FPS). Valori target: FPS > 55 durante lo scorrimento, tempo di rendering per elemento < 1 ms.