KVO 관측 대 NSNotificationCenter 관측

Question

KVO 대 NSNotificationCenter 관측에서 서로를 사용할 이유가 있는지 궁금합니다. 성능, 메모리 사용량, 속도 등?

Answer 1

두 개는 항상 서로 바뀔 수있는 것은 아닙니다. 개념적으로, KVO는 객체의 속성을 관찰하기위한 것입니다. 예를 들어 관찰자에게 이벤트 속성에 대한 변경 사항이 아니라 이벤트 발생 사실을 사용자에게 알리기 때문에 KVO를 사용하여 NSApplicationWillTerminateNotification을 대체 할 수 없습니다.

성능 및 메모리 사용량은 빠르며 무시할만한 메모리를 사용합니다. NSNotificationQueue은 병합되어 플러딩 된 알림을 중지합니다. KVO는 내가 아는 한 병합 현상이 전혀 없기 때문에 성능 문제가 발생합니다. 수백 개의 개체를 관찰하고 있었는데 일괄 업데이트가 이러한 개체에 발생하면 수백 개의 KVO 콜백이 발생합니다. KVO 자체의 성능 문제는 아니었지만 일괄 업데이트로 인해 자체 코드가 실행되었습니다.

성능은 실제로 문제가 아니며 문제에 가장 적합합니다. 재산이 변경된 경우 KVO를 사용하십시오. 속성 변경이 아닌 경우 단일 관찰자 또는 여러 관찰자가 필요한지 여부에 따라 대리인 또는 알림을 사용하십시오.

Answer 2

아주 오래된 질문이지만, 몇 가지 점을 추가 할 생각입니다. 나는 Tom Dalling's answer에 동의하지만 큰 응용 프로그램에는 개체의 속성에 대한 관찰자를 추가하는 경향이있는 많은 시나리오가 있으며 우리는 관찰자 목록에서이를 제거 할 수 없습니다.

내 응용 프로그램에서 다음 시나리오를 고려해 보겠습니다. ViewController가 뱀 객체를 표시하면이 객체의 속성 변경 인 "독"을 관찰하고 있습니다. 그래서 viewController가 다른 뱀을 보여줄 필요가있을 때마다 나는 그 뱀 객체의 관찰자로부터 뷰 컨트롤러를 제거하기 만했을 것입니다.

앱이 단일 뱀 대신 뱀의 목록을 표시하도록 발전한 것입니다. 즉, 해당 개체의 모든 뱀에 대한 속성을 관찰해야한다는 것을 의미합니다. 이제 오래된 뱀이 배열에서 제거 될 때이 뱀 객체에서 관찰자로 뷰 컨트롤러를 제거 할 수 있도록이 이벤트에 대해 알아야합니다. 이렇게하려면 배열 자체의 변경 사항을 먼저 관찰해야합니다. 이렇게하려면 특정 프로토콜을 따라 객체를 배열에 삽입하고 배열에서 제거해야합니다. 이렇게하면 복잡성이 증가합니다. 우리 모두는 객체에서 관찰자를 제거하지 않고 객체가 OS에 의해 해제되는 경우의 결과를 알고 있습니다!

위, 여기에 큰 문제는이 객체가 출시되기 전에 내가 관찰자에서 그들을 제거하기 위해 주어진 객체에 대한 KVO 관계자의 목록을 얻을 수 이다 인용 한 예이다 -이 쉽게 NSNotification에 의해 달성 될 수있다 NSNotificationCenter. 때로는 KVO를 통해 NSNotification을 사용하는 경향이 있지만 KVO는 항상 좋은 디자인 관행에 대한 통보보다 우위에 있습니다.