여전히 기억해야 할 주요 메모리 관련 문제는 유지주기입니다. 한 객체가 다른 객체에 대한 강한 포인터를 가지고 있지만 대상 객체에 원래 포인터를 다시 가리키는 강력한 포인터가있을 때 발생합니다. 이러한 객체에 대한 다른 모든 참조가 제거 되더라도 여전히 서로 붙잡고 해제되지 않습니다. 체인의 마지막 체인이 이전 오브젝트를 다시 참조 할 수있는 오브젝트 체인에 의해 간접적으로 발생할 수도 있습니다.

이러한 이유로 __unsafe_unretained및 __weak소유권 한정자가 존재합니다. 전자는 객체가 가리키는 객체를 유지하지 않지만 객체가 사라질 가능성을 열어두고 메모리가 나쁜 메모리를 가리키는 반면 후자는 객체를 유지하지 않고 대상이 할당 해제되면 자동으로 nil로 설정됩니다. 둘 중 __weak일반적으로이를 지원하는 플랫폼에서 선호됩니다.

이 한정자를 사용하여 객체가 델리게이트를 유지하지 않고 사이클을 유발하지 않도록하는 델리게이트와 같은 항목에 사용할 수 있습니다.

또 다른 중요한 메모리 관련 문제는 Core Foundation 객체 malloc()및와 같은 유형에 사용하여 할당 된 메모리를 처리하는 것 char*입니다. ARC는 이러한 유형을 관리하지 않으며 Objective-C 객체 만 관리하므로 여전히 직접 처리해야합니다. 핵심 Foundation 유형은 때로는 까다로울 수 있습니다. 때로는 일치하는 Objective-C 객체에 브리지되어야하고 그 반대도 마찬가지입니다. 이는 CF 유형과 Objective-C를 브리징 할 때 ARC에서 제어를 앞뒤로 전송해야 함을 의미합니다. 이 브리징과 관련된 일부 키워드가 추가되었으며 Mike Ash는 그의 긴 ARC 글 에서 다양한 브리징 사례에 대해 잘 설명 했습니다 .

이 외에도, 게시 된 사양 이 자세하게 설명 되는 몇 가지 덜 빈번하지만 여전히 문제가되는 경우가 있습니다 .

객체에 대한 강력한 포인터가있는 한 객체를 유지하는 것을 기반으로하는 많은 새로운 동작은 Mac의 가비지 수집과 매우 유사합니다. 그러나 기술적 토대는 매우 다릅니다. 이 스타일의 메모리 관리는 더 이상 지적되지 않는 객체를 정리하기 위해 정기적으로 실행되는 가비지 수집기 프로세스가 아니라 Objective-C에서 모두 준수해야하는 엄격한 유지 / 해제 규칙에 의존합니다.

ARC는 단순히 반복적 인 메모리 관리 작업을 몇 년 동안 수행하여 컴파일러로 오프로드하므로 다시 걱정할 필요가 없습니다. 이렇게하면 가비지 수집 플랫폼에서 경험할 수있는 정지 문제 나 톱니 메모리 프로파일이 없습니다. 가비지 수집 된 Mac 응용 프로그램에서이 두 가지를 모두 경험했으며 ARC에서 어떻게 작동하는지 알고 싶어합니다.

가비지 수집 대 ARC에 대한 자세한 내용 은 Objective-C 메일 링리스트 에서 Chris Lattner의 매우 흥미로운 응답을 참조하십시오 . 여기서 Objective-C 2.0 가비지 수집에 비해 ARC의 많은 장점을 나열합니다. 나는 그가 설명하는 몇 가지 GC 문제에 부딪쳤다.

답변