핵심 공식
대략적인 디코딩 메모리:
메모리 바이트 ≈ width × height × 4 (RGBA8)
메모리 MB ≈ width × height × 4 / 1024 / 1024- 4000 x 3000 이미지: 약 45.8MB
- 3000 x 3000 이미지: 약 34.3MB
iOS Development Guide
대형 이미지가 메모리를 많이 쓰는 이유
파일 용량(JPEG/PNG KB)과 메모리 점유(RAM MB)는 다르다. 화면 표시 시에는 압축이 풀린 픽셀 버퍼 크기가 메모리를 결정한다.
학습 날짜
2026-04-29
왜 문제가 되나
- 스크롤 리스트에서 큰 이미지를 여러 장 동시에 들고 있으면 급격히 메모리 증가
- 첫 렌더링 시 디코딩 비용으로 프레임 드랍 발생
- 메모리 압박 시 앱이 백그라운드/종료될 위험 증가
파일 용량이 작아도 메모리가 큰 이유
| 구분 | 의미 |
|---|---|
| 파일 용량 | 디스크/네트워크에서 전송되는 압축 데이터 크기 |
| 메모리 점유 | 렌더링을 위해 압축을 푼 픽셀 버퍼 크기 |
JPEG 1MB 이미지라도 해상도가 크면 메모리에서는 수십 MB가 될 수 있다.
실무 대응
- 표시 크기에 맞춰 다운샘플링
- 썸네일/원본 분리 저장
- 메모리 캐시 제한 설정(NSCache cost)
- 셀 재사용 시 이전 요청 취소 및 이미지 해제
체크리스트
- 원본 해상도 그대로 표시하고 있지 않은가
- 동시 표시 셀 수 대비 이미지 메모리 합이 과도하지 않은가
- 스크롤 시 디코딩이 메인 스레드에 몰리지 않는가
Q&A 정리 (디코딩/캐시/스크롤)
| 질문 | 핵심 답 |
|---|---|
| 첫 렌더링 시 디코딩 비용으로 프레임 드랍? | 압축 이미지를 픽셀 버퍼로 푸는 작업이 메인 스레드 타이밍과 겹치면 프레임 예산(약 16.7ms)을 초과해 버벅임이 생긴다. |
| w × h × 4로 메모리 계산? | RGBA8 기준의 빠른 추정치로 유효하다. 대략 MB는 w × h × 4 / 1024 / 1024. |
| imageView.image = nil이면 즉시 메모리 제거? | UIImageView의 강한 참조를 끊는 것이다. 다른 참조/캐시에 남아 있으면 즉시 해제되지 않는다. |
| 캐시에 있으면 재디코딩 없음? | 항상은 아니다. 같은 디코딩 버퍼가 유지되면 비용이 작지만, 메모리 상황/경로에 따라 다시 디코딩될 수 있다. |
| UIImage면 항상 디코딩 완료? | 아니다. UIImage(data:)는 표현 객체 생성이고, 실제 디코딩은 첫 표시 시점까지 지연될 수 있다. |
| 셀 재사용 시 무엇을 해야 하나? | 이전 요청 취소 + 이미지 참조 해제 + 새 모델 기준 재요청. 늦게 도착한 이전 이미지 덮어쓰기를 막는 것이 핵심이다. |
| 백그라운드 디코딩 가능? | 가능하다. 다운로드/다운샘플/디코딩은 백그라운드, 최종 imageView.image 할당만 메인에서 처리한다. |