[우아콘 2024] XML에서 Compose로의 전환 (Feat. 안드로이드)

 

우아콘 2024 ❘ XML을 Compose로 전환하기

 

이번 우아콘 2024에서 "XML을 Compose로 전환하기" 세션에 참석했습니다.

기존의 XML 기반 UI를 Jetpack Compose로 전환하는 과정에서의 경험을 들은 이후, 사견에 대해 공유하고자 합니다 :)

 

1. 전환 계기

우아한형제의 안드로이드 팀에서는 공통 디자인 시스템 구축을 위해 Compose를 도입하기 시작했습니다. 단순한 공통 시스템을 위해 Compose를 도입하는 것이 적절한지에 대한 의구심이 있었으나, 선언적 UI의 이점과 코틀린만으로 개발이 가능하다는 점이 매력적으로 작용하여 도입을 결정지은 듯 합니다.

 

 

2. Compose의 장점

아래 내용 중 예상하건데, 점진적 전환이 가능했기에 서비스에 도입할 수 있지 않았을까요?

• 선언형 UI로 인한 성능 개선 : 화면의 변경되는 부분만을 다시 그린다.
• 코틀린 기반 개발 : XML 없이 코틀린 코드만으로 UI를 구성한다.
• 점진적 전환 가능 : Compose와 XML을 함께 사용할 수 있어 완전한 전환히 아니어도 도입이 가능하다.
• RecyclerView 대체 : 어댑터 등의 작성 없이도 리스트 UI를 구현할 수 있다.

 

 

3. Compose의 단점

• 기존 서비스와의 호환성 문제
• 부족한 기능 : 일부 기능(예 : AutoSizeText)이 Compose에서 지원되지 않아 재정의해야 한다.

 

 

4. 활용

4-1. 요소의 정렬

한글과 숫자를 함께 사용할 때 중앙 정렬이 어려운 문제가 있었습니다. 이를 해결하기 위해 AlignmentLine과 Baseline을 활용한 alignByBaseline을 사용했습니다. 그러나 한글 기준의 Baseline 지원 여부와 XML에서의 지원은 추가적인 확인이 필요합니다.

 

4-2. 아이콘 삽입

텍스트 사이에 아이콘을 삽입하는 기능을 구현했습니다. alternativeText의 대괄호 안에 아이콘을 넣는 방식으로, 이는 접근성을 고려한 처리로 보입니다.

 

4-3. SubcomposeLayout

가로 스크롤이 가능한 그리드 레이아웃에서 높이를 고정해야 하는 상황이 있었습니다. SubcomposeLayout을 활용하여 요소들의 높이를 미리 계산하는 방식으로 해결했습니다.

 

4-4. 높이가 다른 가로 스크롤

가장 높은 아이템의 높이를 기준으로 레이아웃을 고정해야 했습니다. 그러나 LazyRow는 뷰가 그려지기 전까지 높이를 알 수 없어 어려움이 있었습니다. 이를 해결한 것 역시 Compose를 통해...

 

4-5. AutoSizeText

글자 수에 따라 글자 크기가 줄어드는 기능이 필요했지만, Compose에서는 기본 제공되지 않아 TextMeasurer를 활용하여 재정의했습니다. 그리고 TextMessurer에 대해 추가적으로 정보를 파악하면 어떨까요?

 

 

5. Compose로 바꿔야 하는가

• 기능 구현의 가능성 : 소개된 활용 사례들이 XML로도 구현이 가능한건 아닐지 생각합니다.
• 전환의 필요성 : 공통 디자인 시스템 구축이나 특정 기능을 위해 Compose로의 전환이 꼭 필요한지에 대한 의문이 있습니다.
• 부족한 기능 보완 : Compose에 아직 없는 기능들이 있음에도 불구하고 전환하는 이유는 무엇일까요?

 

 

6. 결론

안드로이드 팀의 현재 과제는 Compose의 완전한 전환일까요, 아니면 새로운 기술이나 관심사에 집중하는 것일까요? Compose 도입은 여러 장점이 있지만, 호환성 문제와 부족한 기능에 대한 보완이 필요해 보입니다. 전환 여부는 팀의 목표와 프로젝트의 특성에 따라 신중하게 결정해야 할 것 같습니다.