很明显，推送通知并不总是可靠的，正如文档中所述。
如果我错了请纠正我，这只是因为有人可能长时间没有互联网，通知可能会过期，或被替换，甚至因为某些宇宙原因丢失。
我不介意。
但是作为一个初级程序员，我使用了很多本地通知，不是为了显示，而只是为了在某些进程完成时调用不同的方法。
这里有一个简单的例子，当应用程序启动时，我有一个数据更新过程，比如，消息和其他东西。当更新完成时(大约3秒后)，我将发送一个通知给所有控制器，以便它们相应地更新自己的UI。如果我在主屏幕上，我会显示这些红色小徽章，如果我在对话中，我会在tableview中添加消息，等等
而且，作为一名初级开发人员，我有机会与一位不赞成这种风格的高级开发人员一起工作。他说它不可靠我应该使用委托回调和完成处理器。考虑到应用程序的构建方式，我发现很难做到这一点。我的系统实际上是一个单行程序，从来没有失败过，而他的系统需要在每个单独的类中实现大量不同的方法。这看起来既多余又混乱。
我终于得到了我想要的:通知在本地是可靠的吗，我说的是这个:
[[NSNotificationCenter defaultCenter] postNotificationName:NOTIF_SOMETHING_SOMETHING object:self];
与addObserver:相对应。
可悲的是，这是一个基于意见的问题，因为它是关于标准和良好实践的，但我觉得它不够宽泛，不足以违反规则，因为我真的真的觉得有人会带来一个技术上的理由，为什么这个或那个应该/不应该这样做，或者澄清什么应该在何时何地使用。
无论如何，如果需要的话，请让我澄清一下，我对所有的回复都很感兴趣，我很期待。
在iOS世界中有不同类型的通知，每种都有不同的目的，不应该相互混淆。
-
推送通知:这些是唯一不可靠的，因为它们依赖于网络连接和苹果的推送系统……
-
UILocalNotification:这些都是在特定事件时通知用户的方法(你可以将其与推送通知相比，它不是从服务器发送的，而是由你自己的应用本地触发的) -
NSNotification:这些纯粹是技术上的，基本上他们提供了一个广播机制，可以用来使您的应用程序的某些部分之间的通信。我明白，乍一看，它似乎很方便使用NSNotification经常在你的代码，因为它是一个简单而直接的方式，让2(或更多)类相互通信。但是，您的高级开发人员建议您不要过度使用此机制是正确的。主要是因为它会导致混乱的编码结构，并且当项目变大时不能很好地扩展。另一个大问题是它使调试非常困难。另一方面，当使用委托或完成块时，您有机会以合理的方式构建代码，以确保您封装了应该封装的功能，使代码更具可读性，并且更适合大规模使用。
不要将NSNotificationCenter通知与本地(或远程)推送通知混淆。他们是完全不同的。
NSNotificationCenter的通知是可靠的。这些都不使用互联网。它们是在运行中的应用程序中进行的简单方法调用。它们与使用其他形式(如委托)一样安全。
使用NSNotificationCenter是伟大的，当你只是想广播到应用程序，发生了什么事，你不关心谁知道或有多少听众有事件。
典型的委托模式通常只在事件最多有一个侦听器时才起作用。