IOS 응용 프로그램을위한 메모리 관리 방법 -

는 현재 객체를 사용하는 다른 객체의 수입니다. 보유 수 (retention count)가 0보다 큰 한, 메모리 관리자는 누군가가 그 객체에 관심을 갖고 있다고 가정합니다. 객체의 보유 카운트가 0이되면 메모리 관리자는 아무도 더 이상 필요가 없다는 것을 알고 객체에 dealloc 메시지를 보낸 다음 메모리를 시스템에 반환하여 재사용합니다. 그 과정은 꽤 간단하게 들릴지 모르겠지만 보유 수는 어떻게 증가하고 감소합니까? Xcode 4. 2와 iOS 5.0이 나오기까지는 앱에서 보유 개수를 관리해야했습니다. alloc 또는 new 또는 muteableCopy 메시지를 통해 객체를 만들면 객체의 보유 개수가 1로 설정됩니다. 응용 프로그램에서 이러한 메소드 중 하나를 사용하면 소유권이 메시지를 전송 한 객체로 전송됩니다. 그 개체는 유지되었으며 메시지를 보낸 개체는 개체의 비 독점적 소유자

가됩니다.

소유권

은 개체가 더 이상 필요하지 않을 때 메시지를 보내서 명시 적으로 해제 될 때까지 개체가 사용된다는 것을 의미합니다. Xcode 4. 2 및 iOS 5. 0 이전에는 이러한 방법 중 하나를 사용하여 개체를 만들지 않았지만 소유자가되기를 원했기 때문에 개체가 주위에 머물러 있어야만 자신이 사용할 때까지 사용할 수있었습니다 그것으로 끝났습니다. 보유 수를 늘리기 위해 보관 메시지를 보내고, 끝났을 때 해제 메시지를 보내야했습니다. 이것은 객체의 생성자 (보유 수를 1로 설정했기 때문)가 자동으로 해제했을 수 있기 때문입니다. 객체에 나중에 릴리스 될 릴리스 메시지를 보냈습니다 (대개 다음 번 실행 루프 입력됩니다). 이것은 객체의 소유권을 포기하고 메소드에서 객체를 반환 할 때와 같이 즉시 할당 해제 될 가능성을 피하기 위해 유용합니다. 어느 경우이든 객체를 사용할 수 있도록 객체에 대한 포인터를 유지 관리하고있었습니다. 이 접근법은 이론적으로 단순했지만 프로그래머에게는 정말 골치 거리였습니다. 대부분의 시스템 충돌은 응용 프로그램의 메모리가 부족하여 시스템에 의해 종료 되었기 때문에 발생합니다. 이 중 일부의 경우, app 는 메모리 경고 메소드에 응답하지 않고 메모리 부족 경고를 관리합니다.

대부분의 경우 앱이 메모리 부족 경고에 응답하더라도 메모리가 누출 되었기 때문에 가능한 작업으로 제한되었습니다.

일부 객체가 사용되지 않았기 때문에 메모리를 실제로 사용할 수 있었지만 객체의 메모리가 시스템으로 다시 릴리스되지 않았습니다. 이러한 객체에 대한 포인터가 더 이상 존재하지 않으므로 해제되고 할당 해제되고 메모리가 다시 사용되었습니다.

개발자는 메모리를 자동으로 관리하는 여러 가지 방법을 사용했습니다. 하나는

가비지 콜렉션이고, 는 메모리를 스캔하여 포인터가없는 오브젝트를 해제합니다. Objective-C의 가비지 수집은 Mac에서 가능하지만 가비지 수집에는 몇 가지 문제가 있습니다. 가장 부적절한시기에 앱을 시작하고 일시 중지 할 수 있으며 성능이나 사용자 경험에 영향을 미치지 않습니다. iOS에서는 구현되지 않았고 OS X 10.8 (Mountain Lion)부터 사용되지 않습니다.

Objective-C 컴파일러의 최신 버전 (ARC (Automatic Reference Counting) 이 제공됨)을 사용하여이 메모리 관리를 모두 수행해야합니다. 프로젝트를 만듭니다. ARC는 컴파일러에서 독자적으로해야했던 일을합니다. 모든 릴리스, 자동 응답 및 보유를 처리합니다.