[WWDC18] iOS Memory Deep Dive

iOS Memory Deep Dive - WWDC18 - Videos - Apple Developer

[WWDC18] iOS Memory Deep Dive

• Why reduce memory :: 왜 메모리를 줄여야 하는지?
• Memory footprint :: 메모리 사용량에 대한 이론적인 이야기
• Tools for profiling footprint :: 메모리 사용량을 확인할 수 있는 툴 소개
• Images :: 메모리를 많이 사용하는 이미지에 대하여
• Optimizing when in background :: 백그라운드에서의 이미지 메모리 최적
• Demo 

---

🧐 Why reduce memory

메모리를 줄이는 이유는 무엇일까?

• 유저가 더 나은 경험을 할 수 있기 때문이다! (이것이 고객 중심..?🥹)
• 앱 실행 속도가 빨라지고, 시스템이 잘 수행되고, 앱이 메모리에 더 오래 유지될 수 있는 등 다양한 관점에서 장점이 있다.

메모리를 줄이는 것에 대해 이야기하지만 실제로는 memory footprint 에 대한 이야기이다.

 

💡 footprint : 특정 하드웨어나 소프트웨어가 차지하고 있는 공간의 크기
하드웨어의 경우에는 물리적인 공간, 소프트웨어에서는 메모리 공간을 의미
memory footprint : 소프트웨어가 차지하는 메모리의 크기 즉 메모리 사용량 을 의미한다.

 

🐾 Memory Footprint

모든 메모리가 동일하게 생성되는 것은 아니다.

• 페이지에 대해 이야기 해야한다.
  

  

요런 페이지가 아니라, 메모리의 페이지 단위에 대해 알아야 한다.

• 메모리 페이지는 시스템에 의해 제공되고, 힙에 여러 개체를 저장할 수 있다.
• 그림의 Data 처럼 여러 페이지에 걸쳐 있을 수도 있다.

• Page 단위의 크기는 일반적으로 16KB 이다.
  • Page type clean, dirty ??  🤔 는 아래에서 더 살펴봅니다!
• 앱의 메모리 사용량은 페이지수 * 페이지 크기로 계산할 수 있다.

📄 Clean and dirty pages 예제

20,000개의 정수 배열을 할당하는 예시

• 시스템은 6개의 페이지를 준다.
• 처음 할당할 때에 페이지들은 clean 상태이다.

• 데이터 버퍼에 값을 쓰게 되면, 해당 값이 있는 페이지는 dirty 상태가 된다.
• 첫번째와 마지막 페이지 사이에 있는 페이지들은 clean 상태이다.
• clean page 라는 건 시스템으로부터 페이지를 할당받지만 값이 쓰여지지 않은 상태, dirty page 는 특정 값을 써 최초의 할당된 상태가 아닌 걸 의미하는듯 하다!

📁 Memory mapped files

• 또 하나 알아야 할 것은 메모리 매핑 파일,
• 메모리 매핑 파일은 디스크에 있지만 메모리에 로드된 파일을 의미한다.
• 읽기 전용 파일은 항상 clean page 이다.
• 커널은 파일이 Disk 에서 RAM 으로 들어오고 나가는 시간을 관리한다.

🖼 JPEG 이미지 파일을 통해 예시를 들어볼게요

• 50KB 크기의 JPEG 이미지의 경우, 메모리 매핑시 4페이지의 메모리에 매핑된다.
• 1페이지당 16KB, 4페이지 64KB 로, 14KB 의 여유 메모리가 있다.
• 네번째 페이지는 완전히 채워지지 않아 다른 용도로 사용할 수 있다.
• 완전히 채워진 세개의 페이지는 항상 시스템에서 제거할 수 있지만, 네번째 페이지는 다른 용도로 사용될 경우 바로 제거할 수 없는걸까요? 🤔

Typical app memory profile

일반적입 앱에서 메모리 풋프린트와 프로파일의 메모리 세그먼트는 dirty, compressed, clean 로 나뉘어진다.

clean memory

clean memory 는 페이지 아웃할 수 있는 데이터를 의미한다. (메모리 할당 해제가 가능한?)

• Memory mapped file 을 의미한다.
• 이미지, 데이터 블랍(Blob, Binary Large Object), 학습 모델
  • Blob,, 이미지, 비디오, 사운드 등과 같은 멀티미디어 객체를 저장하기 위한 자료형, Large Object의 위치 포인터를 저장한다.
• 프레임워크가 될 수도 있다.
  • 모든 프레임워크에는 DATA CONST 섹션이 있고, 일반적으로는 clean memory 에 속하지만 swizzling 을 통하면 dirty memory 가 될 수도 있다.

Dirty memory

Dirty memory 는 앱에서 값을 쓴 메모리를 의미한다.

