المعاملات المستقرة مقابل غير المستقرة

When a Composable re-runs but its inputs have not changed, Compose can skip it entirely. Skipping is how fast Compose apps stay fast. 🚀

Compose only skips a Composable when every parameter is stable. One unstable input and the whole function re-executes on each recomposition.

A type is stable when Compose trusts that equals() is reliable and that public properties will not change without telling Compose.

Primitives, String, and function types are stable out of the box, so passing an Int or a lambda never blocks skipping.

A class with only val properties of stable types is itself stable. Immutable data is the friendliest input you can give Compose.

A mutable var property can change behind Compose's back, so the class becomes unstable and its Composable can no longer skip.

Plain List, Map, and Set are treated as unstable, because the interface could hide a mutable ArrayList underneath.

An interface parameter is unstable: the concrete implementation is unknown at compile time, so Compose cannot guarantee its equals() behaves.

Newer Compose ships strong skipping, which lets unstable parameters compare by reference, so many cases skip without extra annotations.

If a Composable redraws every frame for no visible reason, suspect an unstable parameter forcing a full re-run each time.

Stability is a promise to Compose, not magic. The more immutable your inputs are, the more work Compose is free to skip.

Test your grasp of stability.

Compose skips a Composable only when every input is stable. Favor primitives, Strings, and val-only classes to keep redraws cheap. ✅