iOS 之后Apple 为 NSNotificationCenter 的 target‑action 模式引入了 zeroing weak reference。当 observer 对象被释放后程序自动将内部的 weak reference 置为 nil不再向其投递通知，也不会产生野指针 crash。

Apple 文档对此也有明确说明：

这条规则接受度很高，许多团队所以在代码规范中不再严格要求管理 observer 生命周期。只是"不会 crash" 并不等于 "没有性能影响"。这里通过一个真实的线上卡死案例，探讨 NotificationCenter observer 管理不当可能带来的隐性性能问题。

一个线上卡死案例

在一次线上卡死监控中，发现一类卡死的比例明显上升。主线程被卡住 **5 秒**。CPU 占用 **30%**，处于 running 状态。从堆栈顶部如下来看，

_weak_unregister_no_lock_objc_moveWeak__CFXNotificationRegistrarAddObserverSomeTimeViewModel.componentMount
← 调用 NotificationCenter.default.addObserver

卡死发生在一个 ViewModel 的初始化阶段——调用 addObserver 注册通知时。其实，注册一个通知 observer 本身应该是非常轻量的操作。为什么会导致 **5 秒** 的卡死？

经过排查，这个问题的根因并不是“忘记 removeObserver 导致 dead entries 累积”。 而是一个更容易被忽视的问题：同一个通知名下积累了过多的 live observers。

NotificationCenter 的内部机制

要理解这个问题，需要了解 NSNotificationCenter 在 iOS + 中的内部实现。

注册表结构

当调用 addObserver:selector:name:object: 时NotificationCenter 在内部维护一个注册表。按通知名称索引，存储所有注册信息。每条注册信息大致包括：

• 一个指向 observer 的 weak reference
• selector
• notification name
• object filter

这些信息存储在 CoreFoundation 内部的数据结构中。

扩容与 weak reference 迁移

和 HashMap 类似。NotificationCenter 的内部存储在容量不足时会扩容——分配更大的存储空间，将现有条目迁移到新位置。

对于包含 weak reference 的条目，迁移过程需要通过 ObjC runtime 的 objc_moveWeak 将 weak reference 从旧内存地址搬迁到新地址。说到这个操作涉及，

1. : 从 runtime 的 side table 中注销旧地址
2. : 在 side table 中注册新地址

单次操作很快。但如果某个通知名下积累了大量条目，扩容时需要逐个迁移所有 live entries 的 weak reference，累积耗时就可能达到秒级。

两种问题模式

NotificationCenter 的 entries 膨胀来自两个方面它们可以独立存在也可以叠加：

模式一：dead entries 累积

当 observer 被释放时其 weak reference 自动置 nil。但注册条目本身不会被移除. 对于频繁创建和销毁的对象，如果不在 deinit 中 removeObserver，NotificationCenter 会持续累积 dead entries。话说回来，

模式二：live entries 过多

案例分析

.tabBarDidChangeSelectedIndex` 在整个 App 中有 30+ 个文件注册了 observer。涵盖 Feed、社交、个人资料页、IM、Notice、电商等几乎所有主要模块。

• .tabBarDidChangeSelectedIndex
200 live observers just from this module.

被忽视的关键点

Even when every observer correctly calls removeObserver in deinit,sheer number of *live* observers can still cripple performance.

---