[Android] Image 처리 – 캐시 Intro

이미지가 안 쓰이는 안드로이드 앱이 있을까? 할 정도로 안드로이드 앱에서의 이미지는 기본적인 요소라고 볼 수 있다. 그럼 과연 이미지 처리에 대해 얼마나 자세히 알고 사용하는가?

솔직히 고백하자면, 이미지 처리에 대해 크게 신경쓰지 않았다.
ImageView에 그냥 drawable 리소스를 할당하는 것이 전부였다. 혹은 Glide 같은 이미지 로딩 라이브러리를 사용하여 이미지를 꽂아주는 정도가 전부였다. 이미지 캐시? 등에 대해 고민해본 적이 없다.

최신 폰을 사용해서인가? 아무런 문제 의식을 갖지 못했기 때문이다. 얼마 전 사내 행사를 위해 개발한 앱에서 이미지 버벅이는 문제를 경험했으나 간단히 이미지 파일 사이즈를 줄여 해결했다. 

dev-youknow.tistory.com/17

절대 문제에 대해 심도있는 접근법이라고 할 수 없다.
거기에 최근 면접을 봤던 회사에서도 이미지 처리에 대한 좀더 심도 있는 경험기를 질문받았는데, 답변을 할 수 없었다. 그 회사에서 원했던 점은 이미지 버벅이는 문제에 대해 어떤 캐시 알고리즘을 적용했는지, LRU Cache가 뭔지 등을 알기 원하는 것 같았다. 경험이 없었기에 답변할 수 없었고, 이번 기회에 정리하고자 한다.

---

먼저 이미지 처리에 이토록 신경써야 하는 이유는 네이버 공식 개발자 블로그에서 아주 상세히 제시하고 있으니 참고하기 바란다.

이미지 캐시

앱에서 이미지를 쓰는 보편적인 시나리오를 생각해보면 리스트 뷰를 들 수 있다. (SNS나 게시판, 뉴스 리스트 UI에 이미지 섬네일이 보이는 화면) 이런 화면에서는 수 많은 이미지들을 그리게 되는데, 이러한 이미지는 또한 앱 내에 존재하는 이미지가 아니라 외부 서버로부터 다운로드 받아 그리는 케이스가 많다. 따라서 UI 스크롤이 일어날 때마다 매번 엄청난 양의 이미지를 HTTP 통신으로 다운로드 받아 그려줘야 한다. 이는 성능에서도 그렇고, 사용자 네트워크 데이터 사용 면에서도 그렇고 굉장히 비효율적이다. 따라서 이미지 캐시가 필요하다.

이미지 캐시는 아래와 같이 두 가지로 생각해볼 수 있다.

• Memory Cache
• Disk Cache

상세한 설명은 뒤로 하고, Memory, Disk 단어에서도 두 단계 캐시임을 대충 눈치챌 수 있다. 이는 아래와 같은 그림으로 설명된다.

refer: https://d2.naver.com/helloworld/429368
네이버 공식 블로그에서 이미지 캐시에 대한 설명을 표현한 그림인데 굉장히 이해하기 쉽다.

• Memory Cache Hit의 경우, 메모리 상에서 바로 불러와 “이미지 후처리”만 거친 후 사용자에게 바로 보여진다.
• Disk Cache Hit의 경우, “이미지 디코딩”을 한 후 Memory에 캐싱, “이미지 후처리”를 거쳐 사용자에게 보여진다.
• Cache에 없는 경우 (Worst case) 인터넷에서 다운로드받아 위 과정을 모두 거쳐 사용자에게 보여준다.

이미지 캐시에 대해서는 구글 공식 개발자 문서에서도 다루고 있다. 그런데 보면 알겠지만, 구글 공식 문서에서도 Glide를 사용할 것을 권장하고 있다. 그러니 일단 닥치고 Glide를 쓰자!