Накладные расходы на NSNotifications

Недавно я начал использовать NSNotifications:

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

Я считаю, что это отличная концепция для связи между контроллерами представления. Кажется, слишком просто использовать NSNotification для всех коммуникаций в приложении.

В случае, если я использую NSNotification для большей части работы в своем приложении, как вы думаете, какие накладные расходы будут для слишком многих из них?


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

Одна из вещей, которые вам нужно помнить о NSNotification, это то, что они являются блокирующим механизмом. Таким образом, хотя объекту, отправляющему уведомление, не нужно знать, кто его получает, если получателей слишком много, он должен будет обработать их всех, прежде чем вызов 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
Если блокировка основного потока является проблемой, вы можете использовать метод NSNotificationCenter addObserverForName:object:queue:usingBlock: для добавления наблюдателя. Это дает вам гибкость в выборе потока, в котором будет обрабатываться уведомление. Кроме того, селектор вызывается при отправке уведомления, вы всегда можете написать код в селекторе, чтобы он не блокировал основной поток. Рассмотрение NSDistributedNotificationCenter также является вариантом. - person sherlock; 12.04.2013