📱 WWDC 2024 - [Analyze heap memory] 정리 및 리뷰

- 앱의 동적 메모리인 힙 메모리에 대해 자세히 알아보기.
- Instruments와 Xcode를 사용하여 일반적인 힙 메모리 문제 판단, 분석, 해결 방법
- 앱에서 일시적 또는 지속적인 메모리 사용량 증가, 메모리 누수를 진단하는 기술 및 모범 사례 소개

 

✅ 전체 세션 요약

 

이 세션은 iOS/macOS 앱에서 힙 메모리의 사용량을 분석하고, 메모리 문제를 진단하며, 최적화하는 방법을 소개합니다. 주로 Xcode와 Instruments 도구를 사용해 메모리 사용량을 추적하고 문제를 해결합니다.

 

🎯 세션 핵심 주제 (5가지)

 

1. 힙 측정하기

2. 일시적 증가에 대응하기

3. 지속적 증가 추적하기

4. 메모리 누수 수정하기

5. 런타임 성능 개선하기

 

앱에서 직,간접적으로 사용되고 개발자가 제어하고 최적화 할수 있음. 앱의 참조타입 저장

📌 힙 메모리란? 

• 앱에서 수명이 긴 객체들이 저장되는 메모리 영역

• 직접적으로는 malloc, calloc, realloc 등으로 할당

• 간접적으로는 Swift/Objective-C 인스턴스를 통해 할당됨

• 운영체제의 가상 메모리 페이지 (클린, 더티, 스왑)로 구성

 

- 앱이 시작되면 자체적인 빈 가상 메모리 주소 공간을 받음

- 앱이 실행될 때 시스템은 메인 실행 파일, 연결된 라이브러리/ 프레임워크를 로드, 디스크에서 읽기 전용 리소스 영역을 매핑

- 실행 중에 앱은 각 스레드의 로컬 및 임시 변수를 위한 스택 영역을 사용

- 동적이고 수명이 긴 메모리는 힙 메모리 영역에 배치

 

- 여러 가상 메모리 영역으로 구성됨

- 각 영역은 개별 힙 할당으로 나뉨.

- 운영체제의 16kb 메모리 페이지로 구성됨.

- 상태는 클린, 더티 또는 스왑

- 더티와 스왑만 애플리케이션의 메모리 공간에 포함됨.

- 힙이 메모리 공간의 대부분을 차지 

 

클래스 이니셜라이저 -> malloc 호출

 

malloc stack logging 활성화

🛠️ 힙 메모리 측정 도구

시간경과에 따른 풋프린트를 보여주는 xcode 메모리 보고서

 

1. Xcode 메모리 보고서

• 앱 전체 메모리 사용량 추이 확인 가능

• 갑작스러운 메모리 증가 감지에 유용

• 대규모 메모리 문제와 일부 최근 기록을 보여주지만 메모리 사용량이 증가하는 이유는 알려주지 못함.

 

 

 

모든 할당과 그 사이 참조에 대한 스냅샷인 메모리 그래프 캡쳐 가능

2. Xcode 메모리 그래프 디버거

• 현재 앱의 메모리 스냅샷을 캡처하고 객체 간 참조 확인 가능

• 누수나 순환 참조 시 시각적으로 추적 가능

• MallocStackLogging을 사용하면 각 할당의 역추적이 포함됨

• 특정 할당에 집중해야 할때 유용, xcode의 디버그 막대에서 바로 액세스 할 수 있음

 

 

3. Instruments - Allocations

• 시간 흐름에 따른 메모리 할당/해제 추적

• 콜 트리 및 생성 위치 분석 (통계와 콜 트리를 집계해 다시 코드로 추적)

• leaks 도구는 앱의 메모리를 주기적으로 스냅샷해 메모리 누수를 감지

 

4. Command-line 도구들

• leaks, heap, vmmap, malloc_history 

• macOS 및 시뮬레이터 프로세스를 직접 분석하거나 이미 캡처된 메모리 그래프로 문제를 조사할 수 있음.

 

 

 

 

📈 메모리 일시적 증가 분석

 

DestinationVideo 앱의 메모리 문제 : 비디오의 새 배경 이미지를 선택할 수 있는 기능 - 갤러리 열기에서 앱 크래쉬

 

문제:

• 갤러리 열기 → 메모리 1GB 급증 (xcode 보고서) → 앱 종료 위험

 

Allocations 도구를 활용:

• Product -> Profile 메뉴  -> 앱의 릴리즈 빌드 수행 -> 앱이 대상으로 선택된 상태에서 Instruments가 열림 -> 프로파일링할 템플릿을 선택하라는 메시지 표시 -> allocations 선택 ->  allocations(힙과 VM 이벤트를 실시간으로 기록하여 활동을 실시간으로 확인 가능), VM Tracker(주기적으로 스냅샷을 생성해 모든 가상 메모리 측정 가능)에서 allocations 선택 -> 왼쪽 상단의 Record 버튼으로 추적 

 

