Было бы достаточно легко иметь категорию в NSNotificationCenter, которая увеличивает некоторое внутреннее целое число при добавлении наблюдателя уведомлений (и, следовательно, уменьшает его при удалении), но вы должны спросить себя: насколько это слишком много?
Если вы считаете, что это какое-то произвольное целое число (например, 30), то что произойдет, если вы протестируете его на устройстве, которое имеет больше ограничений по памяти и процессору, чем то, которое у вас есть сейчас? Что произойдет, если вы протестируете его на устройстве, которое может легко обрабатывать 30 наблюдателей и уведомления, плавающие вокруг (это было бы полной тратой времени)? Хотя можно было бы закодировать общие правила, было бы невозможно оценить влияние уведомлений на время отклика приложения в каждом случае.
Другой возможностью может быть то, что фоновый процесс запрашивает стек уведомлений (или каким-то образом просто оценивает его внутренне, как указано выше), когда количество наблюдателей приводит к обходу определенных системных функций. Конечно, игнорируя тот факт, что это слишком много работы, вы бы проектировали подсистему, которая, вероятно, использует столько же памяти и снижает производительность, сколько вы пытались исправить с ее помощью в первую очередь!
TL;DR Существует так много других шаблонов и структур, которые вы могли бы использовать вместо уведомлений, так почему же именно вы удовлетворяете потребности NSNotification?
person
CodaFi
schedule
04.03.2013
