NSNotifications 的开销答案

【问题标题】：Overhead of NSNotificationsNSNotifications 的开销
【发布时间】：2011-06-09 16:15:37
【问题描述】：

我最近开始使用NSNotifications：

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

我发现它对于视图控制器之间的通信来说是一个很棒的概念。对于应用程序中的所有通信，使用NSNotifications 似乎有点太容易了。

如果我在我的应用程序中使用NSNotifications 来完成大部分工作，您认为其中太多的开销会是什么？

【问题讨论】：

【解决方案1】：

关于NSNotifications，您需要记住的一件事是它们是一种阻塞机制。因此，虽然发布通知的对象不需要知道谁在接收它，但如果接收者太多，它必须在postNotification 调用返回之前处理所有这些。这是您必须考虑的事情。

因此，就像@slev 所说，委托是一种更好的方法。仅当您无法使用委托方法时才使用通知。

【讨论】：

Deepak - 有机会聊天吗？
这是 NSNotifications 的主要风险。假设您正在通知邻居对象网络请求已完成，并将其触发以处理该请求。 NSNotification 发生在主线程上，除非你对它做点什么，否则被调用的函数也会在主线程上工作。如果它是一个长时间运行的过程，那将阻塞 UI（事物不会滚动或动画，它只会看起来冻结），直到该过程完成。更糟糕的是，如果您有一堆观察者要调用，UI 会一直阻塞，直到它们全部完成。
也就是说，我使用它们并且我喜欢它们。你只需要知道它们的局限性。
stackoverflow.com/questions/6297829/…
如果阻塞主线程是个问题，你可以使用 NSNotificationCenter 的 addObserverForName:object:queue:usingBlock: 方法来添加观察者。这使您可以灵活地选择处理通知的线程。此外，发布通知时会调用选择器，您始终可以在选择器中编写代码，使其不会阻塞主线程。考虑 NSDistributedNotificationCenter 也是一种选择。

【解决方案2】：

我似乎记得读过 NSNotification 非常消耗开销，因此使用其中的很多可能不是最好的主意。相反，我会考虑采用delegate 协议。您可以轻松创建自己的文件来告诉您的文件要做什么以及何时执行。

This site 给出了一个与我用来学习如何创建委托的示例非常相似的示例，可能值得研究一下。我曾经一直使用 NSNotifications，直到我了解了委托，并从那时起将我所有的通知切换到委托方法

【讨论】：