Android의 XML·View 기반 명령형 UI와 Jetpack Compose의 상태 기반 선언형 UI를 대비시키며, Compose가 화면을 그리는 내부 흐름을 단계별로 열어 보인다. "선언형이 편하다"에서 멈추지 않고 composition→layout→drawing, 그리고 recomposition까지 실제로 무엇이 일어나는지를 짚는다.
핵심 포인트- 기존 View 시스템은 XML 구조와 Kotlin 조작 코드가 나뉘어 어떤 코드가 어느 View를 바꿨는지 추적이 어렵지만, Compose는 상태에 따라 보여야 할 화면을 함수 안에서 선언해 가독성·추적성을 높임
- @Composable 함수가 UI 표현의 기본 단위이며, View 객체 대신 함수 호출과 입력값으로 화면을 기술하는 점이 Compose 모델 이해의 출발점
- 렌더링은 무엇을 만들지 정하는 composition, 크기·위치를 계산하는 layout, 픽셀을 그리는 drawing 순서로 진행되고 Modifier는 적용 순서에 따라 padding·background 결과가 달라짐
- 관찰 중인 상태가 바뀌면 그 상태를 읽은 UI 범위만 무효화(invalidation)돼 recomposition이 일어나고 이후 layout·drawing으로 변경분만 갱신해 전체 재생성보다 효율적
왜 읽나Compose를 쓰지만 recomposition이 왜·어디서 일어나는지 감이 없던 Android 개발자에게, 성능 튜닝과 상태 설계의 기반이 되는 내부 동작 지도를 준다.