compose를 사용안하는 10가지 이유 (25.01.06)

https://medium.com/@sonique6784/10-reasons-to-not-use-jetpack-compose-719de5d37c9e

10 reasons to NOT use Jetpack Compose

 

소개 

컴포즈는 좋은 UI 툴킷이라고 안드로이드 커뮤니티에서 따뜻하게 환영받았습니다. 그것은 종종 너의 안드로이드 앱에 좋은 방식입니다. 

나는 컴포즈를 좋아하지만, 어떤 기술에는 주의사항이 있다고 생각합니다. 이 아티클에는 어떤 경우에는 뷰 시스템을 활용하는게 더 좋은지에 대해 배울것입니다. 

 

1. 가능한 최소한의 의존성 

컴포즈는 많은 임포트를 요구합니다. 너가 가능한 최소한의 의존성을 요구한다면, 이것은 보안 목적과 호환성을 원하는것일겁니다. 

그럼 뷰 시스템이 훨씬 더 좋은 선택입니다.  뷰 시스템은 추가적인 임포트가 필요 없습니다. 이것은 안드로이드 내부에 존재하며 여러 종속성을 요구해 패키지 크기와 런타임 시에 메모리 사용량을 증가시키고 추가적인 위험 가능성을 열어두는 컴포즈와는 다릅니다. 

 

2. 성능

뷰 시스템은 안드로이드 처음 버전부터 지금까지 사용되어왔습니다.  이건 아주 성숙합니다.  15년동안 많은 최적화가 있었고, 복잡한 레이아웃을 구성할때에 컴포즈보다 성능적으로 뛰어납니다. 컴포즈는 매번 향상되고 있으며, 어떤 경우에는 뷰보다 이미 더 좋습니다. 앞으로의 발전을 지켜보세요. 뷰가 곧 성능 왕자를 내어질수도 있습니다. 

 

3. 에스프레소 테스트 

에스프레소 테스트는 컴포즈에서 이용불가능합니다

뷰를 기반으로 하는 에스프레소 테스트가 많거나, 안드로이드 스튜디오의 테스트 녹화 기능을 사용하고 싶다면, 컴포즈를 피하거나 새로운 뷰에 대해서만 컴포즈를 고려하는게 좋습니다. 컴포즈에서 뷰기반에 에스프레소 테스트 마이그레이션은 쉽지 않습니다. 게다가 에스프레소 녹화는 컴포즈에서 이용불가능합니다. 하지만 컴포즈 에스프레소 테스트는 수동으로 가능합니다

 

4. 안정성과 성숙함

퍼포먼스 섹션을 간략하게 소개해보겠습니다. 컴포즈는 3년이 되었고, 매번 향상 된 릴리즈버전을 내고 있습니다. 하지만 매번 버그들이 나오고 있습니다. 게다가 많은 컴포즈 기능들은 여전히 실험중이고, 사용하려면 옵트인(선택적 활성화)를 위한 어노테이션이 필요합니다. 

실험적 기능을 사용하는건 비즈니스에 문제를 일으킬수 있습니다. 

// Some feature, like modifier, layout and material design are experimental
// and require to OptIn explicitely
@OptIn(ExperimentalMaterialApi::class)
@OptIn(@ExperimentalFoundationApi::class)
@OptIn(ExperimentalComposeUiApi::class)
@OptIn(ExperimentalLayoutApi::class)

 

만약 너가 높은 성숙함과 안정성을 요구한다면 너는 뷰시스템을 유지하는게 좋을수 있다 .

 

5. 누락된 기능 

뷰시스템은 안드로이드의 역사중 한 부분입니다. 많은 안드로이드 기능은 먼저 뷰 시스템에서 사용할 수 있으며, 이후에 compose로 포팅됩니다. 종종 컴포즈는 단지 wrapper만 제공되는 경우도 있습니다. (구글맵). 그래서 너는 컴포즈에서 기능들이 완전히 이용가능해질떄까지 뷰 시스템을 유지해야합니다.

