Quick Reference
Memory 모듈은 시간 추세, Memory Profiler snapshot은 시점별 소유·참조를 보며, Reserved 잔여만으로 누수라 판단하지 않습니다.
- 기준 버전은 Unity 6.5 (6000.5)이며, 상세 snapshot은 Memory Profiler 패키지를 사용합니다. Profiler의 Memory 모듈은 시간에 따른 추세, Memory Profiler의 snapshot은 특정 시점의 소유·참조 구조를 보는 도구입니다.
- 누수 여부는 메뉴 A와 전투 B처럼 서로 다른 장면을 비교하지 않습니다. 같은 시작 상태에서 같은 로드/해제 흐름을 반복한 뒤 같은 상태로 돌아와 A/B를 찍습니다.
Used,Reserved,Committed,Untracked는 같은 값이 아닙니다. reserved가 남았다고 곧바로 누수라고 결론 내리지 말고, 어떤 object와 native allocation이 참조를 유지하는지 추적합니다.
Memory 수치 읽기
- Used/In use는 Unity가 실제로 사용 중이라고 추적하는 메모리입니다. Reserved는 반복적인 OS allocation을 피하려고 Unity가 풀로 확보해 둔 양일 수 있습니다. 씬을 나간 뒤 reserved가 바로 줄지 않는 것만으로 leak이라고 볼 수 없습니다.
- Managed Heap / GC Used Memory는 C# 객체와 garbage collector가 관리하는 영역입니다.
GC Allocated In Frame은 한 프레임의 관리 힙 할당량이며, 장기 snapshot의 총 메모리와 다른 질문에 답합니다. - Graphics & Graphics Driver에는 texture, render target, shader, mesh와 드라이버가 쓰는 추정 메모리가 포함됩니다. GPU memory가 OS/driver에 의해 보고되는 방식은 platform마다 다를 수 있으므로, editor 값만 target device budget으로 사용하지 않습니다.
- Untracked Memory에는 native plugin, driver, 실행 코드, IL2CPP/Mono metadata처럼 Unity가 세부 소유를 완전히 추적하지 못하는 영역이 포함될 수 있습니다. 총 process memory와 snapshot 합계가 정확히 일치하지 않을 수 있습니다.
Snapshot 비교
text
1. 메뉴에 진입해 warm-up을 끝낸 뒤 Snapshot A
2. 같은 전투 진입/종료 또는 scene load/unload를 N회 반복
3. 다시 같은 메뉴 상태가 된 뒤 Snapshot B
4. B - A에서 증가한 object, native memory, reference chain을 조사- Memory Profiler의 snapshot capture는 데이터 수집과 editor memory를 사용하며 runtime을 멈추거나 크게 흔들 수 있습니다. frame-time benchmark 중에 snapshot capture frame을 섞지 않습니다.
- 증가한 Texture, Mesh, AudioClip, Managed Object를 찾은 뒤에는 “크다”에서 멈추지 말고 reference chain을 따라 소유자를 찾습니다. Addressables handle, static event, DontDestroyOnLoad singleton, pool, scene reference가 해제를 막는 대표 경계입니다.
- snapshot 한 장은 규모를 보여 주고, 비교는 변화량을 보여 줍니다. 같은 에셋이 캐시되어 남는 설계인지, 더 이상 도달할 수 없는 object가 계속 남는 누수인지는 제품의 load/cache 정책과 함께 판정합니다.
Profiler와 스크립트 연결
- CPU Usage의
GC.Alloccolumn은 어느 프레임에서 관리 힙 allocation이 발생했는가를 찾는 데 적합합니다. Call Stacks로 호출 위치를 찾고, Memory Profiler snapshot으로 그 object가 왜 장기적으로 남는가를 확인합니다. - 런타임 코드에서
Resources.UnloadUnusedAssets()를 leak 치료처럼 호출하지 않습니다. 비동기 unload와 loading hitch를 유발할 수 있으며, 참조가 남아 있다면 해제하지 못합니다. 먼저 소유권과 release 경로를 고칩니다. GC.Collect()도 snapshot 숫자를 예쁘게 만드는 일반 해법이 아닙니다. 강제 GC는 frame hitch를 만들 수 있으므로 플랫폼 정책과 재현 가능한 loading boundary가 있는 경우에만 검토합니다.
자주 틀리는 부분
Memory Profiler 패키지와 Profiler의 Memory 모듈을 같은 도구로 취급하지 마세요. 전자는 상세 snapshot과 reference 분석, 후자는 frame별 고수준 trend가 강점입니다. 둘을 같이 써야 allocation spike와 장기 retained memory를 분리할 수 있습니다.
Editor snapshot으로 모바일 RAM 예산을 확정하지 마세요. Editor는 창, import asset, 읽기/쓰기 가능한 texture copy 등 별도 메모리를 사용합니다. target device build에서 플랫폼의 process memory와 crash/low-memory 신호를 함께 확인해야 합니다.
참고 링크
2 sources