[Android] UI architecture - Phase와 State

#1 이전 게시글

[Android] UI architecture - Phases

위 게시글에서 이어진다.

 

#2 State

[Android] Jetpack Compose - State 기초

먼저, State에 대해 이해해야 한다. 모르는 사람은 위 게시글을 읽자. 게시글을 요약하면, "Compose Runtime은 State 값 변화에 반응한다"이다.

 

#3 State와 Phase

#3-1 Phase 재실행은 독립적이다

Compose에는 UI 생성을 위한 3단계가 존재한다. Layout 단계의 최초 실행은 Composition 단계가 반드시 선행되어야 하며, Drawing 단계의 최초 실행은 Layout 단계가 반드시 선행되어야 한다. 하지만, 재실행이라면 얘기가 달라진다. 재실행 시에는 Layout 단계가 Composition 단계와 상관없이 독립적으로 작동할 수도 있다. 말 그대로 재실행이기에, Composition 단계에서 만들었던 UI Tree를 재사용할 수도 있기 때문이다. 참고로 State가 어디에 저장되는가? 따위는 중요치 않다. 여기에서 중요한 것은 State의 값이 어떤 단계에서 읽히느냐다. State의 값이 어느 단계에서 읽히느냐에 따라, State 인스턴스 별로 형성되는 Restart Scope를 언제 재실행할지가 결정되기 때문이다.

 

#3-2 Restart Scope

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

    Column {
        Button(onClick = { count++ }) {
            Text("Increment")
        }

        Text("Current count: $count")
    }
}

Restart Scope는 Compose에서 특정 State 값의 변경이 발생했을 때, 재실행될 수 있는 코드 블록의 범위다. 위 코드에서 Text("Current count: $count")는 State형 변수인 count에 의존한다. Button() 사용자가 클릭해서 count 값이 변경되면, Compose는 Text 컴포저블만 다시 실행한다. 이 다시 실행되는 코드의 범위를 Restart Scope라한다. State형 인스턴스들은 각 인스턴스마다 자신들만의 Restart Scope를 형성한다. 각 인스턴스는 (당연히) 일부 혹은 전부가 겹치는 Restart Scope를 가질 수 있다.

 

아래에서 각 단계 별 State와의 상호작용을 서술한다.

 

#3-3 Composition 단계

var padding by remember { mutableStateOf(8.dp) }
var anyState by remember { mutableStateOf(0)}
Text(
    text = "Hello",
    // `padding` 상태는 Modifier가 생성될 때 Composition 단계에서 읽힘
    // `padding` 값이 변경되면 Composition이 재실행됨
    modifier = Modifier.padding(padding)
)

Composition 단계는 한 마디로 UI Tree를 그리는 과정이다. UI Tree를 그릴 때 Compose Runtime은 UI Tree에 관련된 State의 값을 읽고 추적 목록에 넣는다 (!= Compose Runtime이 무조건 반드시 모든 State를 읽고 추적한다). 여기서 중요한 점은 UI Tree에 관련된 State만을 읽고 추적 목록에 넣는다는 것이다. 반대로 말해, UI Tree와 관련없는 State는 Composition 단계에서 무시된다 (= Restart Scope 자체가 만들어지지 않음). 따라서 위 코드 속 변수 anyState는 적어도 Composition 단계에선 없는 변수처럼 취급된다. Composition 단계의 추적 목록에 등록된 State의 값이 변경되면, Composition이 재실행(Recomposition)된다.

 

도식도

https://developer.android.com/develop/ui/compose/layouts/constraints-modifiers#modifiers-ui

Modifier까지 포함한 UI 트리의 모습

 

#3-4 Layout 단계

var offsetX by remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    modifier = Modifier.offset {
        // 'offsetX' 상태는 Layout 단계의 배치 단계(Placement)에서 읽힘
        // 'offsetX' 값이 변경되면 Layout 단계가 다시 실행됨
        IntOffset(offsetX.roundToPx(), 0)
    }
)

Layout 단계는 UI Tree에 기반해 (크기 및 위치를) 계산하는 과정이다. 이 계산 과정에서 Compose Runtime은 크기 및 위치에 관련된 State의 값을 읽고 추적 목록에 넣는다. 여기서 중요한 점은 크기 및 위치에 관련된 State만을 읽고 추적 목록에 넣는다는 것이다. 반대로 말해, 크기 및 위치와 관련없는 State는 Layout 단계에서 무시된다.

 

의문점: padding()과 offset()이 왜 서로 다른 단계에서 추적되는가?

자연히 의문이 든다. #3-2의 padding() 또한 크기 및 위치와 관련된 개념이 아니었는가? 왜 padding()은 Composition 단계에서 추적되며, offset()은 Layout 단계에서 추적되는가? 둘은 무슨 차이가 있는가? 둘은 '모양' 이라는 추상적 관념을 공유하지만, 그 구현 방식이 다르기 때문이다. padding()은 함수 자체가 정적 값을 인수로 받고 offset은 함수 자체가 람다 함수(동적 값)을 인수로 받는다. 전자는 고정된 값을 Modifier가 저장하는 반면 후자는 람다 자체만을 저장하여 Offset 값을 반환하는 로직만 나중에 실행된다. #3-2의 도식도 속 Modifier에 padding(start = 8)과 같은 구체적 수치가 아니라, offset { IntOffset(offsetX.roundToPx(), 0) }와 같은 람다 함수가 담겨 있다고 생각하면 된다.

 