• 문자열, 배열 등 동적으로 할당된 모든 객체
• 이미지 버퍼를 디코딩 하는 경우
• 프레임워크 중 데이터 섹션과 데이터 더티 섹션이 이에 속한다.

🏗 Frameworks

• 프레임워크에는 clean memory 에 속하는 영역과 dirty memory 에 속하는 영역이 둘 다 존재한다.
• 프레임워크를 자체적으로 유지하고 관리한다면, 싱글톤과 전역 생성자는 dirty memory 를 줄이는데 좋은 방법이 될 것이다.
  • 싱글톤은 생성된 이후 항상 메모리에 살아 있고,
  • 생성자 또한 프레임워크를 링킹하거나 클래스가 로드될 때마다 실행될 것이다.

🗳 Compressed memory (압축 메모리)

iOS 에는 전통적인 디스크 스왑 시스템이 없는 대신, 메모리 압축기 (Memory compressor) 를 사용한다. iOS 7 에서 도입 되었다.

• memory compressor 는 압축, 압축 해제를 수행한다.
• 접근되지 않은 페이지를 가져와 압축해서, 더 많은 공간을 만든다.
• 다시 접근할 경우 메모리를 읽을 수 있도록 압축을 해제한다.

캐싱에 사용되는 dictionary 를 예시로 들어봅니다 📔

• 세 개 페이지의 메모리를 사용하고 있지만, 한동안 사용하지 않고 시스템에 메모리 공간이 필요하다면 한 페이지로 압축될 수 있다.
• 현재 압축이 되어 한 페이지로 메모리 절약을 하고 있지만, 실제로 접근할 시점에는 다시 세 페이지를 사용하게 될 것이다.

⚠ Memory warnings

앱이 항상 메모리 경고의 원인은 아니다.

• 메모리가 부족한 디바이스를 사용중에 전화를 받으면 메모리 경고가 발생할 수 있고, 그때 앱이 종료될 수 있다.
• 메모리 압축기를 통해 압축된 경우, 실제로는 메모리를 더 쓸 수 있기 때문에 메모리 해제를 더 복잡하게 만든다.
• 메모리 경고가 발생할 때 캐싱을 하지 않거나 백그라운드 작업을 조정하는 등의 정책 변경을 권장한다.

메모리 경고시 앱에서 수행할 수 있는 동작으로, 캐시에서 모든 객체를 제거하기로 결정했다고 합시다 🤔

아까 압축했던 캐싱을 위한 딕셔너리에 액세스하기 때문에 더 많은 페이지를 사용하게 된다.

• 메모리가 제한되어 있는 환경에서는 적절하지 않다 🤔
• 캐싱된 개체들을 제거해 한페이지로 돌리기 위해, 이미 압축되어 한페이지로 유지되어 있는 상태를 풀어 투머치 작업을 하게 된다.

메모리 관점에서 캐싱에 대해 중요한 것들이 있다.

• ⚖️ CPU 와 메모리 사용의 트레이드 오프를 생각하자.
  • 캐싱을 할 때 CPU 가 반복적인 작업을 하지 않게 노력하지만, 캐싱을 너무 많이 하게되면 메모리를 많이 사용해 시스템에 문제가 발생할 수 있다.
• 메모리 압축기와 캐시가 있는걸 기억하고, 딕셔너리 대신에 NSCache 를 사용하는게 안전하다.
  • NSCache 는 메모리가 부족할 때 자동으로 캐싱된 것의 일부를 해제하도록 동작한다.

📏 Typical app memory profile

일반적으로 앱에서 메모리 사용량 (footprint) 에 대해 이야기 할 때에는 dirty, compressed 세그먼트를 의미한다. clean memory 영역은 크게 중요하지 않다.

• 모든 앱에는 사용 가능한 메모리 제한이 있다.
• 메모리 제한은 디바이스마다 달라질 수 있다.
• 앱마다 제한되는 메모리는 생각보다 많이 할당된다.
• 메모리 공간을 확장할 수 있지만, 이 공간은 적기 때문에 주의해야 한다.
• 앱에 할당된 메모리 공간을 초과하면 exception 이 발생한다.

Tools for Profiling Footprint

• 앱의 footprint 를 프로파일링 할 수 있는 도구를 소개합니다.
• Xcode memory gauge 는 디버깅시 앱의 메모리 공간을 빠르게 볼 수 있다.

Instruments 는 앱의 메모리 공간을 확인하기 위한 여러가지 방법을 제공한다.

• Allocations : 앱에서 생성한 힙 할당을 프로파일링
• Leaks : 시간이 지남에 따른 프로세스의 메모리 누수를 확인
• VM Tracker : dirty, compressed memory 를 프로파일링 하는 방법을 제공
  • 압축 메모리인 dirty size, swapped size, resident size 를 알려준다.
