[iOS] 반나절동안 메모리 사용량 91% 감소시키기

들어가며

https://apps.apple.com/kr/app/%EB%B9%84%EB%A7%88%EC%9D%B4%ED%94%8C%EB%9E%9C-%EC%97%AC%ED%96%89-%EC%BD%94%EC%8A%A4-%EC%8A%A4%ED%86%A0%EC%96%B4/id1627682568

(👇 앱 스토어 링크)

‎비마이플랜 - 여행 코스 스토어

나는 현재 여행 코스 스토어 비마이플랜의 유지, 보수, 신규 기능 개발을 맡고 있다.
.
그동안 팀에 합류하고 크고 작은 5-6차례의 업데이트를 해왔는데, 짧은 호흡으로 제한된 시간 동안의 개발을 하다보니 놓치고 있는 부분들이 있었다.
.
특히 이번 스프린트 동안 개발을 하다가 크게 문제가 있음을 확인했다. 개발을 하다가 디버깅을 하다보니 메모리 사용량이 끝도 없이 올라가고 있던 것이다. 화면 전환을 좀 많이 하다보니 메모리 사용량이 높아지고 결국에는 앱이 종료되는 상황을 겪었다.

 

메모리 사용량이 1.93GB..?

 

뭐가 문제지.. 그냥 못 본 척 할까?
는 무슨 .. ㅎㅎ 왜 문제가 생기는지 생각해보기로 했다.

생각의 시작

메모리 누수 no, 메모리 낭비 yes

첫 번째는 Memory Leak이다. 저 정도의 메모리 사용량이면 200% 메모리 누수에서 문제가 시작되고 있다고 생각했다.
(누구나 그렇게 생각할거다 )

그럼 과연 어디서 메모리 누수가 발생하고 있는지가 핵심이다.
이 순간부터는 정말 막막하다.

회사에서 운영하는 서비스보다는 앱 사이즈가 작기에 괜찮아보이지만 그래도 막막하다.
모든 파일과 화면을 다 살펴봐야 하니까..

여기서부터 시작하자. 어차피 돌아갈 곳은 없다.

접근 1) Instruments 사용

Xcode에서는 좋은 툴인 Instruments를 제공한다. 100퍼센트 원하는 결과만을 제공하지는 않지만, 메모리 누수를 간편하게 확인해볼 수 있는 도구이므로 여기서부터 접근을 시작한다. (사용법은 다른 블로그를 참고하세요..!)

사실 나는 큰 기대를 안고 Instruments 켰다. 여기서 모든 누수를 잡아내기를..

오, 처음부터 메모리 누수 경고가 나오고 있었다. Log를 살펴보니까 저 부분은 Firebase SDK를 사용하면서 그 내부의 문제였다.

 

FirebaseSDK 릴리즈 노트에 가보면 Memory Leak을 수정했다고 되어있다. SDK 버전을 올리면 되는 것이었다.

저것이 근본적인 문제가 아니었다.

실제로 Instruments를 켜고 계속해서 디버깅을 진행하고 확인을 하면 더 이상 경고 표시는 확인할 수 없었는데 여전히 메모리 사용량이 너무 높았다. 이전이랑 차이가 없었다. 그래서 처음부터 다시 시작하기로 했다.

접근 2) Memory Object Graph와 deinitializer 확인

그렇다. 이게 어찌보면 정석과도 같다.

처음부터 시뮬레이션을 해보기로 했다.

일단 첫 화면부터 시작을 했다. 기기로 테스트를 진행하면서 Main(홈 화면)에서 NewPlanPreview(코스 미리보기 화면)을 몇 번 번갈아서 왔다 갔다 해보았다. 시간이 지나도 메모리 사용량이 줄지 않고 계속해서 늘고 있는 것이었다.

처음 드는 생각은 올바르게 뷰 컨트롤러가 deinit 되는지 먼저 살펴봐야겠다는 생각이 든다.

