この投稿へのコメントでNSNotificationsのオーバーヘッドに気づきました、ユーザーJustSidは言います
アプリが実行ループサイクルごとに30以上を送信しない場合、オーバーヘッドは目立たなくなります
現在の実行ループサイクルで送信されたNSNotificationの数を追跡し、事前に構成可能な特定の数を超えている場合に警告する小さなヘルパークラスを作成したいと思います。すべての通知に登録できることはわかっていますが（名前とオブジェクトにnilを渡す）、送信元の実行ループサイクルを追跡するにはどうすればよいですか？
NSNotificationCenter に、通知オブザーバーが追加されたときに内部整数をインクリメントする (その結果、削除されたときにそれをデクリメントする) カテゴリを設定するのは簡単ですが、次のことを自問する必要があります。
それを任意の整数 (例えば 30 など) と見なす場合、現在のデバイスよりもメモリとプロセッサの制約が多いデバイスでテストするとどうなるでしょうか? 30 人のオブザーバーと通知を簡単に処理できるデバイスでテストするとどうなるでしょうか (完全に無駄になります)。一般的なルールをコーディングすることはできますが、通知がアプリケーションの応答時間に与える影響をすべてのケースで測定することは不可能です。
もう1つの可能性は、オブザーバーの量が特定のシステム機能をクロールするときに、バックグラウンドプロセスが通知スタックにクエリを実行することです（または、上記のように内部的に測定するだけです）。もちろん、これがあまりにも多くの作業であるという事実を無視すると、最初に修正しようとしたのと同じくらい多くのメモリを使用し、パフォーマンスを奪うサブシステムを設計することになります!
TL;DR 通知の代わりに使用できるパターンや構造は他にもたくさんあります。