Compose란?
Android를 위한 현대적인 선언형 UI 도구 키트입니다.
XML을 전혀 사용하지 않고 오직 코틀린으로만 사용하는 API라고 볼 수 있습니다!
왜 써야할까?
코드길이 감소
"동일한 버튼 클래스의 경우 코드의 규모가 10배 더 작았습니다.”
-트위터
“RecyclerView로 빌드한 모든 화면에서 상당한 감소 효과가 나타났습니다”
-Monzo
저는 여기서 가장 체감되는 부분은 바로 리사이클러뷰(RecyclerView) 입니다!
안드로이드를 공부하면 필연적으로 마주치고 많이 사용되는 뷰 중 하나인 리사이클러뷰를 설정하려면 어뎁터 설정, 리사이클러뷰에 들어갈 아이템설정, 재정의해야할 함수들 등등.. 설정 할 것들이 너무 많아 골치아픈 경험이 한번쯤 있습니다.
하지만 이런 골치아픈 과정에도 불구하고 리사이클러뷰가 제공해주는 최적화된 UI를 대체 할 수 있는 것이 없어서 울며 겨자먹기로 사용해야 했습니다
Compose를 사용하면 어떨까요?
놀랍게도 단 5줄이내로 리사이클러뷰의 대부분을 구현 할 수 있습니다 (제가 생각한 최소한의 기준😄)
이처럼 Compose를 이용하면 UI를 표현할 때 XML을 사용하지 않고 코틀린만을 활용해 작성하기 때문에 코드의 길이가 대폭 감소하는 효과를 누릴 수 있습니다!
직관성
위 화면을 예시로 들겠습니다!
만약 화면에 Hello World를 쓰려면 어떻게 해야할까요?
XML을 사용한다면 레이아웃의 종류를 설정하고, 그에따른 텍스트뷰를 설정한 뒤 UI를 표시할 코드로 넘어와 뷰바인딩이나 findViewById()를 활용해 표현 할 것입니다.
하지만 Compose를 활용하면 위 사진처럼 단 1줄로 해결이 가능합니다!
심지어 코틀린으로 작성이 가능하기 때문에 XML 문법을 배울 필요도 없습니다!
동적 활용
@Composable
fun Greeting(names: List<String>) {
for (name in names) {
Text("Hello $name")
}
}위 코드는 리스트로 받은 names를 모두 텍스트로 보여주는 아주 간단한 코드입니다!
UI와 코틀린을 결합했기 때문에 이렇게 동적인 표현도 가능합니다!
즉 코틀린 문법을 UI에 적용시킬 수 있기때문에 유연성과 확장성 측면에서도 아주 유용하게 사용될 수 있습니다
재구성의 최소화
@Composable
fun NamePicker(
header: String,
names: List<String>,
onNameClicked: (String) -> Unit
) {
Column {
// header가 변경될때만 리컴포즈됨
Text(header, style = MaterialTheme.typography.bodyLarge)
Divider()
// LazyColumn는 컴포즈의 리사이클러뷰!
LazyColumn {
items(names) { name ->
// name이 바뀔때만 리컴포즈됨
NamePickerItem(name, onNameClicked)
}
}
}
}
@Composable
private fun NamePickerItem(name: String, onClicked: (String) -> Unit) {
Text(name, Modifier.clickable(onClick = { onClicked(name) }))
}Compose는 업데이트해야 하는 부분만 재구성하기 위해 최선을 다한다고 합니다!
즉 효율적인 렌더링 방식을 사용하기 때문에 자원을 효율적으로 사용 할 수 있다는 장점이 있습니다!
결론
Compose를 왜써야하는지 최대한 요약하며 글을 마치려고합니다!
이외에도 많은 개념들이 있지만 이건 추가적으로 더 알아보시면 될 것 같습니다!
공식문서를 확인하면 Compose의 업데이트가 활발한 것과, 프로젝트 기본설정이 Compose로 된 것을 봤을 때 추후 XML은 사용되지 않을 것이라고 느껴집니다 😂
하지만 Compose도 재구성(recompose)을 제대로 다뤄주지 못한다면 치명적인 자원낭비를 초래 할 수 있다고 합니다. 추후 Compose만의 생명주기에 대해서도 자세히 공부하고 포스팅 해보겠습니다!
