remember vs rememberSaveable in Jetpack Compose

Jetpack Compose provides two state retention mechanisms that behave identically during normal recomposition but diverge when the system destroys and recreates the composable's host. remember keeps state alive across recompositions within a single composition lifetime, while rememberSaveable additionally persists state across configuration changes and process death by writing it to the saved instance state bundle. Understanding when each mechanism discards state and how to extend rememberSaveable with custom savers is necessary for building UIs that handle the full Android lifecycle correctly. By the end of this lesson, you will be able to:

• Explain how remember stores values in the composition's slot table and when those values are lost.
• Describe how rememberSaveable integrates with the saved instance state mechanism.
• Identify which types rememberSaveable can persist by default and how to support custom types.
• Implement a Saver to convert non bundleable objects for persistence.
• Choose between remember and rememberSaveable based on state lifetime requirements.

How remember Works

remember stores a value in the Compose runtime's slot table, which is an internal data structure that tracks the state and composition nodes for each composable call. When a composable enters the composition for the first time, the remember block executes and stores the result. On subsequent recompositions, the runtime reads the stored value from the slot table and returns it without executing the block again:

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }
    Button(onClick = { count++ }) {
        Text("Count: $count")
    }
}

The stored value survives recompositions as long as the composable remains in the composition tree. It is discarded when the composable leaves the composition (for example, when it is removed by a conditional branch) or when the host activity is destroyed. Configuration changes like screen rotation destroy and recreate the activity, which destroys the entire composition tree and all remember values with it.

The slot table is an in memory structure with no persistence layer. It exists only as long as the Composition object exists, which is tied to the lifecycle of the ComposeView or the setContent call. This makes remember appropriate for transient state that can be recomputed or is irrelevant after recreation.

How rememberSaveable Works

rememberSaveable extends remember by registering the stored value with the SaveableStateRegistry, which is Compose's integration point with Android's saved instance state mechanism. When the system needs to save state (before a configuration change or process death), the registry serializes registered values into a Bundle and attaches it to the activity's or fragment's saved instance state:

@Composable
fun SearchBar() {
    var query by rememberSaveable { mutableStateOf("") }
    TextField(
        value = query,
        onValueChange = { query = it }
    )
}