@Immutable

@Immutable
data class LoginState(
    val id: String = "",
    val password: String = "",
)

컴포즈로 개발 중인데, 이전 UiState에 해당하는 개념으로 쓰는 data class에 `@Immutable` 어노테이션을 붙여줘야한다는 걸 알았다. 왜 그렇게 해야될까?

 

`@Immutable`은 객체가 불변(Immutable)임을 명시하여, 내부 값이 변경될 일이 없다고 Compose에게 알려주는 역할을 한다.  하지만, @Immutable이 붙어 있다고 해서 리컴포지션을 "절대 안 하는 것"이 아니라, 객체가 변경되지 않는 경우에는 불필요한 리컴포지션을 방지할 수 있다.

 

`@Stable`은 객체가 변경될 가능성이 있지만, Compose가 내부 필드 변화까지 추적 가능하다고 판단할 때 사용한다.
즉, @Stable이 붙어 있는 객체의 프로퍼티가 바뀌면 리컴포지션이 발생하지만, 객체가 같다면 불필요한 리컴포지션을 방지할 수 있다.

 

좀 더 자세히 보겠다.

@Composable
fun UserProfile(user: User) {
    /* body */ 
}

컴포저블함수에 대해서, 상태가 변경될 때마다 리컴포지션을 수행하는데, 이 예제 코드에서는 user의 프로퍼티 값이 바뀌지않는 한 UserProfile이 리컴포지션 되지않는다.(보고있는 상태가 user 하나라고 했을 때)

 

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }

    Button(onClick = { count++ }) {
        Text("Count: $count")
    }
}

컴포즈에서 UI를 구성하는 데 필요한 데이터를 상태라고 보통 얘기하는데, `by remember { mutableStateOf(T) }`로 선언해서 썼을 것이다. 이렇게 var 객체로 선언된 건 상태가 변할 수 있고, 만약 이게 count라고 했을 때 count 값이 증가하게 되면 이걸 보고있던 컴포저블은 리컴포지션된다.

stateDiagram-v2
 [*] --> 상태변화: 상태_변경_감지
상태변화 --> 리컴포지션_필요_여부_판단

리컴포지션_필요_여부_판단 --> 리컴포지션이_필요하면: Yes
리컴포지션_필요_여부_판단 --> 리컴포지션이_필요없음: No

리컴포지션이_필요하면 --> 재구성된_Composable들: 컴파일러가_선택적으로_재구성
리컴포지션이_필요없음 --> [*]

재구성된_Composable들 --> UI_다시_그림: 다시_렌더링한다

UI_다시_그림 --> [*]

 

리컴포지션은 UI 트리를 순회하면서 변경된 상태에 대해서 UI를 다시 그리기 때문에 최적화와도 밀접한 연관이 있다. 즉 아래처럼 정리할 수 있겠다.

• 상태 변화는 UI 업데이트가 필요하다는 신호를 보내며, Compose에서 자동 감지
• 리컴포지션은 실제로 상태가 변경된 Composable을 재호출하여 UI를 갱신

 

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!