앱의 메모리 급증이 안좋은 이유:

• 메모리 압박 유발

• 더티 메모리 교체 및 압축, 읽기전용 메모리 폐기, 백그라운드 작업 종료

• 최악의 경우 앱 종료

 

메모리 급증 추적 :

1. 특정 스파이크에서 최저점에서 최고점에 있는 Created & Still Living 할당 찾기 

2. 전체적으로 큰 범위를 선택해 해당 범위에서 Created & Destroyed 된 모든 할당 찾기

 

타임라인의 스파이크 구간 중 하나 선택 -> 트랙 뷰에서 스파이크의 최저점에서 최상단까지 클릭 + 드래그 -> 정보 표시됨

lifespan 필터 destroyed 변경, 스파이크 3개 전체 선택 - 콜트리로 전환 - 할당을 역추적으로 분석해 가장 많은 메모리할당하는 코드 볼 수 있음

한 줄에서 GB 단위의 메모리가 생성 & 파괴

func makeThumbnail(from photoURL: URL) -> PhotoThumbnail {
  validate(url: photoURL)
  var coreImage = CIImage(contentsOf: photoURL)!

  let sepiaTone = CIFilter.sepiaTone()
  sepiaTone.inputImage = coreImage
  sepiaTone.intensity = 0.4
  coreImage = sepiaTone.outputImage!

  let squareSize = min(coreImage.extent.width, coreImage.extent.height)
  coreImage = coreImage.cropped(to: CGRect(x: 0, y: 0, width: squareSize, height: squareSize))

  let targetSize = CGSize(width:64, height:64)
  let scalingFilter = CIFilter.lanczosScaleTransform()

  scalingFilter.inputImage = coreImage
  scalingFilter.scale = Float(targetSize.height / coreImage.extent.height)
  scalingFilter.aspectRatio = Float(Double(coreImage.extent.width) / Double(coreImage.extent.height))
  coreImage = scalingFilter.outputImage!

  let imageData = context.generateImageData(of: coreImage)

  return PhotoThumbnail(size: targetSize, data: imageData, url: photoURL)
}

루프에서 썸네일을 폴트하고 있고 루프가 실행되는 동안 메모리가 증가하다 끝에서 떨어짐

func loadThumbnails(with renderer: ThumbnailRenderer) {
  for photoURL in urls {
    renderer.faultThumbnail(from: photoURL)
  }
}

Swift에는 자동 참조 카운팅이 있지만 autoreleasepool은 임시 메모리 증가의 흔한 원인. 옵젝씨는 이 풀을 사용해 함수 반환값의 객체 수명을 연장, autoreleasepool은 해제를 지연시켜 이 반환값들을 유지함. swift 가 옵젝씨 api를 사용하는 프레임워크를 호출할 때 자동 릴리즈된 객체를 생성할 수 있다는 의미

 

 

예시 : 현재 날짜 출력 - 자동릴리즈된 문자열도 생성, 현재 자동 릴리즈 범위가 끝날 때 까지 힙에 남아있게 됨

print("Now is \(Date.now)") // Produces autoreleased .description String

스레드에는 일반적으로 최상위 수준 자동 릴리즈 풀이 있지만 자주 정리되지는 않음. 모든 반복 객체는 같은 풀에 자동 릴리즈되며 필요 이상으로 오래 존재할 수 있다. 이 경우 루프가 모두 완료될 때까지 기다림. 자동릴리즈 풀은 객체 참조를 위해 내부적으로 콘텐츠 페이지 할당 - allocations 도구로 확인 가능.

 

풀에서 지연된 릴리즈를 보내고 많은 객체가 한꺼번에 풀려날 수 있다.

 

원인 분석:

• @autoreleasepool 미사용으로 루프 내 임시 객체가 반복 누적

• makeThumbnail() 내 반복 이미지 처리 시 객체 해제가 지연됨

 

로컬 자동 릴리즈 풀 범위를 정의해 수명 좁히기 - 자동 릴리즈된 객체가 내부 루프별 풀에 보관됨. 각 반복마다 릴리즈 됨. 누적되는 객체수가 줄어들고 참조를 추적하는데 필요한 콘텐츠 페이지가 줄어듬

 

 

해결:

• 루프 내부에 autoreleasepool {} 추가

• 반복마다 메모리 해제를 유도

 

 

func loadThumbnails(with renderer: ThumbnailRenderer) {
    for photoURL in urls {
        autoreleasepool {
            renderer.faultThumbnail(from: photoURL)
        }
    }
}

