메모리 최적화는 Android에서 안정적인 고성능 게임 환경을 제공하는 데 매우 중요합니다. 이 가이드에서는 메모리 효율성이 중요한 이유, Android 운영체제에서 프로세스 메모리 한도를 관리하고 적용하는 방법, 게임의 기술적 품질을 모니터링하고 개선하는 데 도움이 되도록 Google Play Console에 노출되는 새로운 기준을 간략하게 설명합니다.
메모리 최적화의 중요성
게임의 메모리를 최적화하는 것은 플레이어 유지율을 유지하고, 기기 호환성을 확대하고, 플랫폼 품질 기준을 준수하는 데 필수적입니다.
- 콜드 스타트 방지 (사용자 환경 및 유지율): 플레이어가 일시적으로 게임에서 전환하는 경우 (예: 알림에 답변하거나 메시지를 확인하기 위해) 운영체제는 게임 프로세스를 백그라운드에 배치합니다. 게임의 백그라운드 메모리 사용 공간이 너무 높으면 시스템의 로우 메모리 킬러 (LMK)는 포그라운드 작업에 RAM을 확보하기 위해 게임 프로세스 종료를 우선시합니다. 다음에 사용자가 재개할 때 게임은 원활하고 즉각적인 웜 재개 대신 스토리지에서 대용량 그래픽 애셋, 오디오, 게임 엔진 바이너리를 완전히 다시 로드하는 긴 콜드 스타트를 거쳐야 합니다. 백그라운드 메모리 사용량을 낮게 유지하면 이러한 자동 백그라운드 종료를 방지하여 사용자 상태를 보존하고 플레이어가 세션을 즉시 재개할 수 있도록 합니다. 시스템 LMK 동작에 관한 자세한 내용은 Android Vitals - 로우 메모리 킬러 가이드를 참고하세요.
- 생태계 및 기기 안정성: 비효율적인 메모리 사용과 메모리 누수로 인해 전반적인 시스템 상태가 저하됩니다. 시스템 메모리가 부족하면 시스템에 심각한 압력이 가해져 프레임 속도 저하, UI 끊김, 오디오 결함이 발생합니다. 메모리 압력이 너무 심하면 시스템의 로우 메모리 킬러 (LMK)는 백그라운드 프로세스를 적극적으로 종료하여 플레이어가 작업 간에 전환할 때 다른 애플리케이션에서 느린 콜드 스타트와 사용자 상태 손실이 발생하도록 합니다.
- 플랫폼 수준 종료: Android 17 (API 수준 37)부터 시스템은 메모리를 너무 많이 사용하는 프로세스를 종료하는 데 더 적극적입니다. 게임의 사용 공간이 너무 높으면 OS는 표준 스택 트레이스를 생성하지 않고 프로세스를 갑자기 종료할 수 있습니다.
- 기기 호환성: 플래그십 기기는 12GB~16GB의 RAM을 제공하지만 전 세계 게임 사용자의 상당 부분이 4GB 또는 6GB의 RAM을 사용하는 기기를 사용합니다. 적절한 메모리 관리를 통해 복잡하고 별도의 애셋 패키지 없이 모든 하드웨어 등급에서 게임에 계속 액세스하고 게임이 계속 응답하도록 할 수 있습니다.
Android의 메모리 이해
효과적인 메모리 예산 책정 전략을 설계하려면 개발자는 Android 플랫폼에서 실제 메모리를 관리하는 방법과 게임의 활성 사용 공간을 측정하는 방법을 이해해야 합니다.
핵심 Android 메모리 개념
플랫폼 수준 메모리 관리에 관한 기본 개념은 공식 메모리 관리 개요 문서를 참고하세요. 이 리소스는 다음 네 가지 아키텍처 영역을 다룹니다.
- 메모리 개요: Android는 페이징과 메모리 매핑 (mmap)을 사용하여 RAM을 관리합니다. 디스크의 기존 스왑 파일을 지원하지 않습니다. 대신 페이지 압축 (zRAM 사용)과 페이지 회수를 사용하여 실제 메모리를 확보합니다.
- 프로세스 간 메모리 할당: Android는 전체 시스템에서 RAM을 공유합니다. Dalvik 또는 ART 가상 머신 실행을 위한 특정 힙을 할당하는 동시에 네이티브 개발 환경 (예: C++ 게임 엔진)에서 네이티브 시스템 힙의 메모리를 요청할 수 있도록 합니다.
- 앱 메모리 관리: 다중 프로세스 모델에서 작동하는 Android는 애플리케이션이 수명 주기 상태를 동적으로 모니터링하고 시스템 상태를 지원하기 위해 캐시되지 않은 그래픽 및 비트맵과 같은 불필요한 리소스를 자발적으로 해제할 것으로 예상합니다.
- 프로세스 및 스레드 개요: 시스템은 현재 사용자가 인식하는 가시성과 중요도를 기준으로 프로세스를 계층 구조로 분류하여 메모리가 부족한 상황에서 어떤 프로세스를 계속 실행하고 어떤 프로세스를 먼저 종료할지 결정합니다.
총 메모리 사용 공간 측정항목
플랫폼 수준 Android 17 메모리 제한기는 총 상주 크기 (RSS) 또는 가상 메모리 크기 대신 총 메모리 사용 공간을 사용하여 프로세스 사용량을 평가합니다.
총 메모리 사용 공간 = 익명 RSS (RssAnon) + 압축되지 않은 스왑 (VmSwap)
게임이 플랫폼에서 적용하는 한도를 초과하지 않도록 하려면 개발자는 시스템 수준에서 이러한 측정항목이 나타내는 내용을 정확히 이해해야 합니다. 이러한 측정항목, 실제 RAM 할당, 파일 지원 페이지가 처리되는 방식에 관한 자세한 내용은 RSS 및 스왑 측정항목 이해를 메모리 사용량 모니터링 가이드에서 참고하세요.
메모리 제약 조건
시스템 안정성을 유지하고 애플리케이션이 과도한 리소스를 사용하지 않도록 하기 위해 Android 플랫폼은 실행 중인 프로세스에 메모리 한도를 적용합니다.
Android 17 이상의 메모리 제한기
Android 17 이상은 Linux cgroup v2를 사용하여 엄격한 앱별 메모리 한도를 적용하여 개별 앱이 시스템 전체의 불안정성을 유발하지 않도록 합니다. 기술 구현에 관한 자세한 내용은 AOSP 메모리 제한기 가이드 및 메모리 효율성 우선순위 지정: Android 17 블로그의 필수 단계를 참고하세요.
- 메커니즘: 메모리 제한기는 모든 애플리케이션 프로세스를 모니터링하고
프로세스의 수명 주기 상태에 따라 한도를 동적으로 할당합니다.
- 표시되는 프로세스 (포그라운드): 현재 UI를 표시하는 앱 프로세스는 더 큰 리소스 작업 세트를 실행할 것으로 예상되며 더 관대한 한도가 제공됩니다.
- 표시되지 않는 프로세스 (백그라운드 또는 서비스): UI를 표시하지 않고 활발하게 작업하는 앱 프로세스는 더 엄격하고 제한적인 예산으로 제한됩니다.
- 커널 속성: 서비스는 다음 두 가지 주요 속성에 의존합니다:
memory.high: 유연한 한도입니다. 초과되면 커널은 프로세스를 제한하고 메모리를 적극적으로 회수하려고 시도합니다. 이 회수로 인해 게임 성능이 저하될 수 있습니다.memory.swap.max: 프로세스에서 사용할 수 있는 스왑 또는 zRAM 공간에 하드 캡을 적용합니다.
- 종료 동작: 프로세스가 익명
메모리를
memory.high초과하여 계속 할당하고 스왑 용량을 소진하면 할당이 실패하고 OS는 자동으로 프로세스를 종료합니다. 이 종료는ApplicationExitInfo를 사용하여 메모리 제한기 종료 이유 (Android 17, 26Q4부터 사용 가능) 아래에 로깅됩니다.
메모리 사용량 모니터링
게임의 메모리를 효과적으로 최적화하려면 먼저 Android 플랫폼에서 사용 공간을 측정하는 방법을 이해해야 합니다. Android 17은 파일 지원 또는 GPU 전용 메모리를 제외하고 익명 RSS (RssAnon)와 압축되지 않은 스왑 (VmSwap)의 합계를 추적하도록 메모리 적용 측정항목을 업데이트합니다. 이 가이드에서는 Perfetto 및 meminfo와 같은 시스템 수준 도구를 활용하고, ProfilingManager 및 onTrimMemory와 같은 진단 API를 구현하고, Unity 및 Unreal Engine 내에서 정확한 메모리 할당을 추출하는 방법을 자세히 설명합니다. 게임의 프로필을 정확하게 작성하고 기존 런타임 메모리 폴링과 관련된 성능 끊김을 방지하는 방법을 알아보세요.
자세한 내용은 메모리 사용량 모니터링을 참고하세요.
메모리 사용 감소 전략
게임 엔진은 크로스 플랫폼 개발을 간소화하지만 기본 메모리 처리로 인해 OS 수준 메모리 한도가 트리거될 수 있습니다. 이 페이지에서는 Unity 및 Unreal Engine에 맞게 특별히 조정된 실용적인 최적화 단계를 자세히 설명합니다. Java 기반 onTrimMemory에 의존하면 Unity에서 교착 상태가 발생하는 이유와 대신 네이티브 수명 주기 콜백을 사용하는 방법을 알아보세요. 또한 ASTC 8x8 텍스처 압축 사용 및 애셋 언로드 구성과 같은 주요 애셋 수준 최적화를 통해 모든 하드웨어 등급에서 게임을 원활하게 실행할 수 있습니다.