[Mission] 요시 week8 완료#80
Conversation
hw4nx02
left a comment
There was a problem hiding this comment.
8주차 피드백
안녕하세요, 요시🦖! 서서히 종강이 다가오는 게 느껴집니다... 조금 더 파이팅해봅시다!!
총평
이번 주에는 Compose에서의 리스트 구현에 대해 학습했는데요. 이는 성능과 안정성에 직접적인 영향을 미치는 요소입니다. 때문에 불필요한 Recomposition을 방지하고, 스크롤 가능한 컴포넌트의 올바른 사용에 대한 고민이 항상 필요한 지점이라고 볼 수 있겠습니다!
기존 RecyclerView 기반의 목록을 Jetpack Compose의 Lazy Composable (LazyColumn, LazyVerticalGrid)로 성공적으로 마이그레이션하셨네요. 전반적으로 Compose의 모범 사례를 잘 따르려는 노력이 돋보이며, 특히 목록 아이템에 안정적인 키를 부여한 점이 인상적입니다!
리뷰
Good!
1. Lazy Composable로의 성공적인 마이그레이션
HomeScreen.kt에서 기존 RecyclerView를 Compose의 Lazy Composable로 잘 전환하여, 데이터를 효율적으로 렌더링하고 메모리 사용량을 최적화할 수 있는 상채로 보입니다.
2. 안정적인 아이템 Key 지정
PurchaseScreen.kt와 WishlistScreen.kt에서 items(items = ..., key = { it.id })와 같이 Product 모델의 고유 ID를 키로 사용하셨네요. 이를 통해 Recomposition 효율성을 높이고, 아이템의 상태를 안정적으로 유지하는 데에 도움이 되는 것 같습니다.
3. 위시리스트 상태 관리 및 공유
WishlistRepository를 remember(context) { WishlistRepository(context) }를 사용하여 한 번만 생성하고, 이를 NavGraphBuilder.mainGraph와 함께 활용하여 여러 화면에 주입하여 공유하고 있습니다. 또한, 위시리스트 상태를 mutableStateOf를 사용하여 Compose에서 반응적으로 상태를 관찰할 수 있도록 구현한 것이 인상적입니다.
To Improve!
1. WishlistScreen의 리스트 구성 최적화
WishlistScreen.kt 파일의 val wishedProducts = SampleProducts.filter { it.id in wishlistIds } 부분에서 wishlistIds가 변경될 때마다 전체 SampleProducts 목록을 다시 필터링하고 있습니다.
이와 같은 방식의 경우, wishlistIds가 변경될 때마다 SampleProducts 전체를 필터링하는 작업은 목록의 크기가 커지거나 wishlistIds의 변경이 잦을 경우 불필요한 Recomposition 및 성능 저하를 유발할 수 있습니다. 이 필터링 로직을 derivedStateOf로 감싸서 wishlistIds가 실제로 변경될 때만 재계산되도록 최적화하는 것을 고려해볼 수 있을 것 같습니다.
📌 PR 제목
#️⃣ 연관된 이슈
closes #79
✅ 변경 사항
📷 영상 및 스크린샷
android_week8_.mp4
🔗 알게 된 사항
📝 질문 사항