lateinit / lazy: l’essenza dell’inizializzazione differita e i suoi meccanismi in Kotlin

Cos’è l’inizializzazione differita in Kotlin?

L’inizializzazione differita è un modello in cui una proprietà di classe riceve il suo valore non al momento della costruzione dell’oggetto, ma successivamente, su richiesta. In Kotlin, questo modello viene implementato in due modi fondamentalmente diversi: il modificatore lateinit e il delegato lazy.

Entrambi i meccanismi risolvono un problema comune — una proprietà deve esistere nella classe, ma il suo valore o è sconosciuto al momento della creazione dell’oggetto, oppure il suo calcolo è troppo dispendioso in termini di risorse per essere eseguito inutilmente. Secondo Google I/O 2023, fino al 40% delle proprietà in una tipica applicazione Android può essere ottimizzato attraverso l’inizializzazione differita, riducendo il tempo di avvio del 15–25%.

La scelta tra lateinit e lazy è determinata da tre fattori: la mutabilità della proprietà (var o val), il suo ciclo di vita (assegnazione singola o multipla) e i requisiti di thread-safety (accesso single-thread o multi-thread).

Quando viene utilizzata l’inizializzazione differita

Il primo e più comune scenario è l’Iniezione di Dipendenze. Il framework (Dagger, Hilt, Koin) inietta le dipendenze dopo la creazione dell’oggetto, quindi la proprietà non può essere inizializzata nel costruttore. Senza lateinit, tutte le dipendenze dovrebbero essere dichiarate nullable e controllate a ogni utilizzo.

Il secondo scenario riguarda le risorse pesanti: database, client di rete, gestori di file. La loro creazione richiede tempo e memoria, quindi dovrebbero essere inizializzate solo quando effettivamente utilizzate. lazy è ideale per questi casi, garantendo una creazione unica.

La terza situazione riguarda i componenti Android (Activity, Fragment, ViewModel) il cui ciclo di vita è gestito dal sistema operativo. Le proprietà che dipendono da onCreate, onViewCreated o dal blocco init del ViewModel non possono essere inizializzate nel costruttore.

lateinit: meccanismo e limitazioni

lateinit è un modificatore per proprietà var che consente al compilatore Kotlin di posticipare l’inizializzazione. Il compilatore non richiede un’assegnazione di valore nel costruttore, ma genera un controllo in fase di esecuzione a ogni accesso: se la proprietà non è inizializzata, lancia UninitializedPropertyAccessException.

class MainActivity {
    lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)
    }
}

Limitazioni di lateinit: la proprietà deve essere dichiarata come var (non val), non nullable e non di tipo primitivo (Int, Double, Boolean, ecc.). Il motivo è che i tipi primitivi vengono compilati in primitivi JVM, che non hanno uno stato “non inizializzato”. Per le proprietà nullable, l’inizializzazione differita non è necessaria: null significa già assenza di valore.

Per verificare lo stato di una proprietà lateinit, utilizzare il riferimento incorporato tramite l’operatore ::: ::propertyName.isInitialized. Questo è l’unico modo sicuro per verificare se una proprietà è stata inizializzata senza rischiare un’eccezione. Il controllo è disponibile solo dalla stessa classe o da una classe interna, non da codice esterno.

class LoginFragment {
    lateinit var binding: FragmentLoginBinding

    fun isReady(): Boolean {
        return ::binding.isInitialized
    }
}

Prestazioni di lateinit

lateinit non aggiunge overhead dopo l’inizializzazione: una volta assegnato il valore, l’accesso alla proprietà è identico all’accesso diretto al campo. L’unico costo è il controllo di inizializzazione a ogni lettura prima dell’assegnazione. Dopo l’inizializzazione, il compilatore JIT ottimizza il controllo.

Una nota importante: le proprietà lateinit non possono essere utilizzate nelle classi inline e non sono supportate per proprietà con getter/setter personalizzati. Se una proprietà richiede un accesso calcolato, utilizzare lazy invece di lateinit.

lazy: meccanismo e vantaggi

lazy è un delegato di proprietà integrato nella libreria standard di Kotlin. Calcola il valore al primo accesso alla proprietà e memorizza nella cache il risultato per tutte le chiamate successive. A differenza di lateinit, lazy funziona solo con val, rendendo la proprietà immutabile dopo l’inizializzazione.

class UserRepository {
    private val database: Database by lazy {
        Database.create("users.db")
    }

    fun getUser(id: String): User {
        return database.query("SELECT * FROM users WHERE id = ?", id)
    }
}

