Recomposition — 개념, 상태 변경 시 UI 재구축

Jetpack Compose에서 Recomposition이란

Recomposition은 이미 Composition에 참여한 Composable 함수를 새 매개변수 또는 상태 값으로 다시 실행하는 것입니다. 재구성의 주요 목표는 전체 인터페이스를 처음부터 재구축하지 않고 UI 트리를 현재 데이터와 동기화하는 것입니다. 한 번 발생하는 Composition과 달리 Recomposition은 화면 수명 동안 수백 번 트리거될 수 있습니다.

Recomposition은 스마트 무효화 원칙으로 작동합니다: Compose는 각 Composable 함수가 읽는 State 객체를 추적하고 종속성이 변경된 함수만 다시 시작하도록 표시합니다. 이는 실행 중 모든 State 읽기 작업을 기록하는 스냅샷 시스템과 이러한 종속성을 특정 함수에 매핑하는 Composer를 통해 달성됩니다.

이해하는 것이 중요합니다: 재구성이 즉각적인 화면 다시 그리기를 의미하지는 않습니다. Compose는 세 단계로 작동합니다: Composition(UI 설명 구축), Layout(크기 및 위치 계산), Drawing(캔버스에 렌더링). 재구성 후 요소의 크기와 위치가 변경되지 않은 경우 Layout 단계를 건너뛸 수 있습니다. 시각적外观이 변경되지 않은 경우 — Drawing이 건너뛰어집니다. 이 3단계 아키텍처는 각 UI 업데이트의 최소 비용을 보장합니다.

재구성 트리거: 함수 재시작 원인

재구성에는 세 가지 주요 트리거가 있습니다. 첫째는 Composable 함수 본문 내에서 읽은 State 객체의 변경입니다. mutableStateOf 또는 derivedStateOf가 값을 변경하면 이전 Composition에서 이 State 읽기를 등록한 모든 함수가 다시 시작하도록 표시됩니다.

둘째 트리거는 부모 함수에서 호출될 때 Composable 함수의 매개변수 변경입니다. 부모 함수가 새 값을 전달하면(예: 텍스트나 숫자가 변경됨) 자식 함수는 내부적으로 State를 읽지 않더라도 다시 시작됩니다. Compose는 equals를 통해 새 매개변수 값과 이전 값을 비교하고 같으면 — 함수를 건너뛸 수 있습니다.

셋째 트리거는 CompositionLocalProvider를 통한 CompositionLocal 변경입니다. .current를 통해 CompositionLocal을 읽는 모든 함수는 공급자가 변경되면 다시 시작됩니다. 이 메커니즘은 MaterialTheme에서 사용됩니다: 테마 전환(라이트/다크)은 MaterialTheme.colorScheme을 읽는 모든 컴포넌트의 재구성을 발생시킵니다.

@Composable
fun RecompositionDemo() {
    var counter by remember { mutableStateOf(0) }
    var text by remember { mutableStateOf("Hello") }

    Column {
        Text("Counter: $counter")  // recomposition when counter changes
        Text("Message: $text")    // recomposition when text changes

        Button(onClick = { counter++ }) {
            Text("+1")
        }
        Button(onClick = { text = "World" }) {
            Text("Change Text")
        }
    }
}

+1 버튼을 클릭하면 counter가 변경되어 첫 번째 Text 줄과 Column 자체만 재구성됩니다. text를 표시하는 두 번째 Text 줄은 다시 시작되지 않습니다. 이러한 격리는 스냅샷 시스템의 결과입니다: 각 Composable 함수는 읽은 State 객체만 알고 있습니다.

재구성 최적화: 실용적인 기술

재구성 최적화는 올바른 데이터 구조 선택에서 시작됩니다. 가변 컬렉션(mutableListOf) 대신 불변 컬렉션(listOf, mapOf)을 사용하세요. Compose는 equals를 통해 매개변수를 비교하며 컬렉션이 변경되었지만 equals가 true를 반환하면 함수가 다시 시작되지 않습니다. 가변 컬렉션의 경우 요소 수준에서 올바른 변경 추적을 구현하는 SnapshotStateList를 사용하세요.

두 번째 기술은 UI의 안정적인 부분을 별도의 Composable 함수로 추출하는 것입니다. 화면의 일부가 자주 변경되는 상태에 의존하지 않는 경우 매개변수와 함께 별도의 함수로 추출하세요. 재구성이 발생하면 안정적인 함수는 동일한 매개변수를 받고 Compose가 이를 비교하여 실행을 건너니다. 이는 일부 매개변수가 변경된 큰 함수의 일부로 해당 부분을 다시 시작하는 것보다 효율적입니다.

세 번째 기술은 LazyColumn의 키입니다. LazyColumn, LazyGrid 및 기타 지연 컨테이너의 항목에는 항상 키를 지정하세요. 키를 사용하면 목록 변경(추가, 제거 또는 재정렬) 시 Compose가 요소를 식별할 수 있습니다. 키가 없으면 Compose는 변경 시 목록의 모든 항목을 다시 시작하며, 큰 목록에서는 눈에 띄는 성능 저하가 발생합니다.

// Optimized structure: stable parts extracted separately
@Composable
fun OptimizedScreen(items: List<Item>) {
    Column {
        Header()                         // does not depend on items — no recomposition
        Spacer(modifier = Modifier.height(8.dp))
        LazyColumn {
            items(items, key = { it.id }) { item ->
                ItemRow(item = item)   // recomposition only for changed items
            }
        }
    }
}

@Composable
fun Header() {
    Text("Item list", style = MaterialTheme.typography.headlineMedium)
}

@Composable
fun ItemRow(item: Item) {
    Text(item.title)
}

// Bad: new lambda on every parent recomposition
@Composable
fun Parent() {
    Child(onClick = { doSomething() })  // new lambda every time
}

// Good: remember stabilizes the lambda
@Composable
fun Parent() {
    val onClick = remember { { doSomething() } }
    Child(onClick = onClick)  // same reference
}