이젠 Compose가 아니면 개발하기 힘든 몸이 되
Compose는 안드로이드에서 새로운 Ui 개발 패러다임으로 기존 명령형 방식의 XML에서 Kotlin으로 개발 가능한 선언형 개발 방식이다.
처음 Compose를 접했을 땐 기존 XML 방식과 많이 달라서 적응하기 힘들었는데
이젠 Compose가 아니면 개발하는 여간 불편한 게 아니다..
1. Compose의 랜더링 단계
- 구성(Composition): UI 선언 및 트리 생성 UI 트리 구성 (상태와 연결)
- 레이아웃(Layout): 부모-자식 관계로 레이아웃 정의 각 컴포넌트의 위치 및 크기 제약 계산
- 측정(Measurement): 크기 측정 각 컴포넌트의 크기 반환
- 그리기(Drawing): 그래픽 렌더링 UI 요소를 실제 화면에 표시
기본적으로 Composable 함수는 위와 같은 단계를 거쳐 화면에 나타난다.
위와 같은 랜더링이 끝난 후 UI 요소를 수정한다고 하면 새로운 업데이트를 적용하기 위해 구성(Composition) 단계부터 다시 실행하는데 이 과정을 재구성(Recomposition) 이라고 합니다.
2. Stability
Compose에서 안정성(Stability)이 중요한 이유는
Compose에서 안정적이거나 불안정하다의 추론은 Compose 컴파일러에 의해 이루어 진다. 컴파일러는 Composable 함수에서 사용되는 매개변수의 유형을 검사하고 아래의 기준에 따라 안정성 여부를 분류한다.
- String을 포함한 기본 유형(Primitive)
- (String) -> String과 같은 람다 표현식으로 표현된 함수
- 모든 public property가 불변이고 (value로 정의된 경우) stable한 속성을 가진 클래스
- @Stable, @Immutable과 같은 stability 어노테이션을 사용하여 명시적으로 표기된 클래스
예를 들면
data class Person(
val name: String,
val age: Int
)모든 public property가 val이고 Primitive Type이기 때문에 stable하다.
data class Person(
val name: String,
var age: Int
)모든 public property가 Primitive Type이긴 하지만 age var이기 때문에 unstable하다.
3. Restartable 과 Skippable
Restartable
입력이나 상태가 변경될 때마다 Compose 런타임이 Composable 함수에 대해 recomposition을 트리거할 수 있다는 것을 의미한다.
Skippable
Smart recomposition에 의해 설정된 적절한 조건 하에서 recomposition 을 완전히 건너뛸 수 있다. 따라서 skippable한 Composable 함수는 특정 상황에 따라 recomposition을 건너뛰고 UI 성능을 향상시킬 가능성과 직접적인 연관성이 있다고 볼 수 있다.
skippable이라는 것은 해당 함수가 restartable한 Composable 함수에 대해 recomposition을 건너뛸 수 있음을 의미한다.
4. Immutable Collections
Compose에서 List는 불안정하다. 그 이유는 아래와 같다.
val mutableList = mutableListOf<String>()
val list: List<String> = mutableList위 코드에서 list는 List 인터페이스로 수정이 불가능 하지만, 구현체는 MutableList로 수정이 가능하다. 이때 Compose 컴파일러는 컴파일 타임에 구현 타입을 추론할 수 없기 때문에 이러한 인스턴스를 불안정한 것으로 처리한다. 이러한 이유로 개발자는 정확한 동작을 보장해야 한다.
kotlinx.collections.immutable 라이브러리
해당 라이브러리를 사용하면 안정적인 List, Set등의 Collection을 사용할 수 있다.