- 루프 본문에 자동 릴리즈 풀 범위를 추가해 각 반복 후에 객체를 비우도록 !

- 대부분의 프로파일링에서는 정확한 타이밍을 위해 릴리즈 빌드를 실제 기기에서 실행하는 것이 중요.

- 하지만 힙 분석의 경우 시뮬레이터 환경이 동작에 더 가까워서 메모리 프로파일링에 사용해도 괜찮음.

 

기가바이트 단위까지 올라가는 메모리 스파이크는 사라졌지만 매번 메모리가 계단식 패턴으로 올라감. 갤러리를 처음 열었을 때만 증가해야되는데.. 열고 닫고 할 때마다 계단식으로 ??

 

 

 

🔄 지속적 메모리 증가 (Memory Leak 아님)

 

문제:

• 갤러리를 열 때마다 점진적 메모리 사용 증가 (계단 형태)

 

메모리 그래프 디버거를 xcode의 디버그 바에서 일시중지 > 힙의 모든 할당이 캡처됨 > 증가의 원인이 된 유형을 이미 알고 있다면 검색할 수 있다.

 

시간이 지남에 따라 메모리가 증가 > 여러번의 할당

 

 

분석 방법:

• Instruments - Allocations의 Mark Generation 기능으로 시간대별 힙 상태 구분

• 증가 구간 별 객체 유형 확인

 

mark generation 버튼 클릭 > 할당을 위한 새 그룹을 만듬 > 이 시점 이전에 생긴 모든 할당을 수집

 

 

3개의 세대 중 하나를 확장해서 할당량 확인 > 데이터용 스토리지에서 > 개별 할당량과 주소 확인 > 모든 데이터 스토리지 할당 생성 확인

 

이 주소 중 하나를 메모리 그래프 디버거에 넣어 참조하는 항목 확인 > 데이터가 잔존하는 이유를 알수 있다.

 

메모리 그래프 디버거가 이 질문에 대한 답을 줄 수 있다.

 

타입 정보와 참조 스캔에 대한 이해 : 

참조의 4가지 타입

 

힙 할당에 대한 포인터 > 코코넛 객체에 대한 강 한 참조

 

c와 c++에는 참조 소유권 정보가 없어 보수적 참조만 볼 수 있다.

 

선택된 할당을 _DataStorage 객체가 보유하고 있음.

 

끝까지 거슬러 올라가면 thumbnailLoader.globalImageCache 가 보유

 

 

func faultThumbnail(from photoURL: URL) {
  // Cache the thumbnail based on url + creationDate
  let timestamp = UInt64(Date.now.timeIntervalSince1970) // Bad - caching with wrong timestamp
  let cacheKey = CacheKey(url: photoURL, timestamp: timestamp)

  let thumbnail = cacheProvider.thumbnail(for: cacheKey) {
    return makeThumbnail(from: photoURL)
  }
  images.append(thumbnail.image)
}

-> faultThumbnail 메서드가 썸네일을 캐싱하고 캐시 미스 시 새 썸네일 생성

-> URL과 creationDate를 기반으로 캐싱하고 있다고 주석에 되어있지만, 코드를 보니 현재 시간으로 되어있다. 

-> 이 메서드가 호출 될 때마다 항상 새로운 photoThumbnail을 캐시

 

 

원인:

• 썸네일 캐싱 시 creationDate가 아닌 현재 시간을 키로 사용   

• 캐시 미스가 반복되며 메모리 누적

 

func faultThumbnail(from photoURL: URL) {
  // Cache the thumbnail based on url + creationDate
  let timestamp = cacheKeyTimestamp(for: photoURL) // Fixed - caching with correct timestamp
  let cacheKey = CacheKey(url: photoURL, timestamp: timestamp)

  let thumbnail = cacheProvider.thumbnail(for: cacheKey) {
    return makeThumbnail(from: photoURL)
  }
  images.append(thumbnail.image)
}

 

해결:

• 정확한 파일 생성 시간으로 캐싱 키 설정 ( 실제 파일 생성 날짜를 기준으로 캐싱 )

 

 

메모리 누수 발견

 

🚨 메모리 누수 분석 및 수정

 

* reachability 도달 가능성 ? 

 

힙의 3가지 종류의 메모리:

1. useful 유용한 메모리: 실제로 사용 중 , 도달 가능 나중에 다시 사용할 메모리 

2. abandoned 버려진 메모리: 도달 가능하지만 불필요하게 유지 ( 실제로는 다시 사용하지 않음 ), 메모리 사용량에 포함, 낭비 

- 캐시에 데이터 너무 많이 저장, 싱글톤에 큰 용량의 데이터 유지

3. Leaked 도달 불가능한 메모리: 참조 사라짐 → 누수 , 재사용 절대 불가능

 