• Virtual memory trace : 앱과 관련된 가상 메모리 시스템의 성능을 알 수 있다
  • By Operation 탭에서 VM 프로파일을 제공해 page cache hits, page zero fills 를 볼 수 있다.

memory resource exceptions

• Xcode 10 부터는 해당 EXC exception 을 캐치해서 앱을 일시 중지한다.
• 해당 시점부터 메모리 디버거를 붙여 확인할 수 있다.

Xcode 메모리 디버거는 Xcode 8부터 제공되어, 객체간 디펜던시, 사이클, 누수(leak)를 추적할 수 있다.

• 그래프 형태로 나타난건 Xcode 10 부터라고 합니다 😇
• Xcode 내부적으로 Memgraph 파일 형식을 사용해 메모리 정보를 저장한다.
• Memgraph 를 export 해서 command line tool 에서 확인할 수도 있다.

vmmap

메모리 리소스 예외가 발생한 상태의 Memgraph 는 커맨드 라인 명령어인 vmmap 을 이용해서 분석할 수 있다.

• vmmap 은 프로세스에 할당된 가상 메모리 영역을 보여준다.

vmmap --summary <memgraph> 명령어를 통해서 해당 메모리 그래프의 전체적인 요약을 볼 수 있다.

• 영역의 메모리 크기, 더티 메모리 크기, 스왑되거나 압축된 메모리의 양을 보여준다.
• dirty, swap 영역이 중요 ..!
• swap size 는 압축된 데이터 크기가 아니라 사전에 압축된 데이터 크기이다.

vmmap <memgraph> 명령어를 이용하면 전체 영역에 대한 메모리 크기를 확인할 수 있다.

• Non-writable regions : 프로그램의 텍스트, 실행 코드 등 쓰기가 불가능한 영역

• Writable regions : 데이터 섹션 등 쓰기 가능한 영역, 프로세스 힙이 될 위치

• vmmap 과 awk 명령어를 통해서 dirty page 개수를 구하는 명령문을 작성할 수 있다.

 

leaks

leaks 명령어를 통해 더이상 레퍼런스가 없지만 할당되어 있는 객체를 확인할 수 있다.

• leak 객체는 절대 해제할 수 없는 dirty memory 이라는 점을 기억..!

메모리 디버거에서 leak 을 확인하는 법

• 3개의 객체가 강한 참조를 하고 있는 상태

• 누수된 객체를 표시할 뿐 아니라, retain cycle 도 표기된다.
• 프로세스에서 malloc 스택 로깅을 활성화했다면, 루트 노드에 대한 역추적도 제공한다.

heap

heap <memgraph> 명령어를 통해 힙에 할당되어 있는 객체들을 볼 수 있다.

• 메모리에 할당된 큰 객체나, 같은 종류의 객체가 많이 존재하는 등을 추적하는데 도움이 된다.

메모리 리소스 예외가 났을때의 Memgraph 를 가지고 확인해보면 각 객체의 클래스 이름, 개체 수, 평균 크기 등이 제공된다.

기본적으로는 개수에 따라 정렬되고, 크기순대로 정렬하고 싶다면 sortBySize 옵션을 추가하면 된다.

• 크기가 큰 NSConcreteData 객체 발견 👀

NSConcreteData 객체중에 하나의 주소를 가져와야 한다.

• -addresses all 옵션과 함께 클래스 이름을 전달하면 각 인스턴스에 대한 힙에 위치한 주소를 확인할 수 있다.

malloc_history

malloc stack logging 옵션을 활성화하면 각 할당에 대한 backtrace 를 기록한다.

• 역추적된 로그는 Memgraph 를 기록할 때 캡처되어 사용된다.
• malloc_history <memgraph> <address> 명령어를 통해서 특정 주소에 위치한 인스턴스가 할당되는 것을 역추적할 수 있다.

NoirFilter.apply 메소드에서 엄청 큰 NS data 를 만들고 있는 것을 발견 🧐

🙄 메모리 문제가 발생했을때 어떤 도구를 선택해야할까?

아래 세가지 케이스에 따라 사용하는 도구가 달라진다.

• 객체 생성을 보고 싶은지
  • malloc_history 명령어를 통해 메모리 할당을 역추적 가능
• 메모리의 객체나 주소를 참조하는 것을 보고싶은지
  • leaks 명령어를 통해 메모리 누수 확인 가능
• 인스턴스가 얼마나 큰지 확인하고 싶은지
  • vmmap, heap 명령어를 통해 크기 확인 가능

🖼 Images

iOS 앱에서 가장 큰 객체는 Images 이다.

