TroubleShooting ‐ Memory Leak

문제 상황

KakaoTalk_20231207_105337219.mp4

다음과 같은 상황에서 메모리 릭이 발생했다.

1. 홈 화면에서 하단 네비게이션 바로 여러 번 화면을 이동할 경우, Java Heap과 Native Heap이 GC 콜 이후에도 크기가 줄지 않고 계속 늘어난다.
2. 로그인/회원가입 화면에서 로그인 성공 또는 실패 시 메모리 누수가 발생한다.
3. 웹뷰를 사용하는 로직에서 웹뷰가 닫힐 경우 메모리 누수가 발생한다.

해결 과정

dependencies {
  // debugImplementation because LeakCanary should only run in debug builds.
  
  debugImplementation("com.squareup.leakcanary:leakcanary-android:2.12")
}

멘토님과의 대화를 통해 LeakCanary를 통해 어디서 문제가 발생하는지 추적하는 방법을 채택했다.

LeakCanary는 안드로이드 생명주기를 알고 Activity, Fragment, View, ViewModel이 파괴됐을 때 자동으로 감지하여 ObjectWatcher로 전달하게 된다.

파괴 후 5초 이내에 GC가 되지 않으면 retained 된 것으로 판단하여 이를 Logcat에 기록한다.

retained 객체수가 임계값을 넘어가면 LeakCanary는 Java 힙 메모리 영역을 안드로이드 파일 시스템에 .hprof 파일로 덤프한다.

힙을 덤프하면 짧은 시간동안 앱이 정지되며, 이후 힙 메모리 분석을 통해 retained 객체들을 검사하고 분석하여 보여준다.

로그인/회원가입 화면

사용자가 경험하는 첫 누수 발생 화면은 로그인 및 회원가입 화면이었다.

로그인 화면과 회원가입 화면에서는 API 응답시간 동안 원형으로 돌아가는 로딩 아이콘을 사용하는데,

해당 아이콘을 그리는 부분에서 메모리 누수가 발생했다.

private lateinit var circularProgressIndicator: IndeterminateDrawable<CircularProgressIndicatorSpec>
...
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    with(binding) {
        viewModel = loginViewModel
    }
    circularProgressIndicator = getCircularProgressIndicatorDrawable(this@LoginActivity)
    initListener()
    collectEvent()
    setContentView(binding.root)
}
...
override fun onDestroy() {
    super.onDestroy()
    circularProgressIndicator.stop()
}

누수 발생 원인은 애니메이션이 종료되지 않았기 때문이다.

해당 애니메이션이 들어있는 아이콘을 만들어 사용한 후 null로 참조를 없앴지만,

실제로 애니메이션을 담은 객체는 멈추지 않고 계속 돌아가게 된다.

이 때 애니메이션이 실행되기 위해 context를 참조하는데 이 과정에서 누수가 발생한 것이었다.

circularProgressIndicator의 애니메이션을 onDestory에서 멈추는 코드를 작성하여 추가하였다.

위 코드로 변경 후 다시 테스트한 결과 더 이상 로그인 화면과 회원가입 화면에서는 메모리 누수가 발생하지 않았다.

상품 추가 도움말 화면

다음으로 발생한 메모리 누수는 상품 추가 도움말 화면이다.

해당 Fragment는 WebView를 사용하는데, 여기서 누수가 발생한 것으로 보인다.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    binding = ActivityLinkHelperWebViewBinding.inflate(layoutInflater)
    setContentView(binding.root)

    webView = WebView(this)
    webView.loadUrl("https://info-kr.priceguard.app/")
    binding.wbLinkHelper.addView(webView)
}

override fun onDestroy() {
    super.onDestroy()
    binding.wbLinkHelper.removeAllViews()
    webView.clearHistory()
    webView.clearCache(true)
    webView.loadUrl("about:blank")
    webView.pauseTimers()
    webView.destroy()
}

Activity가 제거될 때 되면 WebView는 계속해서 Activity에 대한 참조를 유지하므로 활동이 메모리에서 제거되지 않는다.

이렇게 될 경우 메모리 누수가 발생하게 된다.

이를 방지하기 위해 웹뷰를 xml에서 만들도록 하지 않고 코드에서 생성하여 이를 연결하는 방법을 택했다.

https://issuetracker.google.com/issues/273117792#comment4

실제로 누수는 어느정도 잡혔지만, 여전히 LeakCanary가 메모리 누수를 경고하고 있다.

이유를 찾는 도중 현재 삼성 기기 중 안드로이드 13버전에 OneUI 5버전에서 LeakCanary 사용 시 누수가 발생한다는 이슈를 발견하였다.

현 상황과 같은 상황이라 생각했고, 여러 번의 테스트 결과 프로파일링에서 심각한 스파이크나 점진적인 힙 영역 증가는 없었다.

따라서 팀과 의논을 통해 해당 이슈에 대한 탐색은 여기서 중단하였다.

상품 목록/인기 상품 화면

상품 목록 화면 프래그먼트에서도 누수가 발생하고 있었다.

해당 화면에서 RecyclerView를 구현하기 위해 adapter를 설정하고 있었는데,

RecyclerView 어댑터를 설정하면 양방향 통신 방법이 설정된다.

해당 연결을 정리하지 않으면 가비지 수집기가 RecyclerView를 지울 수 없으므로 메모리 누수가 발생하게 되는 것이다.

override fun onDestroyView() {
    super.onDestroyView()
    binding.rvRecommendedProduct.adapter = null
}

다음과 같이 어댑터를 모두 onDestoryView에서 null로 초기화했다.

이제 더 이상 Fragment 라이프사이클 이후 메모리에 남지 않아도 된다.

문제 해결 이후 더 이상 Fragment로 인한 누수는 없어졌다.

BottomNavigatorView에서 Navigate 콜을 반복적으로 호출하는 시나리오에서

어댑터와 리스너 초기화를 하지 않을 경우 Java Heap 63MB, Native Heap 104.6MB의 메모리가 최종적으로 할당되지만,

어댑터와 리스너 초기화를 할 경우 Java Heap은 15 ~ 25MB, Native Heap 28 ~ 33MB 사이에서 메모리가 유지된다.

++추가

Fragment에서 Adapter를 onViewCreated 할때 마다 생성하고있네요. 아까 메모리 릭은 재사용하는 형태로 adapter는 1회 만들고, 이걸 view에 적용만 했다면 메모리 문제가 조금 더 빨리 해결할 수 있지 않을까 생각드네요. Fragment view lifecycle 참고.(구글 binding을 nullable로 하는 이유와 같긴합니다.)

다음과 같은 현업자의 피드백이 있었다.

말씀하신 내용대로 adapter를 캐싱하여 실행 중 한 번만 생성하고 재사용하도록 했으면 훨씬 더 깔끔하게 메모리 관리가 되었을 것 같다.

추후 리팩토링 과정에 반영해야겠다.

참고 자료

• https://leveloper.tistory.com/197
• https://pinartechtips.com/5-most-common-android-memory-leaks/#3-recycler-view-adapter-memory-leaks
• https://stackoverflow.com/questions/3130654/memory-leak-in-webview