메모리 사용량 (익명 RSS + 스왑)

메모리 사용량 (익명 RSS + 스왑)은 앱의 메모리 사용량을 반영하는 측정항목입니다.

익명 메모리는 힙 할당 및 mmap 할당 메모리와 같이 저장소의 파일로 지원되지 않는 메모리입니다. 여기에는 Java 또는 Kotlin 힙, 관리되지 않는 네이티브 힙 할당 (Android 8.0 (API 수준 26) 이상에서 비트맵 픽셀 데이터가 있는 곳), 스레드 실행 스택 등 앱의 동적 메모리 할당이 포함됩니다. OS는 압력 하에서 파일 지원 메모리를 삭제할 수 있지만 익명 메모리는 삭제할 수 없습니다.

Resident Set Size (RSS)는 프로세스에서 사용하고 실제 RAM에 보관된 메모리 페이지 (공유 및 비공유)의 총수입니다. 페이지가 둘 이상의 프로세스 (예: 동일한 라이브러리에 액세스하는 앱)에 의해 액세스되는 경우 '공유'된 것으로 간주됩니다.

익명 메모리의 경우 메모리에 압력이 가해지면 시스템에서 스왑 공간 (또는 Android의 경우 zRAM)에 페이지를 쓸 수 있습니다. 필요한 경우 시스템은 스왑에서 이러한 페이지를 다시 읽을 수 있습니다.

전체적으로 메모리 사용량 (익명 RSS + 스왑)은 저장소의 파일로 지원되지 않는 앱의 총 메모리 페이지 수를 측정하며, 시스템에서 스왑으로 보존하는 메모리도 포함됩니다. 익명 RSS와 스왑을 추적하면 앱의 실제 제거 불가능한 메모리 사용량을 확인할 수 있습니다.

앱의 메모리 사용량이 높은 경우 이 페이지의 안내에 따라 자세히 조사하고 문제를 해결하세요.

리소스

과도한 메모리 사용량 로컬로 진단

과도한 메모리 사용의 원인을 진단하려면 개발자 설정, Android 스튜디오 또는 Perfetto에서 힙 덤프 기록을 사용하여 힙 덤프를 캡처하면 됩니다. 앱의 핵심 사용자 여정을 테스트한 후 로컬에서 힙 덤프를 캡처하는 것부터 시작하는 것이 좋습니다.

특히 다음 사용자 여정을 테스트하는 것이 좋습니다.

  • WebView 및 인앱 브라우저 세션
  • 미디어가 많은 무한 스크롤
  • 애셋 생성 및 수정 흐름

잠재적인 메모리 누수를 조사하려면 해당 사용자 여정을 로컬에서 실행하고 다양한 프로세스 상태 (표시, 포그라운드 서비스, 캐시)에서 힙 덤프를 수집하여 앱이 백그라운드로 전환된 후 메모리를 해제하는지 확인하세요. 이러한 프로세스 상태가 onTrimMemory 콜백과 어떤 관련이 있는지 알아보려면 이벤트에 응답하여 메모리 해제에 관한 안내를 참고하세요.

Android 스튜디오 프로파일러를 사용하여 메모리 문제를 디버깅하는 경우 LeakCanary 통합을 사용하여 누수 및 중복 비트맵 감지를 간소화하여 이미지 사용량을 최적화할 수도 있습니다.

힙 덤프를 수집한 후에는 Android 프로파일러 기술을 사용하여 힙 덤프를 분석하고 메모리 사용량이 많은 잠재적 소스를 파악하는 것이 좋습니다.

AI 스킬이 응답할 수 있는 내용은 다음과 같습니다.

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

힙 덤프 해석을 위한 추가 리소스

다음 리소스는 힙 덤프 해석 및 메모리 사용량 디버깅에 관한 자세한 정보를 제공합니다.

메모리 사용량 개선

다음 섹션을 참고하여 앱의 메모리 사용량을 개선하는 방법을 자세히 알아보세요.

메모리 문제 해결에 관한 자세한 안내는 앱 메모리 관리 가이드를 참고하세요.