监控 NSNotifications答案

【问题标题】：Monitoring NSNotifications监控 NSNotifications
【发布时间】：2013-02-19 02:13:08
【问题描述】：

我在这篇帖子的评论中注意到 Overhead of NSNotifications，用户 JustSid 说

如果应用程序在每个运行循环周期中不发送 30+ 个，则开销不会很明显

我想编写一个小助手类来跟踪在当前运行循环周期中发送了多少 NSNotifications，并在它超过某个预先配置的数字时提醒我。我知道我可以注册所有通知（将 nil 传递给名称和对象），但我如何跟踪它们是从哪个运行循环周期发送的？

【问题讨论】：

恕我直言，这种方法似乎值得怀疑。我没有看到任何证据表明使用 NSNotificationCenter 比直接在对象之间发送消息有更高的开销。任何性能问题都将特定于通知的处理（与发送相比）。如果您有大量对象观察通知和/或执行线程阻塞任务，这显然会对应用程序性能产生影响。那是我会集中时间和精力的地方。 @JustSid 的评论是武断和推测性的。

标签： ios objective-c cocoa-touch nsnotificationcenter nsnotifications

【解决方案1】：

在 NSNotificationCenter 上有一个类别很容易，它在添加通知观察者时增加一些内部整数（并因此在删除它时减少它），但你必须问自己：多少是太多了？

如果您认为它是某个任意整数（例如，为了 30），那么当您在内存和处理器限制比您现在拥有的设备更多的设备上测试它时会发生什么？如果你在一个可以轻松处理 30 个观察者和浮动通知的设备上测试它会发生什么（这完全是浪费）？虽然可以编写一般规则，但不可能在每种情况下衡量通知对应用程序响应时间的影响。

当观察者的数量使某些系统功能陷入困境时，另一种可能性是让后台进程查询通知堆栈（或以某种方式像上面一样在内部对其进行测量）。当然，忽略这项工作太多的事实，您将设计一个子系统，它可能会利用尽可能多的内存并从性能上窃取尽可能多的性能，就像您最初尝试使用它进行补救一样！

TL;DR 您可以使用许多其他模式和结构来代替通知，那么为什么要满足 NSNotification 的需求呢？

【讨论】：

这是我只计划在调试时运行的东西，我更担心发送的通知数量，而不是我的情况下的观察者数量。我只有少数观察员。我有一个监视主线程的类，如果它在可配置的时间段内没有响应，则 NSLogs“主线程无响应”。我在想一个类似的工具。通知的数量非常随意，但如果我在每个运行循环中发送 20 个通知并且我进行了更改并且突然在每个运行循环中发送 500 个通知，那就太好了。
那么就使用那个类。它似乎也足以处理阻止通知。或者，如果您愿意，请重新编写 NSNotificationCenter。真的不应该那么难。
我的回答是 A) 你告诉我你有一个可以跟踪线程阻塞的工具，B) 这样的工具太笨重而没有用处。您不仅需要跟踪主线程，还需要过滤 only NSNotification 阻塞循环的方法。至少，它太笨拙了（调试工具通常与应用程序本身分开，因此它们不会干扰应用程序的执行并报告错误数据）。改写或重新提出有关该问题的问题以获得“更好”的答案。
//跟踪每个运行循环周期发送了多少// 完全正确！您需要跟踪运行循环并过滤发送的通知数量！如果没有暴露的 RunLoop 接口或对象（NSRunLoop 仅适用于 OS X），您希望如何做到这一点？这正是我一直告诉你工作量太大的原因。相信我，如果获得运行循环的调用很容易，那么关于如何做到这一点的方法会有一百万个答案。
您是否希望运行循环将其交给您？运行循环不关心执行了什么，运行循环只关心及时运行代码。不仅如此，iOS 上没有用于访问运行循环的公开 API！再次相信我，如果这很简单，那么会有更多的答案。