그렇다면 질문을 바꿔보겠다. 왜 padding은 정적 값을 받도록 만들어져있고 offset은 람다 함수를 인수로 받게 만들어진 것일까? 개발자라면 누구나 간단한 Web 프로그래밍을 해본 적이 있을 것이다. css 속성에서 padding값을 설정할 때를 생각해보자. padding을 어떻게 설정하느냐에 따라 부모 및 자식의 모양이 변한다. 즉, 자기 자신만 바꾸는 게 아니라 어떤 연쇄 반응을 일으킨다. 이는 설계하는 입장(프로그래머 입장)에서 눈쌀을 찌푸리게 만드는 불확실함을 자아낸다. 반면 offset은 자기 자신의 위치만을 변경한다. 자기 자신만 바꾸기에 안전하다. 실제로 Jetpack Compose에서 offset값을 이상하게 설정하면 부모의 영역을 뚫고 나가버린다든가 하는 일이 생긴다. 자기 자신의 모양만 바꾸니까 그렇다. 정리하면, 우리(개발자)가 개발하기 편하게 Google이 의도적으로 구분해 놓은 것이다.

 

Layout 단계는 측정(Measurement) 및 배치(Placement)라는 두 하위 단계를 가진다.

 

#3-5 Layout - Measurement

여기서 설명하는 건 혼란만 가중시킨다. 이 게시글에서 실제 코드와 함께 봐야한다. 저 게시글에 나오는 measurable.measure()가 Measurement 단계에 해당한다.

 

#3-6 Layout - Placement

여기서 설명하는 건 혼란만 가중시킨다. 이 게시글에서 실제 코드와 함께 봐야한다. 저 게시글에 나오는 MeasureScope.layout()이 Placement 단계에 해당한다.

 

#3-7 Drawing 단계

var color by remember { mutableStateOf(Color.Red) }
Canvas(modifier = modifier) {
    // `color` 상태는 Drawing 단계에서 읽힘
    // `color` 값이 변경되면 Drawing 단계가 다시 실행됨
    drawRect(color)
}

Drawing 단계는 실제 화면에 그래픽을 표시하는 과정이다. 이 계산 과정에서 Compose Runtime은 그래픽에 관련된 State의 값을 읽고 추적 목록에 넣는다. 여기서 중요한 점은 그래픽에 관련된 State만을 읽고 추적 목록에 넣는다는 것이다. 반대로 말해, 그래픽과 관련없는 State는 Drawing 단계에서 무시된다.

 

#4 State의 '좋은' 위치

#4-1 2가지 Modifier.offset()

후술할 코드 설명을 위해 먼저 메소드 오버로딩된 Modifier.offset()의 2가지 형태를 먼저 알아본다.

 

// https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/package-summary#(androidx.compose.ui.Modifier).offset(androidx.compose.ui.unit.Dp,androidx.compose.ui.unit.Dp)

fun Modifier.offset(x: Dp = 0.dp, y: Dp = 0.dp): Modifier

#3-2의 padding()처럼 정적인 정보를 담는다.

 

// https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/package-summary#(androidx.compose.ui.Modifier).offset(kotlin.Function1)

fun Modifier.offset(offset: Density.() -> IntOffset): Modifier

#3-3에서 쓰인 offset()으로, 동적인 정보(람다 함수)를 담는다.

 

#4-2 State의 나쁜 위치

Box {
    val density = LocalDensity.current
    val listState = rememberLazyListState()

    Image(
        // ...
        // 비효율적인 구현 방식!
        Modifier.offset(
            // Composition 중 firstVisibleItemScrollOffset 상태 읽기
            (listState.firstVisibleItemScrollOffset / 2).toDp(density)
        )
    )

    LazyColumn(state = listState) {
        // ...
    }
}

정적인 정보를 담는 Modifier.offset()이 쓰인 코드다. 작동은 하지만 성능상으론 좋지 않은 코드다. 왜냐하면 Composition 단계에서 읽힌 listState.firstVisibleItemScrollOffset의 값이 스크롤 할 때마다 변동되기에, Composition 단계가 너무 자주 재실행되기 때문이다.

 

#4-3 코드 리팩토링

Box {
    val listState = rememberLazyListState()

    Image(
        // ...
        Modifier.offset {
            // Layout 단계에서 firstVisibleItemScrollOffset 상태 읽기
            IntOffset(x = 0, y = listState.firstVisibleItemScrollOffset / 2)
        }
    )

    LazyColumn(state = listState) {
        // ...
    }
}

