첫 글에서 리컴포지션은 "State로 선언된 값을 읽고 있던 컴포저블이, 그 값이 바뀌면 다시 실행되는 것"이라고 했다. 근데 어떤 값을 "읽기만" 해도 리컴포지션이 생각보다 자주 일어날 수 있다. 목록을 스크롤할 때마다 "맨 위로" 버튼을 보여줄지 말지 판단하는 걸로 확인해보자.

스크롤 위치를 보고 버튼을 보여주는 코드

@Composable
fun TodoListScreen(todoList: List<Todo>) {
    val listState = rememberLazyListState()
    val showScrollToTop = listState.firstVisibleItemIndex > 0

    Column {
        if (showScrollToTop) {
            Button(onClick = { /* 맨 위로 스크롤 */ }) {
                Text("맨 위로")
            }
        }
        LazyColumn(state = listState) {
            items(todoList, key = { it.id }) { todo ->
                // ...
            }
        }
    }
}

동작은 한다. 근데 Layout Inspector의 리컴포지션 카운트 표시를 켜고 스크롤을 해보면, TodoListScreen 전체가 스크롤하는 동안 계속 리컴포지션된다. showScrollToTop은 true/false 둘 중 하나로, 실제로 바뀌는 건 "맨 위 근처냐 아니냐"의 경계를 넘을 때 딱 한 번뿐인데, 그보다 훨씬 자주 다시 그려지고 있다.

왜 이렇게 자주 리컴포지션될까

listState.firstVisibleItemIndex는 스크롤 중에 매 프레임 바뀌는 값이다. val showScrollToTop = listState.firstVisibleItemIndex > 0이라고 쓰면, 컴포즈는 이 줄이 있는 컴포저블(TodoListScreen)이 firstVisibleItemIndex를 읽고 있다는 걸 기록한다. 그 값이 스크롤마다 바뀌니까, 매번 TodoListScreen을 통째로 다시 실행한다. showScrollToTop이라는 결과값 자체가 true에서 true로 안 바뀌어도, 그 결과를 계산하는 데 쓴 재료(firstVisibleItemIndex)가 바뀌면 일단 다시 계산부터 하는 거다.

derivedStateOf - "결과가 실제로 바뀔 때만" 알린다

val showScrollToTop by remember {
    derivedStateOf { listState.firstVisibleItemIndex > 0 }
}

derivedStateOf { }는 안의 람다를 계속 실행해서 값을 계산하긴 하지만, 그 결과값이 실제로 바뀔 때만 "이 값을 읽고 있던 컴포저블을 다시 그려야 한다"는 신호를 내보낸다. 람다 안에서는 여전히 firstVisibleItemIndex를 매 프레임 읽지만, 0에서 3, 3에서 7로 바뀌어도 showScrollToTop 값 자체는 계속 true라서 바뀌지 않았다는 걸 알고 있으니, 그 경계값을 넘기 전까지는 TodoListScreen을 다시 그리지 않는다.

아무 때나 derivedStateOf를 쓰면 되는 건 아니다

계산이 아주 가볍고, 원본 값이 바뀔 때 결과값도 거의 항상 같이 바뀐다면 derivedStateOf를 쓰는 오버헤드가 오히려 손해일 수 있다. "자주 바뀌는 값으로부터, 드물게 바뀌는 결과값을 뽑아낼 때"가 derivedStateOf를 쓸 자리다. 지금 예제처럼 "매 프레임 바뀌는 스크롤 위치"에서 "거의 안 바뀌는 불린 값"을 뽑아내는 게 정확히 이런 경우다.

Stable - 컴포즈가 "이건 비교해서 건너뛸 수 있다"고 믿게 해주기

@Composable
fun TodoListScreen(todoList: List<Todo>) { ... }

List<Todo>처럼 코틀린 표준 List 인터페이스를 파라미터로 받으면, 컴포즈 컴파일러는 이게 실제로 변경 불가능한(immutable) 리스트인지 확신할 수 없다. 뒤에서 ArrayList 같은 가변 구현체가 몰래 들어와서 내용이 바뀔 수도 있기 때문이다. 이렇게 "안전하다고 확신 못 하는" 타입은 @Stable하지 않다고 보고, 컴포즈가 "이전 값과 똑같으니 리컴포지션 건너뛰기" 최적화를 포기하는 경우가 있다.

데이터 클래스에 @Immutable 애노테이션을 직접 붙이거나, kotlinx.collections.immutable의 ImmutableList 같은 "진짜로 안 바뀐다고 타입으로 보장하는" 컬렉션을 쓰면 컴포즈가 더 확신을 갖고 건너뛸 수 있다. 지금 단계에서 todo_project 규모라면 당장 이걸 바꿀 필요는 없지만, 리스트가 커지고 화면이 복잡해질수록 이 차이가 체감된다.

Layout Inspector로 직접 확인하기

Android Studio의 Layout Inspector에는 리컴포지션 횟수를 색으로 보여주는 기능이 있다. derivedStateOf를 적용하기 전/후로 스크롤하면서 이 카운트를 비교해보면, "이 변화가 진짜 효과가 있었는지"를 감으로 때려맞추지 않고 눈으로 확인할 수 있다.

정리

• 어떤 값을 "읽기만" 해도, 그 값이 자주 바뀌면 그걸 읽는 컴포저블도 자주 리컴포지션된다
• derivedStateOf는 "자주 바뀌는 값에서, 드물게 바뀌는 결과"를 뽑아낼 때 리컴포지션을 줄여준다
• 리스트/컬렉션 타입을 파라미터로 받을 때는 컴포즈가 "안전하게 건너뛸 수 있는 타입"인지도 성능에 영향을 준다
• 감으로 판단하지 말고 Layout Inspector의 리컴포지션 카운트로 확인한다

다음 글에서는 폰과 태블릿처럼 화면 크기가 다른 기기에 맞춰 레이아웃을 바꾸는 방법을 보겠다.