• 이미지와 관련된 메모리 사용은 파일 크기가 아닌 이미지의 크기와 관련이 있다는 것이다.
• Memory use is related to the dimensions of the image, not the file size.
• 파일 크기는 590KB 이지만, 이미지의 크기는 10MB 이다.
  • 2048 * 1536 * 4bytes

🧐 왜 이렇게 사이즈가 큰지 알기 위해서는.. iOS 에서 이미지를 처리하는 방식을 알아야한다

• Load, Decode, Render 세가지 과정으로 나뉜다.
• Load 단계에서는 590KB 의 압축된 이미지파일을 메모리에 로드한다.
• Decode 단계에서 JPEG 파일을 GPU 가 읽을 수 있는 형식으로 변환한다. 압축된 이미지를 푸는 과정에서 10MB 가 된다.
• 디코딩된 후에 렌더링은 언제든 할 수 있다.

• 이미지 최적화 방법은 Images and Graphics best practice

SRGB

디코딩 이후에 SRGB 포맷은 한 픽셀 당 4 bytes 를 포함한다.

• 일반적인 그래픽의 이미지 포맷
• Red, Green, Blue, Alpha

Wide format

iOS 하드웨어는 wide format 으로 렌더링 할 수 있다.

• 와이드 포맷은 SRGB 각각이 두배씩 늘어난 형태로, 픽셀당 8 bytes 를 포함한다.
• 이미지의 크기를 두배로 늘리게 된다.

• 좀 더 작은 형태의 이미지 포맷,
• 한 픽셀당 2 bytes 를 포함하고, 휘도와 알파 값을 갖는다.

• Alpha 값 하나만 갖는 포맷으로 1픽셀당 1 byte 롤 포함한다.
• SRGB 에 비해 75% 적은 메모리를 사용하기에 흑백인 텍스트나 마스크에 적합하다.

이미지 형식은 1픽셀당 1 byte 에서 8 bytes 까지 다양하기 때문에, 상황에 따라 적당한 포맷을 선택해야 한다.
어떻게 선택해야 하나.. 싶었지만, 포맷을 직접 선택하지 않으면 된다고 한다 🤓

• UIGraphicsBeginImageContextWithOptions API 는 항상 픽셀당 4 bytes 를 사용했지만,
• UIGraphicsImageRenderer 를 사용하면 적절한 포맷을 설정해주기 때문에 메모리를 절약할 수 있다.

UIGraphicsBeginImageContextWithOptions 를 통해 마스크에 원을 그리고 있다

• 검정색 원을 그리는데 픽셀당 4 bytes 를 사용하는 불필요한 과정

UIGraphicsImageRenderer 를 사용하면 1픽셀당 1 byte 를 사용하도록 자동으로 변환된다.

• 해당 이미지를 다시 사용해서 색상만 변경할 수도 있다. 추가적인 메모리 할당이 없이 색상을 변경할 수 있다는 점!

⬇ Down sampling

일반적으로 썸네일을 만들기 위해 많이 사용하는 이미지 다운 샘플링

• UIImage 를 사용해서 사이징, 리사이징을 하는건 성능이 떨어진다.
  • 내부 좌표 공간 변환과 메모리에 있는 전체 이미지의 압축을 풀기에 성능이 떨어진다.
• ImageIO 프레임워크를 사용하면 이미지를 다운샘플링 할 수 있는데
  • 결과 이미지의 dirty memory 비용만 지불 수 있도록 스트리밍 API 를 사용한다.
  • 메모리 스파이크를 줄일 수 있다.

UIImage 를 사용해서 더 작은 이미지로 변환하는 코드

ImageIO 로 전환한 코드

• 디스크에서 파일을 로드해야 하는건 동일하지만 이미지의 크기를 지정하는건 매개변수를 통해 전달하면 된다.
• 변환된 CGImage 를 UIImage 를 래핑할 수 있다.
• 이미지 크기 또한 작고, 이전 코드보다 50% 빠르다.

📱 Optimizing when in the background

백그라운드에서 최적화하는 방법

• 앱의 전체 화면에 이미지가 있다고 가정한다면, 앱이 알림을 받아 다른 화면으로 이동하더라도 계속 메모리에 남아있게 된다
• 평소에 보지 못했던 큰 리소스는 언로드 하는 것이 좋다..
• 앱이 백그라운드로 가거나, 포그라운드로 돌아오는 라이프 사이클 이벤트를 이용하자.
• 백그라운드로 들어가는 경우 큰 이미지를 언로드 하고, 포그라운드로 돌아올 때 이미지를 다시 로드하도록 한다.
• 백그라운드에서 메모리를 절약하고, 사용자가 앱을 사용하러 포그라운드로 돌이올 때에도 동일하게 유지할 수 있게 된다

navigation controller, tab controller 의 경우에서도 특정 뷰 컨트롤러가 보이거나 사라질 때 동일한 처리를 해줄 수 있다.