NewPlanPreviewViewController로 가서 deinit 메서드에 로그를 찍어보았는데 Main 화면으로 돌아올 때 네비게이션 스택에서 pop은 되지만 deinit 메서드는 호출되지 않고 있었다.

 

실제로 더 확실한 방법으로 메모리 그래프를 확인해보면 스택에 VC가 불필요하게 7개나 쌓여있는 것을 확인할 수 있었다.
A ↔ B를 왔다갔다 하는 것을 7번 정도 하니까 7개 쌓여있는 것을 확인할 수 있다.

 

왜 deinit이 되지 않을까?

원인 가정 1)

처음 생각했던 지점은 A(MainVC) 과 B(NewPlanPreviewVC)가 서로 강하게 참조하고 있어서가 아닐까? 라는 부분이었다.
그러나 서로 참조하고 있는 형태나 코드는 없었기에 이 부분은 원인이 아니었다.

원인 가정 2)

B(NewPlanPreviewVC)가 메모리에 계속 살아있기에, 1번의 원인이 아니라면 내부에서 순환 참조가 발생할 가능성이 클 것이라는 합리적인 의심을 해볼 수 있었다. 코드를 천천히 살펴보았다.

final class NewPlanPreviewVC: UIViewController {

...

@IBOutlet var topNavibar: NewPlanPreviewNaviBar!

...

topNavibar.backButton.press {
  self.postObserverAction(.navigationPop)
}

...

}

 

코드를 엄청 간소화했다. 상황을 간단하게 요약하면 중간에 버튼(backButton)이 액션 핸들러 클로저 부분에서 self를 강하게 참조하고 있다. 이렇게 뷰 컨트롤러와 버튼이 서로 강하게 참조하고 있기 때문에, 뷰 컨트롤러가 메모리에서 정상적으로 해제되지 않는 문제가 생기고 있었던 것이다.

 

문제의 원인 자체는 간단해보이지만, 과정은 결코 쉽지 않았다.

코드가 약 1,000줄 가까이 되기 때문에 하나하나 문제를 찾아가는 것은 머리 아픈 일이다.

여기서 ViewController의 코드를 좀 분리시키고 싶다는 생각이 강하게 들었다..ㅎ

1+1 덤으로 문제 발견

또 어디 누수난 곳은 없나하고 메모리 그래프를 쭉 훑어보던 중에 이상한 부분을 발견했다. 프로젝트 내에는 인스턴스 생성을 담당하는 객체인 ModuleFactory가 있다. 이 객체는 여러 개의 인스턴스를 생성할 필요가 없는 객체이다. 그렇기에 싱글톤(- 적절한 선택이 아닐 수도 있으나 -)으로 만들거나 하는 것이 맞다. 프로젝트 기존에 코드가 짜여있던 것도 그러한 형태로 쓰여왔었다. 나도 그동안 싱글톤인줄 알았는데 그게 아니었다. 객체가 여러 개 생기고 있었다.

// before
static func resolve() -> ModuleFactory {
  ModuleFactory()
}

 

기존에는 resolve메서드를 호출해서 ModuleFactory인스턴스를 생성하고 이 인스턴스가 가지고 있는 인스턴스 생성 메서드를 이용해서 뷰 컨트롤러를 만들고 있었다.

그러나 생각해보면 ModuleFactory인스턴스 1개만 있어도 된다. 인스턴스를 계속해서 생성하는 것은 불필요하다.
뷰 컨트롤러마다 해당 인스턴스를 넘겨주고 있는 형태도 아니고, ModuleFactory는 특정 공간 한 곳에서만 사용되고 있기도 했다.

// after
static let shared = ModuleFactory()

 

그렇기에 타입 저장 프로퍼티로 인스턴스를 만들어서 싱글톤 형태로 하나의 객체만 사용할 수 있도록 변경해주었다.

 

