监测NSNotifications

我在这个帖子上Overhead of NSNotifications评论注意到，用户JustSid说监测NSNotifications

的开销不会明显，如果应用程序不会发送30+每轮循环周期

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

2013-03-04 Cody C

恕我直言，这种做法似乎是可疑的。我没有看到使用NSNotificationCenter的开销比直接在对象之间发送消息更高的开销。任何性能问题都将针对通知的处理（与发送）相关。如果有大量对象观察通知和/或执行线程阻塞任务，这些任务显然会对应用程序性能产生影响。这就是我将时间和精力集中的地方。 @ JustSid的评论是任意的和推测性的。 – XJones 2013-03-04 23:40:27

当添加通知观察者时（在移除时减少它），在NSNotificationCenter上有一个类别可以增加某些内部整数，但您必须问自己：多少太多？

如果您认为它是某个任意整数（例如，举例来说，例如30），那么当您在具有比现在更多的内存和处理器限制的设备上测试它时会发生什么？如果您在可轻松处理30名观察员和浮动通知的设备上进行测试，会发生什么？（这将会是一种完全浪费）？尽管可以对通用规则进行编码，但在任何情况下都不可能评估通知对应用程序响应时间的影响。

当观察者将某些系统函数进行爬网时，另一种可能性是后台进程查询通知堆栈（或者以某种方式在上面内部对其进行测量）。当然，如果忽略这样一个事实，那就是太多的工作，你会设计一个子系统，这个子系统可能会利用尽可能多的内存和窃取，尽可能远离性能，正如你试图用它来解决这个问题一样！

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

来源

2013-03-04 21:20:21 CodaFi

这是我在调试时只计划运行的东西，我更担心发送通知的数量，而不是我的情况下观察者的数量。我只有少数观察员。我有一个类监视主线程，如果它没有响应一个可配置的时间段，NSLogs“主线程无响应”。我正在考虑一个类似的工具。通知的数量是非常随意的，但是如果我每次运行循环发送20个通知并且我做出更改并且突然发送每个运行循环的500个通知，那就太好了。 – 2013-03-04 21:47:39

然后就使用那个类。似乎足以应付阻止通知。或者，如果你愿意，可以重新编写NSNotificationCenter。这真的不应该那么难。 – CodaFi 2013-03-04 22:12:45

我的答案是：A）你告诉我你有一个工具可以跟踪线程阻塞，B）这样的工具太笨重而无法使用。你不仅需要跟踪主线程，而且还需要筛选* NSNotification的阻塞循环的方法。至少，它的布局过于笨拙（调试工具通常与应用程序本身分离，所以它们不会干扰应用程序的执行并报告错误的数据）。为了“更好”的答案，重新说明或回答一个问题。 – CodaFi 2013-03-04 22:33:59

监测NSNotifications

回答

相关问题