메뉴 품절 처리 업무를 하던 중, 사내식당 메뉴 이미지 너무 늦게 나오는 걸 확인했다,,,

속 뒤집어질 뻔,, 그래서 한 번 고쳐보기로 했다,, (이건 무조건 고쳐야해,,)

왜 느릴까?

원인 1️⃣

이미지 URL이 메인 API(ENT_LGN_000002) 응답에 들어있어 API 완료 + 셀 표시 후에야 다운로드 시작 (직렬 체인)

해법 1️⃣ → 프리페치 - URL을 아는 즉시 미리 받기 (MainViewModel)

원인 2️⃣

다운로드 중 이미지 영역이 완전히 빈 화면 → 지연이 더 크게 체감

해법 2️⃣ → 로딩 상태를 즉시 보여주기 (MealMenuCollectionViewCell)

원인 3️⃣

원본 크기 그대로 다운로드, 디코딩

해법 3️⃣ → 다운 샘플링 - 셀 크기 (145x150pt) 만큼만 디코딩 (양쪽 공통 context)

셀과 프리페처가 완전히 동일한 다운샘플링 옵션(context)을 써야 SDWebImage 캐시 키가 같아져서, 프리페치 해둔 이미지를 셀이 실제로 꺼내 쓴다.

옵션이 다르면 키가 달라져 같은 이미지를 두 번 받는다.

어떻게 설계할까?

1. 크기 상수는 한 곳에만 (SSOT)
   • SSOT 란?
   • 셀과 프리페처가 같은 캐시 키를 봐야하므로 thumbnailPixelSize static 상수 하나를 양쪽이 참조.
     • “셀 bounds에서 동적으로 읽으면 되지 않나?” → 프리페치는 셀이 만들어지기 전에 실행되므로 읽을 bounds 가 없음,, - 레이아웃 이전에 양쪽이 다 아는 값이어야 하고, 그게 static 상수인 이유
2. 프리페처는 전용 인스턴스
   • SDWebImagePrefetcher.shared 에 context를 설정하면 싱글톤이 오염 → 나중에 다른 화면이 프리페치를 도입하면 식단용 다운샘플링 옵션을 몰래 상속 받음,, 전용 인스턴스에 격리하면 부작용의 범위가 이 기능 안에 갇힌다.
3. 셀은 “리셋 → 재설정” 계약
   • 재사용되는 셀의 상태는 딱 두 메서드만 만진다: prepareForReuse 가 항상 깨끗이 비우고(이미지, 스켈레톤, 구독), configureCell 이 항상 처음부터 다시 채운다. 상태 변경 지점이 두 곳 뿐이니 잔상, 구독 누적 같은 “이전 셀의 흔적” 버그가 구조적으로 생길 수 없다.