NSNotificationCenter非常酷,我们可以用它构建非常可扩展的应用程序。我的问题是:我们是否可以在应用程序中滥用NSNotificationCenter,即密集使用它还是不是一个好的选择? 目前我正在使用它时,我有JSON服务响应:我发布通知,所以我有几个听众听这种类型的通知。到目前为止,我有几十个服务要调用,让我们说基于这些通知要实现更多的操作。 WDYT? 谢谢
答案 0 :(得分:11)
根据我的经验,编写广泛使用NSNotificationCenter的应用程序会导致维护噩梦,需要引用使用您的数据的(委托)对象意味着您可以逐步完成处理数据的实际过程;通知事情太过断线。
也就是说,有很多次通知是有道理的(设备轮换,应用启动/退出,广泛的状态变化),但我通常会尽量避免使用它们。
我发现Notifications工作正常的一个地方是我有一个控制器来管理许多其他控制器使用的数据;当数据发生变化时,我启动通知,这允许所有感兴趣的各方更新。例如,我可能有一个UserController来管理有关当前用户的信息(名称,照片等)。当某些用户数据被更改时,我会发布通知(例如UserControllerDidUpdatePhotoNotification)。然后,任何感兴趣的视图控制器都可以选择更新他们正在显示的照片。
我认为阻止我使用通知的最大原因是需要可维护性,如果您使用通知仍然允许您拥有可维护的代码然后继续使用它们;如果没有,请切换到其他设计。
答案 1 :(得分:6)
当NSNotificationCenter发送通知时,它与直接通知收件人的通知发件人消息完全没有任何不同。 NSNotificationCenter提供的好处是对象能够进行通信而无需彼此维护引用。
我认为不滥用NSNotificationCenter的诀窍是确保您的通知处理程序有效。如果您知道许多对象将消耗单个通知,那么您应该确保这些通知处理程序尽可能高效。您可以使用一些技巧来完成此操作,例如使用有价值的信息填充NSNotification的userinfo字典,通知处理程序可以使用这些信息轻松快速地确定应该通知的内容(如果有的话)。
您可以使用Instruments来衡量通知处理程序的运行时间,并且可以尝试进一步优化。请记住,通知处理程序在负责生成通知的同一个线程上调用,因此所有通知处理程序一次运行一个,直到它们全部完成为止。高效!
答案 2 :(得分:0)
更好的替代方案可能是使用像Tolo这样的事件总线 - 非常容易使用并在dealloc上自动删除订阅者。你只想写:
SUBSCRIBE(EvenType)
{
//do something with event
}
检查出来。
答案 3 :(得分:0)
您可以尝试使用此ObserversCenter,而不是使用NSNotificationCenter。你可以摆脱令人担忧的滥用NSNotificationCenter。