[Compose] Jetpack Compose 및 State

기존의 명령형 UI 구성 방식

• Compose 이전의 기본 Android 뷰 계층 구조는 UI 위젯의 트리로 표시할 수 있었다.
• 레이아웃을 맨 아래에 깔고 그 위에 브랜치처럼 텍스트뷰, 이미지뷰를 넣고 다시 레이아웃을 넣는 등 쌓아가는 개념으로 뷰를 그렸다.
  • 이와 같은 작업 방식은 개발자로 하여금 XML 이라는 막대한 리소스를 반복적으로 낭비하게 하며, 노드를 변경하기 위해 findViewById, viewBinding, dataBinding 을 통하여 노드에 접근하고 setText(), setImageBitmap( ) 등의 메서드를 사용하여 변경해야 한다.
    • 이런 접근 방식은 불필요한 코드를 만들 뿐만 아니라 한 노드에 대한 업데이트의 충돌이 발생할 확률을 높이게 된다.
• Java/Kotlin 코드와 높은 의존성을 가진다.
  • 이미 완성된 앱에서 버튼을 하나 제거하고 싶다면, 단순히 XML 에서 버튼을 삭제하는 것으로 끝나지 않는다. 해당 버튼과 연결된 Java/Kotlin 코드도 함께 삭제하지 않으면 오류가 발생할 수 있다.
• 화면 요소의 재사용성이 낮다.
  • 5개의 입력 칸이 있는 회원가입 화면을 만들고자 할 때, 입력 칸이 모두 동일한 형태라 하더라도 각각의 EditText 를 개별적으로 만들어야 한다.
• 코드가 길고 보일러플레이트가 많다.
  • XML 언어의 특성과 앞서 언급한 재사용성 문제로 인해, 레이아웃이 복잡해질수록 코드가 비대해지고 가독성이 떨어지게 된다.

 

선언형 UI 구성 방식

• Jetpack Compose : Android 네이티브 UI 를 빌드하기 위한 현대적인 선언형 UI 툴킷
  • 뷰를 명령형으로 변형하지 않고도 앱 UI 를 렌더링 할 수 있게 하는 선언형 API 를 제공하여 UI 개발을 간소화하고 가속화한다.
• 화면 전체를 개념적으로 재생성한 후 필요한 변경사항만 적용하는 방식으로 적용된다.
• 뷰마다 상태(State)가 있고, 이 값을 변경하게 되면 새로운 화면을 생성해서 다시 화면을 업데이트하게 된다. 따라서 개발자는 상태 변화에만 집중을 하면 된다.
  • 이러한 접근 방식은 스테이트풀(Stateful) 뷰 계층 구조를 수동으로 업데이트할 때의 복잡성을 방지할 수 있다.
• 코드 감소 : 적은 수의 코드로 더 많은 작업을 하고 전체 버그 클래스를 방지할 수 있으므로 코드가 간단하며 유지 관리하기 쉽다.
• 직관적 : UI 만 설명하면 나머지는 Compose 에서 처리한다. 앱 상태가 변경되면 UI 가 자동으로 업데이트되게 된다.
• 빠른 개발 과정 : 기존의 모든 코드와 호환되므로 언제 어디서든 원하는 대로 사용할 수 있다. 실시간 미리 보기 및 Android 스튜디오 지원으로 빠른 개발을 지원한다.
• 강력한 성능 : Android 플랫폼 API 에 직접 액세스 하고 머티리얼 디자인, 다크 테마, 애니메이션 등을 기본적으로 지원하는 멋진 앱을 만들 수 있다.

---

Compose State

• 상태가 변경되면 영향을 받는 Composable 함수를 새 상태로 재실행하여 새로운 업데이트 UI 가 생성되며 이를 Recomposition 이 발생한다고 표현한다.
• 매번 모든 Composable 코드를 재실행할 수는 없기에 영향을 받지 않는 요소들은 건너뛰고 개별 Composable 에 필요한 데이터만 확인하여 업데이트한다.
• 그렇기에 Compose 가 UI 업데이트를 위해 어떤 상태를 추적해야 하는지 알아야 한다. 그래야 해당 상태가 업데이트될 때 Recomposition 을 예약할 수 있기 때문이다.
• Compose 에는 특정 상태를 읽는 Composable 의 Recomposition 을 예약할 수 있는 특정 상태 추적 시스템이 있다.
  • 이를 통해 Compose 가 전체 UI 를 변경하지 않고 일부 Composable 만 재구성할 수 있다.
  • 해당 작업은 쓰기(상태 변경)뿐만 아니라 상태에 대한 읽기도 추적하여 실행된다.
• Compose 의 State 와 MutableState 를 사용하여 Compose 에서 상태를 관찰할 수 있다.
  • 상태 Value 속성을 읽는 각 Composable 을 추적하고 해당 value 가 변경되면 Recomposition 을 트리거한다.
• mutableStateOf 함수를 사용하여 관찰 가능한 MutableState 를 만들 수도 있다.
  • 해당 함수는 initial 값을 매개변수로 받아 State 객체에 래핑하여 상태의 value 값을 관찰 가능한 상태로 만든다.
• Compose 에서는 Composable Inline 함수인 remember API 를 지원한다.
  • remember 로 계산된 값은 Initial Composition 중에 Composition 에 저장되고, 저장된 값은 Recomposition 발생 시 유지된다.
• Compose 에서 상태를 저장한 뒤 읽었는데 크기가 비교적 큰 데이터는 UI 코드로 저장하기엔 부담이 있다.
  • ViewModel 등으로 분리하여 데이터를 보관하는데 해당 데이터가 변경될 때 인지하여 UI 를 변경해야 하는 상황이 필요하다.
  • 일반적으로 LiveData, StateFlow, Flow, Observable(RxJava) 등 관찰 가능한 유형을 사용하여 상태를 앱에 저장할 수 있다.
    • 이들은 단순히 관찰 가능한 데이터일 뿐, Compose 가 해당 데이터 객체를 관찰하고 상태가 변경될 때 자동으로 재구성되도록 하기 위해선 State 로 매핑해야 한다.

 

저장된 상태 기반 UI

• Compose 는 선언한 UI 프레임워크이므로, 상태 변경 시 UI 구성요소를 삭제하거나 공개 상태를 변경하지 않고, 특정상태의 조건에서 UI 가 어떻게 존재하는지 설명한다.
• Recomposition 발생 이후 UI 가 업데이트된 결과로 Composable 이 Composition 을 수행하거나 종료할 수 있다.
• UI 를 설명하는 Composition 이 존재하고, Composable 이 Composition 으로 진입한 뒤 현재 상태에 따라 n 회 Recompose 된다.
• 이후 조건에 맞지 않으면 Composition 에서 사라져 종료된다.
• 결국 Composable 함수가 Initial Composition 이나 Recomposition 에서 호출되는 경우에만 Composition 에 Composable 함수가 위치하고, 호출되지 않는다면 Composable 함수는 더 이상 Composition 에 존재하지 않음을 의미한다.

 

---

[Android] Jetpack Compose란

Android | Jetpack Compose Remember State