用户 JustSid 说,我在评论这篇文章Overhead of NSNotifications时注意到
如果应用程序在每个运行循环周期中不发送 30+ 个,则开销不会很明显
我想编写一个小助手类来跟踪在当前运行循环周期中发送了多少 NSNotifications,并在它超过某个预先配置的数字时提醒我。我知道我可以注册所有通知(将 nil 传递给名称和对象),但是我如何跟踪它们是从哪个运行循环周期发送的?
用户 JustSid 说,我在评论这篇文章Overhead of NSNotifications时注意到
如果应用程序在每个运行循环周期中不发送 30+ 个,则开销不会很明显
我想编写一个小助手类来跟踪在当前运行循环周期中发送了多少 NSNotifications,并在它超过某个预先配置的数字时提醒我。我知道我可以注册所有通知(将 nil 传递给名称和对象),但是我如何跟踪它们是从哪个运行循环周期发送的?
在 NSNotificationCenter 上有一个类别很容易,它在添加通知观察者时增加一些内部整数(并因此在删除它时减少它),但你必须问自己:多少是太多了?
如果您认为它是某个任意整数(例如,为了 30),那么当您在内存和处理器限制比您现在拥有的设备更多的设备上测试它时会发生什么?如果你在一个可以轻松处理 30 个观察者和浮动通知的设备上测试它会发生什么(这完全是浪费)?虽然可以编写一般规则,但不可能在每种情况下衡量通知对应用程序响应时间的影响。
另一种可能性是当观察者的数量使某些系统功能陷入困境时,让后台进程查询通知堆栈(或以某种方式在内部像上面一样对其进行测量)。当然,忽略这项工作太多的事实,您将设计一个子系统,它可能会利用尽可能多的内存并从性能上窃取尽可能多的性能,就像您首先尝试使用它进行补救一样!
TL;DR 有很多其他的模式和结构可以用来代替通知,那么为什么要满足 NSNotification 的需求呢?