이렇게 전체 파일 곳곳에 강한 참조로 엮어있는 부분을 약한 참조로 수정해주었더니 문제가 해결된 듯 하였으나… 메모리 사용량이 여전히 많았다. (얼추 줄기는 했지만 …)

대체 무엇이 문제일까.. 무엇이 나를 이토록 힘들게 하는가..

생각을 해보자..

비마이플랜이라는 서비스는 이미지가 정말 많이 쓰이는 서비스이다.

곰곰히 생각을 해보았다. 캐싱이 문제일까..?

이미지 캐싱을 위해서 이미 서비스 내에서는 Kingfisher라는 라이브러리를 쓰고 있다.
근데 고민해보면, 캐싱은 결국에 높은 코스트의 이미지 요청을 줄이기 위해 하고 있는 것이고
근본적으로는 이미지 사이즈(용량)을 줄이는 것이 크게 중요하다는 생각이 들었다.

기존에 사용하고 있는 이미지의 사이즈를 찍어보면
1920 * 1080 이정도 사이즈의 고화질의 이미지를 사용하고 있었다.

생각보다 이미지가 잡아먹는 메모리가 크다는 것을 알고 있는가?

약, 이미지 해상도 * 4byte라고 보면 된다.
예를 들면, 1920 * 1080 * 4 = 8,294,400 = 약 8mb

이미지도 데이터다.

이미지도 특정 포맷으로 인코딩된 데이터의 일종인데, 이를 휴대폰에서 보여주기 위해서는 디코딩이라는 과정을 거치게되고 디코딩 후에는 이미지 버퍼라는 특정 메모리에 이미지 데이터가 저장되게 된다. 이것이 렌더링되어서 화면에 보여지게 된다.

이미지 사이즈가 크면 결국에 포함되는 데이터 정보도 많아지게 되는 것이고 차지하는 메모리의 크기도 증가하게 될 것이다.

화면에 보여질 수 있는 공간은 한정적인데 굳이 고화질 사진을 해상도 그대로 가지고 있을 필요가 없었다.
사이즈 자체를 줄여줘서 메모리에 로드되는 크기를 줄이는 것이 중요해보였다.

리사이징 / 다운샘플링 하는 코드는 많이 나와있기 때문에 참고해서 구현을 했다.

결론..

후 힘들다.. 글이 생각보다 길어졌다.

문제를 해결 전에는

문제 있는 녀석 x 문제 있는 녀석의 콜라보로 무지막지한 메모리 사용량을 보이다가 앱이 종료되는 문제가 발생했는데

이렇게 위의 과정을 거쳐서 메모리 누수를 잡고, 이미지 리사이징까지 해주니까 메모리 사용량을 현저히 줄일 수 있었다.
앱 사용 시 평균 100 - 200 mb 메모리 사용량이 유지되는 것 같다.

끝까지와서 생각해보면 엄청 큰 원인/문제는 아니었지만, 사소하게 놓칠 수 있는 부분들이 큰 이슈를 만들 수 있다는 것에 다시 한 번 꼼꼼히 코드를 짜야겠다라는 생각이 들었다.

마지막, 스크린 샷

메모리도 줄줄 새고, 내 눈물도 줄줄 새는 상황 + 이미지도 엄청 큰 거 쓰는 상황;;

그냥 다 틀어막아버린 경우 -> 용감했다.

 

결론: 기존 대비 메모리 사용량 최대 91% 감소 🎉

 

여기까지 읽어주셔서 감사합니다 :)

레이아웃을 다듬고 싶지만,, 힘에 부쳐서 정돈된 글을 읽고 싶으시다면 아래 링크를 참고해주세요 ㅎㅎ

그리고 잘못된 내용이나 피드백 있으면 언제든지 환영입니다.

 

https://github.com/Taehyeon-Kim/Today-I-Learned/issues/104

[Memory] 반나절동안 메모리 사용량 91% 감소시키기 · Issue #104 · Taehyeon-Kim/Today-I-Learned