How You Get Your Compose UI From Hundreds of Recompositions to Almost Zero
- Jetpack Compose 리컴포지션 최적화는 실제 성능 문제가 있을 때만 고려해야 하며, 조기 최적화는 코드 품질을 저해할 수 있습니다. ⚠️
- Compose는 Composition(UI 구조), Layout(위치/크기), Drawing(픽셀) 세 단계를 거치며, 이 중 UI 구조 변경 시에만 리컴포지션이 필수적입니다. 🌳
LinearProgressIndicator처럼 람다를 통해 값을 전달하면 드로잉 단계에서만 업데이트되어 리컴포지션을 피할 수 있지만, 람다 자체의 참조가 변경되면 리컴포지션이 발생합니다. 🎨
PersonUI 객체 전체를 전달하거나 개별 필드를 전달해도, 내부 데이터 변경으로 람다가 재생성되면 리컴포지션이 발생하여 불필요한 리컴포지션으로 이어집니다. ♻️
rememberUpdatedState와 같은 Compose 이펙트 핸들러를 사용하여 람다가 내부적으로 변경되는 값을 참조하더라도 람다 자체의 안정성을 유지하여 불필요한 리컴포지션을 줄일 수 있습니다. 🧠
데브허브 | DEVHUB | How You Get Your Compose UI From Hundreds of Recompositions to Almost Zero