Abandoned Memory ?
흔히 얘기하는 Leaked Memory 는 reference가 존재 하지 않는 잃어버린 Memory를 이야기한다.
그럼 Abandoned Memory는 무엇일까?
Abandoned Memory는 Reference가 존재하지만 사용하지 않는 Memory 이다.
Abandoned Memory는 Profiler가 찾을 수 없기 때문에, Debugging하기가 매우 어렵다.
허나, Instrument 의 Heap Shot기능을 이용하면,
비교적 쉽게 Debugging이 가능하다. Abandoned Memory를 찾아 낼수 있다.
Heapshot의 기능?
Heapshot의 기능은 Heapshot간의 Memory Allocation Diff 정보를 제공한다는것이다.
HeapShot#0 -> Do some task -> HeapShot#1
이런식으로 흘러 갔을때, HeapShot#0와 HeapShot#1의 Memory allocation Diff가 0 bytes가 되는것이 이상적이라 할수 있겠다.
현실에선, Cache등의 이유로 Diff가 0가 되는일은 거의 없겠다.
허나 HeapShot이 Diff를 제공하기에 Task 후에 살아 남은 Memory Block들을 한눈에 볼수 있고,
내가 의도지하지 않은 Memory Block을 비교적 쉽게 찾아 낼 수 있다.
HeapShot 예제
위의 Sample Program은 2 Button이 존재하며, Memory Leak을 유발하는 Button 하나와 아무것도 하지 않느 버튼 하나가 존재한다.
-(IBAction) pressLeak:(id)aSender {
[[NSArray alloc] initWithObjects:@"abcdef",@"abcdef",@"abcdef",@"abcdef", nil];
}
Leak Button을 Touch 하면 아무의미 없이 NSArray Object하나를 만든다.
Profile 모드로 앱을 실행시키고, Instrument Template은 "Allocation"을 선택한다.
아래 그림은 Heapshot을 찍은후의 Heapshot List이다.
Memory Leak을 보여주는것이 아니라, Memory Allocation Diff를 보여주는것이기때문에,
Heapshot에 기록되는 모든 Memory가 Leak 혹은 Abandoned 되었다고 판별할 수 없다.
필자는 Heapshot4와 Heapshot8을 찍기 직전에 "Leak" button을 Touch 했다.
Heapshot8을 펼쳐 보면 예상과의 달리 Object들이 많이 생성되었다.
아마 Touch Handling을 위해 Framework단에서 생성하는 Object들일것이다.
위의 Test Code를 보면 NSArray를 만들었기에, 유일한 NSArray Object의 생성주기를 보자.(Instrument 우측 View에 나타난다.)
우측에 보면, Object가 만들어진 Stack Trace가 노출되고, Framework 코드가 아닌, 내가 작성한 코드는 Bold로 Highlight된다.
해당 부분을 Double Click 하면 코드도 볼수 있다.
생각보다 Smart한 방법은 아니고, 사람에 의존적인 방식이다.
허나 Diff를 제공하여, 살아 남은 Object 를 추적할 수 있기에, 매우 유용하다.
Memory 문제에 자유로운 개발자는 아마 없을터,
Leaked Memory가 아니라, Abandoned Memory 를 찾아 내는데는 꽤나 유용한 Tip이라고 생각한다.