🌀 derivedStateOf 의 Trade-Off

1️⃣ derivedStateOf란 무엇인가?

한 줄 정의

derivedStateOf는 하나 이상의 Compose State로부터 "파생된 상태"를 만들고,
결과 값이 실제로 바뀌었을 때만 리컴포지션을 유발하는 Effect API

var text by remember { mutableStateOf("") }
val filteredText by remember {
    derivedStateOf {
        text.filter { !it.isDigit() }
    }
}

해당 코드를 통해서 text 의 값이 변경될때 내부 함수로 등록된 filter 가 호출되어 실행됩니다.

text 가 바뀔 때마다 derivedStateOf 안의 식을 다시 계산하고, 결과가 달라졌을 때만 UI를 다시 그립니다.

2️⃣ 왜 derivedStateOf가 필요한가?

Compose의 기본 동작

State가 변경되면 해당 State를 읽은 Composable은 무조건 리컴포지션됩니다.

val text by remember { mutableStateOf("") }
val filteredTextby = remember(text) { 
    text.filter { !it.isDigit() }
}

text가 바뀔 때마다 filteredText는 재계산되고 이를 사용하는 UI는 다시 그립니다. 문제는 text가 바뀌어도 필터링 결과가 동일한 경우에도 리컴포지션이 발생한다는 점입니다.

예를 들어 위 코드를 예시로 텍스트에서 숫자만 필터할때,  "abc" → "abcd" → "abc" 처럼 숫자가 없는 상태가 계속 유지되어도, text가 바뀌는 매 순간 UI를 다시 그립니다. 계산 결과가 같으면 실제 UI 변화가 없는데도 다시 그리는 것은 비효율적입니다.

3️⃣ derivedStateOf의 핵심 동작 구조

내부적으로 무슨 일이 일어나는가?

@StateFactoryMarker
public fun <T> derivedStateOf(calculation: () -> T): State<T> =
    DerivedSnapshotState(calculation, null)

derivedStateOf는 내부적으로 DerivedSnapshotState라는 특수한 State 구현체를 생성합니다.

DerivedSnapshotState는 다음과 같은 책임을 가집니다.

• 계산 람다(calculation) 보관
• 계산 결과 캐싱
• 계산 중 읽힌 State 자동 추적
• Snapshot 변경 시 캐시 유효성 판단
• 필요할 때만 재계산 수행

이 모든 로직은 내부의 ResultRecord를 통해 관리됩니다.

class ResultRecord<T>(snapshotId: SnapshotId) : StateRecord(snapshotId), DerivedState.Record<T> {
     override var dependencies: ObjectIntMap<StateObject> = emptyObjectIntMap()
     var result: Any? = Unset
     var resultHash: Int = 0
     ...
}

result: 마지막 계산 결과

dependencies: 계산 중 읽힌 State 목록

resultHash: dependencies들이 현재 snapshot 에서도 같은 상태인지 판단하기 위한 해시

DerivedSnapshotState 구조

fun isValid(derivedState: DerivedState<*>, snapshot: Snapshot): Boolean {
    val snapshotChanged = sync {
        validSnapshotId != snapshot.snapshotId ||
            validSnapshotWriteCount != snapshot.writeCount
    }
    val isValid =
        result !== Unset &&
            (!snapshotChanged || resultHash == readableHash(derivedState, snapshot))

    if (isValid && snapshotChanged) {
        sync {
            validSnapshotId = snapshot.snapshotId
            validSnapshotWriteCount = snapshot.writeCount
        }
    }

    return isValid
}

해당 코드를 통해 현재 ResultRecord 가 주어진 snapshot 시점에서 최신 상태인지 확인합니다.

해당 부분에 최신 상태가 아니라면 Snapshot.observe() 를 통해서 calculation()을 호출해 새로운 dependencies 와 result 를 설정합니다.

derivedStateOf는 state 값이 변경될 때마다 대신 “계산 + 비교” 비용을 항상 감수하는 구조입니다.

⚠️ 중요한 성능 관점

원활한 성능을 보장하기 위해

derivedStateOf 안에 아주 무거운 연산식을 넣는 것은 피해야 합니다.

연산이 복잡해질수록 derivedStateOf의 “계산 + 비교 비용”이 리컴포지션으로 UI를 다시 그리는 비용보다 더 커질 수 있습니다.

4️⃣ 그래서 언제 derivedStateOf가 효과적인가?

• When to Use derivedStateOf vs remember
  

✅ 사용하면 좋은 시나리오

공통 조건

• State 가 자주 변경되지만 실제 값 변경은 드문 경우
• derivedStateOf 내부 연산 자체가 가벼운 경우

대표 예시: 스크롤 관련 처리 lazyListState

@Composable
fun ScrollToTopButton(lazyListState: LazyListState, threshold: Int) {
	  val isEnabled by remember(threshold) {
	      derivedStateOf { lazyListState.firstVisibleItemIndex > threshold }
    }
  
  	Button(onClick = { }, enabled = isEnabled) {
    	Text("Scroll to top")
  	}
}

스크롤 이벤트는 프레임마다 발생하지만, firstVisibleItemIndex > threshold의 결과(Boolean)는 임계값을 넘는 순간에만 바뀝니다. derivedStateOf가 대부분의 프레임에서 리컴포지션을 막아 줍니다.

