Parametri stabili e instabili

Quando un Composable viene rieseguito, ma i suoi input non sono cambiati, Compose può saltarlo completamente. È così che le app Compose veloci restano veloci. 🚀

Compose salta un Composable solo quando ogni parametro è stable. Basta un input non stabile e l'intera funzione viene rieseguita a ogni ricomposizione.

Un tipo è stable quando Compose può fidarsi del fatto che equals() sia affidabile e che le proprietà pubbliche non cambino senza informare Compose.

I tipi primitivi, String e i tipi funzione sono stable già in partenza, quindi passare un Int o una lambda non impedisce mai lo skip.

Una classe con sole proprietà val di tipi stabili è a sua volta stabile. I dati immutabili sono l'input più adatto da fornire a Compose.

Una proprietà var mutabile può cambiare alle spalle di Compose, quindi la classe diventa instabile e il relativo Composable non può più essere saltato.

List, Map e Set semplici vengono trattati come instabili, perché l'interfaccia potrebbe nascondere internamente un ArrayList mutabile.

Un parametro di tipo interfaccia è instabile: l'implementazione concreta è sconosciuta in fase di compilazione, quindi Compose non può garantire che il suo equals() si comporti correttamente.

Le versioni più recenti di Compose includono strong skipping, che consente di confrontare per riferimento i parametri instabili; in questo modo molti casi vengono saltati senza annotazioni aggiuntive.

Se un Composable viene ridisegnato a ogni frame senza un motivo visibile, sospetti un parametro unstable che forza una riesecuzione completa ogni volta.

La stabilità è una promessa fatta a Compose, non una magia. Più i suoi input sono immutable, più lavoro Compose può saltare liberamente.

Compose salta un Composable solo quando ogni input è stable. Preferisca primitivi, String e classi composte solo da val per mantenere economici i ridisegni. ✅