ARC - 메모리 관리

기존 메모리 관리 방식

• 명시적 해제 : 메모리에 저장된 변수를 개발자가 모두 관리 (alloc init/retain -> release)
• 가비지콜렉터 : 가비지 콜렉터가 수시로 확인해서 안쓰는 객체 레퍼런스 해제
• 레퍼런스 카운팅 : 오너쉽 정책에 의해 객체의 해제(release) 정의

Reference counting?

• 인스턴스 객체의 오너만이 해당 인스턴스의 해제에 대해 책임
• 오너쉽을 가진 객체에 대해서만 reference count가 증가

예제

• 2번째 줄에서 생긴 인스턴스의 메모리를 해제할 방법이 없다.

NSString *str1 = [[NSString alloc] init];
NSString *str2 = [[NSString alloc] init];
NSString *str3 = [[NSString alloc] init];
str2 = [[NSString alloc] init];
[str1 release];
[str2 release];
[str3 release];

👏🏻 ARC: Automatic Reference Counting

• 11년 WWDC 발표 이후, 기존에 수동(MRC)으로 개발자가 직접 release(해제)를 통해 reference counting을 관리해야 했던 부분을 자동으로 관리할 수 있도록 조정되었다.
• 메모리 관리가 조금 더 간편해졌다.

Strong

• 오너쉽을 가진 객체
• strong is “normal” reference counting

Weak

• 점선 포인터: 힙 영역의 인스턴스를 가리키고 있으나, 오너쉽은 없음
• strong 포인터가 인스턴스와 연결이 해제되면, weak 변수가 가리키는 인스턴스가 없어지면서 weak은 nil이 될 수 있음
• if no one else is interested in this, then neither am I, set me to nil in that case
• A weak pointer will NEVER keep an object in the heap
• Because it has to be nil-able, weak only applies to Optional pointers to reference types
• Great example: outlets (strongly held by the view hierarchy, so outlets can be weak)

Unowned

• unowned means “don’t reference count this; crash if I’m wrong”
• 절대 nil이 아니라고 개발자가 보장함. 100% 확실할 때만 사용.

참고

• weak은 let으로 선언이 안됨.
• UI 속성들은 모두 weak으로 선언하는게 좋음: 기본적으로 self.view가 strong으로 subView들을 갖고 있기 때문.

샘플코드

• Closures are stored in the heap as well (i.e. they are reference types). What is more, they “capture” variables they use from the surrounding code into the heap too. Those captured variables need to stay in the heap as long as the closure stays in the heap. This can create a memory cycle.
• 때문에, 순환 참조를 막기 위해, 값을 캡쳐하는 클로저 내부에서는 외부의 reference타입 property에 대해 weak 또는 unowned로 선언하는 것이 좋다.

addUnaryOperation("✅”){ [weak self] in 
	self?.display.textColor = UIColor.green
	return sqrt($0)
}

Resources

• Xcode Instruments