대부분의 누수의 경우 한 순환에서 하나의 참조를 찾아 수정하는 것이 목표

 

프로젝트에서 발생하는 것만 보기

 

스위프트 클로저가 값을 캡처해야할 때 힙에 메모를 할당해 저장. 메모리 그래프 디버거는 이러한 할당을 클로저 컨텍스트로 표시. 앱 힙의 각 클로저 컨텍스트는 라이브 클로저와 1대1 대응. 클로저는 기본적으로 참조를 강하게 캡처, 참조순환을 만듬.

 

원인:

• 클로저 내 self를 강하게 캡처 → 순환 참조 발생

 

강한 참조를 찾음 > 클로저 코드 찾기

 

thumbnailloader 객체를 생성 > 완료 핸들러에 할당 > 로딩 시작 지시, 클로저가 thumbnailRenderer를 강하게 캡처 > 참조순환

 

// ...
let renderer = ThumbnailRenderer(style: .vibrant)
let loader = ThumbnailLoader(bundle: .main, completionQueue: .main)
loader.completionHandler = {
  self.thumbnails = renderer.images // implicit strong capture of renderer causes strong reference cycle
}
loader.beginLoading(with: renderer)
// ...

 

// ...
let renderer = ThumbnailRenderer(style: .vibrant)
let loader = ThumbnailLoader(bundle: .main, completionQueue: .main)
loader.completionHandler = { [weak renderer] in
	guard let renderer else { return }

  self.thumbnails = renderer.images
}
loader.beginLoading(with: renderer)
// ...

 

해결:

• 클로저에 [weak self] 또는 [unowned self] 사용

• 옵셔널 처리를 통해 안전하게 사용

 

누출 보고 > 명시적으로 전역에 저장 > 객체를 로컬 함수 범위 바깥에 저장.

 

🚀 런타임 성능 개선

 

weak vs unowned 차이

항상 옵셔널 타입, 수명과 관계없이 사용. 코코넛이 제비 참조. 대상 객체에 대한 weak 참조 저장소 할당,

 

 

대상을 직접 보유, 추가메모리 사용하지 않고, weak 참조보다 접근시간이 짧음.옵셔널이 아닐수도 있고 상수일 수도. 항상 유효한건 아님. swallow가 참조보다 먼저 사라지면 swallow는 제거되지만 할당이 해제되지는 않음.

 

- unowend 참조는 반드시 무언가를 가리켜야 하므로  런타임은 swallow를 유지

- weak 참조를 강제로 언래핑하는 것과 비슷

- 참조 대상은 할당 해제될 수 없고, 메모리 낭비

 

 

메모리 그래프에 weak참조 또는 unowned 참조가 보이지 않으면 xcode에서 프로젝트의 reflection metadata level 빌드 설정 확인해야 할수 있음. 되도록 기본값인 all level 사용하는 것이 좋음.

 

class ByteProducer {
  let data: Data
  private var generator: ((Data) -> UInt8)? = nil

  init(data: Data) {
    self.data = data
    generator = defaultAction // Implicitly uses `self`
  }

  func defaultAction(_ data: Data) -> UInt8 {
    // ...
  }
}

- defaultAction 메서드에 할당된 클로저라는 생성기 속성이 있음. 암묵적으로 self 사용. 

메서드를 클로저로 사용할 때는 매우 조심

 

defaultAction을 호출하는 클로저 정의. > self 캡처가 명시적. weak. unowned 가능 : 생성기 클로저는 대상인 byteProducer 인스턴스와 수명 동일.클로저는 다른 코드로 할당되거나 비동기적으로 디스패치 되지 않으므로 캡처된 자신보다 오래 지속될 수 없음

 

unowned는 메모리 필요없음. 기본값은 weak. unowned은 참조가 대상보다 오래 지속되지 않음을 보장할 수 있을때 메모리랑 시간 절약. cpu 오버헤드를 유발하는 영역을 찾으려면 프로파일링 > swift_weakLoadStrong()과 같은 런타임 함수에 대한 호출 찾기.

 

 

 

성능 최적화 팁

• -whole-module-optimization 활성화

• 구조체는 단순화하여 복사 비용 줄이기

• ARC를 우회하지 말 것

• Objective-C는 objc_direct, objc_externally_retained 등을 활용

 

 

🎯 핵심 메시지 요약

• 힙 메모리 최적화는 앱 안정성과 성능 향상에 필수

• 메모리 문제는 도구를 사용해 반복 측정 및 추적으로 해결 가능

• 자동 릴리즈 풀, 클로저의 캡처 방식에 주의해야 메모리 누수 방지

• weak/unowned 선택은 수명에 따라 결정

• 프로파일링과 도구 활용 능력이 개발자 숙련도를 좌우