Разход на NSNotifications

Наскоро започнах да използвам NSNotifications:

[[NSNotificationCenter defaultCenter] postNotificationName: selector: object:]; ....

Намирам това за страхотна концепция за комуникация между контролери за изглед. Почти изглежда твърде лесно да се използва NSNotifications за всички комуникации в приложението.

В случай, че използвам NSNotifications за по-голямата част от работата в моето приложение, какви мислите ще бъдат режийните разходи за твърде много от тях?


person Legolas    schedule 09.06.2011    source източник


Отговори (2)


Изглежда си спомням, че прочетох, че NSNotification е доста трудоемък, така че използването на много от тях вероятно не би било най-добрата идея. Вместо това бих помислил за приемане на delegate протоколи. Можете лесно да създадете свой собствен, за да казвате на вашите файлове какво да правят и кога.

Този сайт дава пример, доста подобен на този, който използвах, за да науча как да създавам делегати и може да си струва да се разгледа. Използвах NSNotifications през цялото време, докато не научих за делегатите и оттогава превключих всичките си известия към делегирани методи вместо това

person justin    schedule 09.06.2011
comment
Делегатите са страхотни, без съмнение, но те не са заместител на известията. Освен това режийните разходи няма да бъдат забележими, ако приложението не изпраща 30+ на цикъл на изпълнение. - person JustSid; 09.06.2011
comment
Много вярно, трябва да използвате много postNotification повиквания, за да забележите наистина разлика. Предполагам, че съм малко виновен, че предпочитам делегатите, а не известията - person justin; 09.06.2011
comment
Това беше страхотно. Благодаря за ЛИНК! - person Legolas; 09.06.2011
comment
stackoverflow.com/questions/6297829/ - person Legolas; 09.06.2011

Едно от нещата, които трябва да запомните за NSNotifications е, че те са блокиращ механизъм. Така че докато обектът, публикуващ известието, не трябва да знае кой го получава, ако има твърде много получатели, той ще трябва да обработи всички тях, преди postNotification повикването да може да се върне. Това е нещо, което ще трябва да вземете под внимание.

Като такива, както каза @slev, делегатите са по-добър подход. Използвайте известия само когато не можете да използвате подхода на делегиране.

person Deepak Danduprolu    schedule 09.06.2011
comment
Дийпак - има ли шанс за чат? - person Legolas; 09.06.2011
comment
Това е основният риск от NSNotifications. Да кажем, че уведомявате съседен обект, че мрежова заявка е изпълнена, и го задействате, за да обработи тази заявка. NSNotification се случва в главната нишка и освен ако не направите нещо по въпроса, функцията, която се извиква, ще свърши работата си и в главната нишка. Ако това е продължителен процес, това ще блокира потребителския интерфейс (нещата няма да се превъртат или анимират, просто ще изглеждат замразени), докато този процес не приключи. Още по-лошо, ако трябва да се обадите на куп наблюдатели, потребителският интерфейс блокира, докато всички не свършат. - person Dan Ray; 09.06.2011
comment
Това каза, че ги използвам и ги харесвам. Просто трябва да знаете техните ограничения. - person Dan Ray; 09.06.2011
comment
stackoverflow.com/questions/6297829/ - person Legolas; 09.06.2011
comment
Ако блокирането на основната нишка е проблем, можете да използвате метода addObserverForName:object:queue:usingBlock: на NSNotificationCenter, за да добавите наблюдателя. Това ви дава гъвкавост да изберете нишката, в която да обработите известието. Освен това се извиква селектор, когато се публикува известие, винаги можете да напишете код в селектора, така че да не блокира основната нишка. Като се има предвид NSDistributedNotificationCenter също е опция. - person sherlock; 12.04.2013