lazy accetta un parametro opzionale LazyThreadSafetyMode che controlla il meccanismo di thread-safety. Il valore predefinito è SYNCHRONIZED — doppio controllo con blocco, che garantisce un’inizializzazione unica anche in caso di accesso concorrente da più thread.

Modalità di thread-safety di lazy

La modalità PUBLICATION consente l’inizializzazione parallela: più thread possono eseguire simultaneamente il blocco di inizializzazione, ma il risultato viene accettato solo dal primo che completa. È più veloce di SYNCHRONIZED in caso di contesa elevata, ma aumenta il consumo di risorse.

La modalità NONE disabilita completamente la sincronizzazione. Usarla solo per proprietà il cui accesso è garantito da un singolo thread. In questa modalità, lazy opera con overhead minimo — quasi come un’assegnazione diretta.

val heavyConfig: Config by lazy(LazyThreadSafetyMode.NONE) {
    Config.loadFromFile("config.json")
}

Quando lazy è preferibile

lazy è la scelta giusta per dipendenze inizializzate una volta: repository, client di rete, cache, database. La semantica di val protegge dalla sovrascrittura accidentale e la thread-safety predefinita rende il codice sicuro in ambienti multi-thread. lazy funziona correttamente anche con i tipi primitivi, cosa impossibile con lateinit.

In Android, lazy viene spesso utilizzato per inizializzare le dipendenze di ViewModel tramite by viewModels() o per creare client Retrofit. Tuttavia, fare attenzione: se un blocco lazy cattura un riferimento a un’Activity o un Fragment, può causare una perdita di memoria, poiché il delegato mantiene la chiusura per tutta la durata della proprietà.

lateinit vs lazy: confronto degli approcci

La scelta tra lateinit e lazy non è una questione di preferenza, ma una decisione architettonica determinata dalla natura della proprietà. Ogni meccanismo risolve il proprio compito e le loro aree di applicazione si sovrappongono solo parzialmente.

Utilizzare lateinit quando una proprietà deve cambiare dopo l’inizializzazione o la sua creazione è gestita da codice esterno. Un esempio tipico è View Binding in Android Activity: il binding viene creato in onCreate ma rimane var perché il framework non supporta val per questo scenario.

Utilizzare lazy quando una proprietà viene inizializzata una volta, il suo calcolo è costoso e il valore non cambia durante la vita dell’oggetto. Un esempio classico è la creazione lazy di un client Retrofit o di un database Room al primo accesso al repository.

Combinazione di lateinit e lazy

Entrambi i meccanismi possono essere utilizzati simultaneamente all’interno della stessa classe. Ad esempio, lateinit per View Binding e lazy per un repository. Questa è una pratica normale che riflette requisiti diversi per proprietà diverse. L’importante è non confondere la semantica: non utilizzare lateinit dove serve val, e non utilizzare lazy per proprietà che devono essere riassegnate.

Errori comuni nell’uso di lateinit e lazy

L’errore più comune con lateinit è accedere alla proprietà prima che venga inizializzata. Ciò porta a UninitializedPropertyAccessException, che non viene intercettata in fase di compilazione perché Kotlin si fida che lo sviluppatore garantisca l’ordine corretto di inizializzazione. La soluzione è controllare sempre lo stato tramite ::property.isInitialized prima dell’accesso in situazioni ambigue.

Il secondo problema comune è utilizzare lateinit per proprietà che sono semanticamente val. Se il valore viene impostato una volta e non cambia mai, lazy è la scelta più corretta. Rende la proprietà immutabile, previene la sovrascrittura accidentale e aggiunge thread-safety gratuitamente.

Il terzo errore è lazy con effetti collaterali. Il blocco di inizializzazione lazy non dovrebbe modificare lo stato esterno né dipendere dall’ordine di inizializzazione di altre proprietà lazy, poiché la sequenza di calcolo dipende dal primo accesso e potrebbe non essere ovvia. Se le proprietà lazy si riferiscono l’una all’altra, si crea una dipendenza circolare e StackOverflowError.

Il quarto problema riguarda le perdite di memoria tramite lazy in Android. Se un blocco lazy cattura un riferimento a un’Activity o un Fragment, il delegato mantiene la chiusura e il garbage collector non può liberare il componente nemmeno dopo la sua distruzione. La soluzione è usare lazy solo con oggetti a vita breve o passare il contesto di Application invece dell’Activity.

Il quinto errore tipico è tentare di applicare lateinit ai tipi primitivi. Il compilatore Kotlin lo blocca a livello di sintassi, ma gli sviluppatori tentano di aggirare la limitazione attraverso wrapper nullable. Ciò porta a controlli null non necessari e annulla completamente i vantaggi dell’inizializzazione differita.