사용 예시)

• text 유효성 검증
• 필터링된 텍스트 표시 (derivedStateOf { text.filter { it.isDigit() } })
• LazyListState 의 스크롤 상태 처리

5️⃣ 언제 derivedStateOf를 쓰면 안 되는가?

계산을 통한 오버헤드가 recomposition을 통해 UI를 업데이트하는 비용보다 더 크면 성능에 역효과가 날 수 있습니다.

❌ 피해야 할 시나리오

1. 결과가 거의 항상 바뀌는 경우

@Composable
fun ScrollProgress(listState: LazyListState) {
    val progress by remember {
        derivedStateOf {
            val total = (listState.layoutInfo.totalItemsCount - 1).coerceAtLeast(1)
            listState.firstVisibleItemIndex / total.toFloat()
        }
    }

    LinearProgressIndicator(progress = progress)
}

해당 예시는 스크롤할 때마다 progress 값이 바뀝니다. 결과가 거의 항상 달라지므로 derivedStateOf의 비교 비용만 추가될 뿐 리컴포지션 스킵 효과는 없습니다. 이런 경우는 단순히 recomposition을 허용하는 편이 낫습니다.

2. 계산 비용이 비싼 경우

• filter/map/groupBy/sortedBy
• 통계 계산(sum/average) + 중간 컬렉션 생성

@Composable
fun GroupedSectionList(viewModel: MyViewModel) {
    val items by viewModel.items.collectAsState()     
    val query by viewModel.query.collectAsState()      

    val grouped by remember {                          
        derivedStateOf {
            items                                      
                .asSequence()
                .filter { it.name.contains(query, ignoreCase = true) }
                .groupBy { it.category }
                .mapValues { (_, v) -> v.sortedBy { it.date } }
                .toMap()
        }
    }
}

이경우 items나 query가 바뀔 때마다 filter/groupBy/sortedBy 전체가 재실행됩니다. 그냥 리컴포지션을 하는 경우 보다 더 해당 식을 실행하고 비교하는 연산이 더 비싸질 수 있습니다.

3. 단순 계산

아래 같은 연산은 비용이 사실상 0에 가깝고, 리컴포지션 비용도 대부분 매우 낮습니다.

derivedStateOf { list.isEmpty() }

오히려 코드 복잡도를 증가 시키고 마찬가지로 추가적인 오버헤드를 발생시킬 수 있습니다.

6️⃣ 그럼 이런 경우엔 어떻게 해야 하나?

derivedStateOf 안에서 정렬/그룹핑 같은 무거운 계산을 수행하면, UI 레이어에서 불필요한 재계산이 반복될 수 있습니다.
이럴 때는 계산을 Compose 밖으로 옮기고, Compose는 결과만 그리도록 만드는 방식이 가장 안전합니다.

• ViewModel에서 미리 계산해 UiState로 내려주기
• Flow.map {} / StateFlow로 데이터 변환 구성
• 필요한 경우 Dispatchers.Default 등 백그라운드 스레드에서 처리
• UI는 “가공된 결과”만 받아 그림

class MyViewModel(
    private val repository: Repository
) : ViewModel() {

    val uiState: StateFlow<UiState> =
        repository.itemsFlow
            .map { items ->
                UiState(
                    grouped = items.groupBy { it.category }
                )
            }
            .stateIn(
                scope = viewModelScope,
                started = SharingStarted.WhileSubscribed(5_000),
                initialValue = UiState()
            )
}

data class UiState(
    val grouped: Map<Category, List<Item>> = emptyMap()
)

7️⃣ 실전 질문 정리

Q) 어떤 시나리오에서 derivedStateOf가 효과적인가요?

여러 State로부터 파생된 값이

자주 읽히지만 실제 변경은 드문 경우에 효과적입니다.

특히 스크롤 상태로부터 Boolean 값을 파생하는 경우,

불필요한 recomposition을 줄이는 데 큰 도움이 됩니다.

Q) 언제 사용하지 말아야 하나요?

derivedStateOf 안에 무거운 연산을 넣으면,

의존 State가 바뀔 때마다 재계산 비용이 누적되어 오히려 성능에 악영향을 줄 수 있습니다.

이런 경우 ViewModel이나 백그라운드 처리로 분리하는 것이 적절합니다.

Q) remember 없이 derivedStateOf만 쓰면 안 되나요?

안 됩니다. remember가 없으면 리컴포지션마다 DerivedSnapshotState 객체가 새로 생성되어 캐시가 사라집니다.

이전 결과와 비교 자체가 불가능해지므로 derivedStateOf의 핵심 기능이 동작하지 않습니다. 

remember는 객체를 살려두는 역할, derivedStateOf는 그 객체가 살아있는 동안 비교하는 역할로 둘은 반드시 함께 사용해야 합니다.

📕 참고 자료

다음의 링크를 참고했습니다.

• https://developer.android.com/develop/ui/compose/side-effects#derivedstateof
• https://haeti.palms.blog/compose-snapshot-system
• https://androidengineers.substack.com/p/deep-dive-into-derivedstateof-in