경고: 긴 답변.
테스트 해 보시면 되죠.
arraylist에 십만개의 Object를 넣는다고 해도,
텍스트는 양이 얼마 안될 겁니다. 텍스트 하나를 Unicode라면 3바이트로 계산해 보세요.
그냥 1메가짜리 JPEG이미지를 화면에 띄우는 메모리 사용량 보다도 못하겠죠.
4K*2K 이미지가 4바이트 rgba 모드로 띄우면 순간적으로 32메가 바이트의 메모리를 차지합니다.
Glide로 올리면 2바이트나 12비트로 낮추어진다면 12메가 ~ 16메가 사이의 용량을 차지 하겠죠.
그 이미지가 리사이클러 뷰에서 끊임없이 스크롤해도 잘 죽지 않습니다.
텍스트는 그에 비하면 껌입니다.
물론 그런 Request와 Response를 왜인지 모르지만 모두 보관한다면,
시간이 지날 수록 메모리를 차지하겠죠.
앱은 샌드박스로 동작하므로, 안드로이드가 지나친 메모리를 하나의 앱에서 가져가게 허용하지 않을겁니다.
게다가 하나의 앱이 계속 최상단에 떠 있는 경우는 매우 드뭅니다.
특별한 앱이 아닌이상, 백그라운드에서는 통신을 거의 안하게 되기 때문에,
메모리는 특정 사용량에서 멈춰있다가
최상단으로 올라갈 때 다시 로드되겠죠.
그게 많아지면, 안드로이드가 알아서 킬을 할 것이고,
Killed 된 앱이 다시 로드되어도 사용자가 거의 알아챌 순 없죠.
이전의 화면을 기억한다면, 어 다시 실행되었네. 하겠죠.
리사이클러뷰는 효율적으로 메모리를 재사용하기 때문에, 안전하게 사용할 수 있지만,
사용자가 굳이 이미지 버퍼를 직접 핸들링하게 되면, 메모리 릭으로 죽을 수는 있습니다..
그러나 그런 뻘짓만 안한다면,
그정도의 용량은 크게 문제가 안될 것으로 보여요.
다만, 잘 만들어진 앱은 사용 메모리가 늘어나지 않게 관리해야 한다고 생각합니다.
Requet와 Response는 gson 같은 거로 파일에 저장하면 되기 때문에,
굳이 과거의 히스토리를 메모리에 가지고 가는 것은 문제가 있죠.
다만, 파일로 저장할 때는 암호화해서 저장하기만 한다면, 큰 문제는 없으리라고 봅니다.
Hotels.com 앱이, 호텔 예약한 바우처를 로컬에서 암호화해서 보관해서 보여줍니다.
왜냐하면, 여행자들이 비행기를 탈때, 인터넷이 안되는 환경에서 호텔예약정보를 볼 수 있어야,
입국신고서에 호텔 주소등을 입력할 수 있기 때문입니다.
그리고 외국에 나가면 인터넷이 일시적으로 불통일 수 있기 때문에,
바우처를 보관해서 보여줄 수 있는 기능을 제공합니다.
언제든지 취소할 수 있기 때문에, 해당 바우처가 호텔에서 확인이 안될 수는 있지만,
선의의 고객을 위한 기능이라고 봐야겠죠.
그런 경우에는 바우처를 gson 으로 암호화해서 보관하고,
다시 불러오면 됩니다.
이야기가 길어졌네요~.
질문을 좀 더 명확하게 핵심포인트만 집어준다면,
답변은 짧아질 수 있습니다.
대부분의 개발자들이 이런 질문을 피하게 됩니다.
왜냐하면, 지속적으로 추가 질문이 예상되기 때문이죠.
개발자들은 누구나 다들 바쁘게 살기 때문이죠. ^^*
