深入了解 NSNotificationCenter 如何提升应用内部通信效率
在开发 iOS 应用时，保持应用各部分同步是一项挑战。界面中的某个变化可能需要在其他地方触发响应，比如更新标签、刷新表格或执行动画。为了避免视图控制器或模型之间的强耦合，NSNotificationCenter 提供了一种干净的方式，在应用中跨层传递消息。
这种基于通知的通信系统允许对象在不知晓接收者身份的情况下广播信息。对于想要构建模块化、灵活应用的开发者来说，它是一个非常实用的工具。从数据更新到界面变动，NSNotificationCenter 都能平稳高效地协助完成，而不需要大量直接引用。
正确掌握 NSNotificationCenter 的使用方法，可以帮助减少 bug、提升应用架构的清晰度。通过明确的使用模式与真实案例，开发者更容易理解这种消息系统如何融入日常开发中。
NSNotificationCenter 的工作原理基础
NSNotificationCenter 的运作方式类似于一个消息公告板。对象可以发送带有特定名称的通知，而其他注册了该名称的监听者就能接收。它支持跨类、跨层级的通信，从而保持设计的简洁性，并避免循环引用。
当通知被发布时，所有监听该通知的观察者都会收到回调。通知还可以通过 userInfo 字典携带额外数据。这意味着某个视图控制器可以响应模型的变化，即使它并未直接参与变更。
因为观察者可以随时添加或移除，NSNotificationCenter 给予开发者对消息流动时间与方式的掌控，非常适合管理全局事件，比如登录状态变更、键盘显示、主题切换等。
添加观察者以监听通知
若要响应某个通知，对象需注册为观察者。这需要指定通知名称、响应方法（selector），并通常在 viewDidLoad 或初始化阶段添加。
常见示例是视图控制器监听“数据刷新”通知。一旦收到，它可能重新加载内容或调整布局。观察方法应匹配预期的参数签名，并能够安全地读取通知携带的数据。
同时也要注意及时移除观察者，通常在 deinit 或 viewWillDisappear 中执行。若对象销毁后仍注册为观察者，系统可能尝试向已释放的内存发送消息，导致崩溃或不稳定行为。
在应用不同部分发送通知
发送通知非常简单。开发者只需指定通知名称，并可选择附加一个对象或字典作为附加信息。通知会在当前线程立即传递给所有注册的观察者。
这种方式非常适用于后台操作或模型层逻辑触发 UI 更新。例如，从远程服务器拉取数据后，模型可发送一条“数据已更新”的通知，通知界面刷新。
即使是一些小操作，比如用户设置变更或主题切换，也能受益于通知机制。通过广播通知，可以让多个模块响应事件，而无需传递引用或建立委托链。
使用 userInfo 携带通知数据
NSNotificationCenter 的一大优势是可以通过 userInfo 字典附加自定义数据。发送方可传递状态码、用户行为、更新内容等信息。
合理使用这些数据可以显著增强通知机制的实用性。例如下载完成后，userInfo 可以传递文件路径或结果状态，接收方据此直接作出准确响应，无需再次查询。
需要注意的是，开发者应定义清晰的键值（key）与数据类型，以避免运行时错误。观察方法中也应包含数据检查，确保即使缺失某些字段，程序也能稳定运行。
NSNotificationCenter 的常见使用场景
一个典型例子是监听键盘通知。iOS 系统在键盘弹出与收起时，会自动发送通知。开发者可以监听这些通知，调整界面元素的位置，避免被键盘遮挡。
另一个常见场景是登录状态管理。当用户登录或注销时，通过通知广播这一状态变化，其他模块即可及时响应，比如隐藏受保护内容或跳转到登录界面。
在复杂的用户流程中，自定义通知也非常有用。比如用户完成一个多步骤表单后，可以发送一条通知，告知其他页面流程已结束，从而触发 UI 更新或网络请求，无需额外逻辑耦合。
正确线程中处理通知
由于通知会在发送线程上立即传递，因此若要更新界面，需要注意线程切换。UIKit 要求所有 UI 操作必须在主线程中进行。如果通知从后台线程发送，观察者应先跳转到主线程再处理 UI。
可以使用 GCD（如 DispatchQueue.main.async）或在注册通知时指定 OperationQueue.main 来确保回调代码在主线程运行。这能防止界面卡顿甚至崩溃等隐蔽问题。
若通知只涉及数据处理或模型层逻辑，后台线程是可以接受的。但只要涉及界面更新（如标签文字、视图位置等），就必须先切换回主线程。
移除观察者以避免内存问题
遗忘移除观察者是造成 bug 的常见原因之一。若对象已被释放却仍在接收通知，下一次通知发送时系统可能调用空指针，导致崩溃。
因此在 deinit 或清理阶段移除观察者是良好习惯。在 iOS 9 及以后版本，Apple 提供了基于 Block 的通知 API，注册时会返回一个观察者 token，可用于方便地移除。
通过将观察者的生命周期与其在界面中的可见性绑定，可以让系统只向活跃对象发送通知，从而提升内存安全与运行效率。
Block 式观察者：更简洁的替代方案
现代 iOS 中支持使用 Block 注册通知，方法是 addObserver(forName:object:queue:using:)。这种方式让通知处理逻辑内联，避免了单独写一个 selector 方法。
这种方式适用于轻量级通知或快速更新。例如设置界面监听主题变更，只需写一段短 block 就能立即更改颜色，无需创建额外方法。
但注意：返回的观察者 token 仍需由开发者自行管理。若不及时移除，可能造成内存泄漏或通知响应混乱。
选择 NSNotificationCenter 而非其他通信方式的理由
虽然 NSNotificationCenter 非常适合解耦通信，但并非所有场景都适用。对于需要双向通信或结构更清晰的交互，使用委托（delegate）或闭包（closure）可能更合适。而若要广播状态变化或响应全局事件，通知机制既快捷又可靠。
开发者常将 NSNotificationCenter 与其他模式结合使用：用通知传递状态更新，用委托处理控制器间的直接回调。这样可以根据不同层级选择最合适的工具，使应用更易扩展、逻辑更清晰。NSNotificationCenter 至今仍是 UIKit 开发中常见且值得信赖的解决方案之一，适用于多种典型通信场景。