동적인 정보를 담는 Modifier.offset()으로 바꿨다. 이러면 사용자가 스크롤을 할 때마다, Composition 단계 대신 Layout 단계가 재실행될 것이다. 위에서 말했듯 각 Phase의 재실행은 서로 독립적이기에, 가령 Composition 단계 재실행이 꼭 layout 단계 재실행을 유발하진 않는다. 하지만 #4-2의 코드에서는 listState.firstVisibleItemScrollOffset의 변화가 Image 및 LazyColumn의 Layout 단계 재실행을 유발한다. 정리하면 Composition이 굳이 재실행될 필요가 없는 구조이기에, Layout만 재실행되도록 코드를 리팩토링한 것이다.

 

#4-4 일반화

#4-2의 코드를 #4-3의 코드로 변경한 것은 하나의 예시에 불과하다. 이를 일반화해 설명하면, State가 읽히는 단계가 최대한 낮은 단계가 되게끔 로컬화(localize)하여 Compose Runtime가 쓸데없는 일을 하지 않도록 만드는 것이다. 또 다른 방법으로는 Side-Efftects 중 하나인 derivedStateOf를 이용해서, 여러 State 인스턴스 값이 가질 수 있는 무수히 많은 조합을 몇 가지의 카테고리로 줄여 Composition 재실행 횟수를 줄일 수도 있다.

 

#5 순환 참조 피하기

#5-1 안 좋은 코드

Box {
    var imageHeightPx by remember { mutableStateOf(0) }
    val density = LocalDensity.current.density

    Image(
        painter = painterResource(R.drawable.rectangle),
        contentDescription = "I'm above the text",
        modifier = Modifier
            .fillMaxWidth()
            .onSizeChanged { size ->
                imageHeightPx = size.height // 안 좋은 코드!
            }
    )

    Text(
        text = "I'm below the image",
        modifier = Modifier.padding(
            top = (imageHeightPx / density).dp
        )
    )
}

위는 이미지가 위에, 텍스트가 아래에 배치된 형태의 수직 Column을 잘못 구현한 코드다. 이 코드의 가장 큰 문제는 "단일 Frame만으로 최종 Layout이 완성되지 않는다"는 것이다.

 

#5-2 문제 분석

https://developer.android.com/develop/ui/compose/phases#recomp-loop

imageHeightPx는 onSizeChaged()에서도 쓰이고 padding()에서도 쓰인다. 전자에서 읽힐 땐 Layout 단계에서 추적되고, 후자에서 읽힐 땐 Composition 단계에서 추적된다. 때문에, imageHeightPx의 값이 Layout 단계에서 변하면 그 다음 프레임에서 Composition이 재실행된다. 프로그래머가 의도한 화면을 위해서 총 2프레임이 요구되는 것이다. 이러면 화면이 뚝뚝 끊어져서 보일 것이다. 이 부정적 패턴을 Cyclic Phase Dependency (단계 간 순환 참조)라는 이름으로 부른다.

 

#5-4 해결

Column()을 이용하기

Column {
    Image(
        painter = painterResource(R.drawable.rectangle),
        contentDescription = "I'm above the text",
        modifier = Modifier.fillMaxWidth()
    )

    Text(
        text = "I'm below the image",
        modifier = Modifier.padding(top = 16.dp)
    )
}

 

Jetpack Compose의 기본 컨테이너인 Column()을 사용한 가장 단순한 해결법. 

 

SubcomposeLayout() 이용하기

@Composable
fun CustomLayoutWithImageAndText() {
    Layout(
        content = {
            Image(
                painter = painterResource(R.drawable.rectangle),
                contentDescription = "I'm above the text"
            )
            Text(text = "I'm below the image")
        }
    ) { measurables, constraints ->
        // 자식 컴포넌트 측정
        val imagePlaceable = measurables[0].measure(constraints)
        val textPlaceable = measurables[1].measure(constraints)

        // 전체 레이아웃 크기 계산
        val layoutHeight = imagePlaceable.height + textPlaceable.height

        layout(constraints.maxWidth, layoutHeight) {
            // 이미지 배치
            imagePlaceable.place(x = 0, y = 0)
            // 텍스트 배치 (이미지 아래)
            textPlaceable.place(x = 0, y = imagePlaceable.height)
        }
    }
}

단일 진실 소스(Single Source of Truth) 원칙을 준수해서 State의 값의 관리가 (Image 및 Text에서) 중복되지 않도록 만든다.

 

장점:
SubcomposeLayout은 레이아웃 계산 단계를 분리하여 점프 현상을 방지합니다.
텍스트가 이미지의 높이에 자연스럽게 따라가도록 보장합니다.

 

하지만 더 복잡한 구조를 가진 사용 사례에서는 **사용자 정의 레이아웃(custom layout)**을 작성해야 할 수도 있습니다. 사용자 정의 레이아웃 작성에 대한 자세한 내용은 Custom layouts 가이드를 참고하세요.

 

위 내용을 정리하자면, Compose에서 다음 단계에 의존하는 순환적인 상태 흐름을 도입하지 않도록 주의해야 합니다. 적절한 레이아웃 구성 요소를 활용하고, 필요하다면 사용자 정의 레이아웃을 만들어 동작을 제어함으로써 재구성 루프 문제를 방지할 수 있습니다.