Tips. Compose stable, unstable 상태와 자주 사용하는 어노테이션 정리

혹시나 잘못된 내용이 있다면 정정해주세요
(항상 헷갈리더라구요)

 

 

Stable vs Unstable 상태

Stable : Recomposition 일 발생했을 때 parameter 가 Stable 하다면 Compose Runtime 에서 Recomposition 을 건너뛰는 것(Skippable)이 가능한 상태를 말해요

Unstable : 상위 Composable 함수에서 Composition, Recomposition 이 발생했을 때, 항상 Recomposition 이 발생하는 상태를 말해요

 

Stable 어노테이션 vs Immtable 어노테이션 를 알아보기 전에, 내부/외부로부터 상태 변경 에 대한 부분을 꼭 알아야해요

fun ContactRow(contact: Contact) {
  var selected by remember { mutableStateOf(false) }
  Row {
    ContactDetails(contact)
    ToggleButton(selected, onToggled = { selected = !selected })
  }
}

 

위의 예제를 보고 이야기하자면, ContactDetail 의 UI 가 변경될 수 있는 요인은 첫째로는 contact 이 변경되는 경우에요. 하지만 파라미터로 받아오는 정보이기 때문에 상위에서 Recomposition 이 발생해야 변경될 수 있어요(외부 상태로 부터 변경). 두번째로는 onToggled 를 통해 selected 변수가 변경되는 순간 ContactRow 함수에 Recomposition 이 발생하면서 ContactDetails 함수도 UI 에 영향을 받게 되어요(내부 상태로 부터 변경). 

 

TMI. ContactRow 함수에서  Recomposition 이 발생하는 이유는 재구성(Recomposition)을 위한 코드 재실행을 시작할 수 있는 진입점으로 ContactRow 함수가 사용되기 때문이고 이를 Restartable 이라고 해요

 

문제는 여기서부터 시작해요. 파라미터로 받고 있는 Contact 의 변경이 없다면 ContactDetails 의 Recomposition 을 생략하고, ToggleButton 의 UI 만 업데이트 하는 것이 당연히 성능면으로 좋아보여요.

 

여기서 Contact 파라미터가 Stable 이라면 Recomposition 이 발생할 때 건너뛰는 것(Skippable)이 가능해요. 하지만 Unstable 하면 건너뛰는것이 불가능하고 결국은 다시 재구성(Recomposition) 되어요.

 

이제 Stable 어노테이션에 대해 알아볼게요.

@Stable 의 안정적이라는 의미는 Recomposition 이 발생해도 객체가 항상 다시 그려야하는 것이 아닌, 변경이 없다면 그려내지 않아도 되기 때문에 이를 안정적이라고 표현한 것으로 보여요. 값이 변경되었을 때, 혹은 상위 Composable 함수에서 Recomposition 이 발생했을 때 이전 호출과 값(equals)이 같다면 건너뛰기해서 불필요한 렌더링을 줄이고, 호출 값이 달라졌다면 Compose runtime 이 이를 감지하고 재구성과 같은 처리를 할 수 있다는 것을 의미해요. 즉 예측가능한 "안정적인" 컴포넌트를 의미해요

 

@Immutable 의 불변이라는 의미는 객체가 생성된 후에 내부 상태가 변경될 수 없는 객체(val)를 의미하며, 이로 인해 객체의 안정성이 보장되어요. Long, Int, Float, String 과 같은 프리미티브 타입들이 포함되어있어요. 그리고 불변하다고 항상 건너뛰기(Skippable) 되는 것은 아니에요. Immutable 해도 List 와 같은 불안정한 자료구조를 만나면 Unstable 하게 변경되어요(List 의 경우는 Stable 하게 만드려면 ImmutableList, persistentList 같은 것을 활용해야해요). 그렇기 때문에 Stable, Immutable 어노테이션을 붙인다고 꼭 의도대로 동작하는 것은 아니에요. 주의가 필요해요. 

 

TMI. List 가 불안정한 이유는 Kotlin List 이 interface 이기 때문에 구현체가 변경될 가능성이 있기 때문이에요.