뷰 전용 시스템에 접근하기 위해 AndroidView를 사용할 수 있다는 점에 유의하세요 컴포즈도 결국 그 수준에 도달하긴 할거에요.

 

6. 기존앱에 널리 사용됨

당신은 경력 동안 뷰를 다뤄야 할 가능성이 높습니다. 많은 큰 회사들은 컴포즈를 도입했더라도 여전히 View를 사용하고 있습니다. 

뷰 화면을 컴포즈로 마이그레이션 하는 것은 높은 비용을 요구하고 최종 사용자에게 상대적으로 낮은 가치를 제공할수 있습니다. 많은 회사는  점진적으로 컴포즈를 채택하며, 기존에 UI 시스템은 그대로 유지합니다.  View를 Compose로 효과적으로 변환하려면 View에 대한 기술이 필요할 수 있습니다. 

 

7. APK 크기

릴리즈 빌드에서 컴포즈는 7MB의 용량을 차지하며, 뷰를 사용하며 이를 완전히 피할수있습니다.

패키지에 사이즈를 고려해야 한다면, 컴포즈 채택을 다시한번 고려해야합니다. 컴포즈는 패키지에 적어도 몇 MB가 증가됩니다. R8 full모드를 허용한다면 크기를 더 줄일 수 있습니다. 반면에 뷰 시스템은 컴포넌트가 시스템의 일부이므로 추가 라이브러리를 필요로 하지않아 거의 용량을 차지하지 않습니다. 

 

8. 오래된 디바이스와의 호환

컴포즈는 안드로이드 API21 버전(롤리팝) 부터 지원을 요구합니다. 너가 만약 이전버전에 디바이스들이 있다면 뷰를 사용해야합니다. 

 

9. IOT 장치들과 임베드 

한가지 목적(키오스크, 결제 시스템, 셀프 체크인)을 위한 장치들은  종종 앱 하나만 실행되고, CPU와 램에 제한된 리소스를 가지고 있습니다. 컴포즈는 무거울수 있으며, 안드로이드 개발자들이 기기 사향에 맞추기 위해 뷰 시스템을 사용할수도 있습니다.

장치는 아마도 안드로이드 4 버전보다 오래되었을 수도 있습니다.

 

10. 새로운 것을 배우고 싶지 않을떄 

아마도 당신이 경력의 끝에 있거나, 다른 분야로 이동하려고 한다면 컴포즈를 배우는건 의미가 없는 상황이 될수도 있습니다. 컴포즈는 약간 러닝커브가 있습니다. 왜냐면 뷰와 다르게 아예 새로운 UI 개발 방식이기 때문입니다.  그렇긴하지만 일부 원칙들이 react와 flutter와 같은 다른 프레임워크들에서도 사용되기에 배우는건 유용할 수도 있습니다. 

 

결론

컴포즈는 좋은 UI 툴킷이고, 확실히 안드로이드의 미래입니다. 하지만 컴포즈는 유일한 UI 툴킷이 아니며, 뷰 시스템은 이미 잘 동작함을 입증했습니다. 일부에서는 뷰를 레거시 시스템으로 간주하지만, 자신의 요구사항과 제약에 맞는 것을 선택하는것이 좋습니다. 

너의 선택은 언제든 좋습니다. 안드로이드 개발은 풍부하고 다양하며, 이러한 강점들을 활용하는것이 안드로이드 개발자로써 우리의 역할ㅇ입니다. 

 

이 기사를 읽어줘서 고맙고, 나는 즐기길 희망하고, 새로운걸 배우길 원합니다. 

 

 

기타

delightful 기쁨을 주는

caveats. 주의사항 

mature 성숙한 

optimisation 최적화 

watch this space 앞으로의 발전 

briefly 간략한

problematic 문제가 있는 

stick to 유지하다 , 무엇을 계속하다 

widely 널리 

relatively 가치 

progressively  점진적으로 

totally 완전히 

a bit steep , 약간 가파르다 

principles 원칙 

certainly 확실히 

demonstrated 입증하다 

consider 간주하다 , 고려하다 

levarage 영향력, 역할