監測NSNotifications

我在這個帖子上Overhead of NSNotifications評論注意到，用戶JustSid說監測NSNotifications

的開銷不會明顯，如果應用程序不會發送30+每輪循環週期

我想寫一個小助手類來跟蹤在當前運行循環週期中發送了多少個NSNotifications，並提醒我它是否超過了某個可預先配置的數字。我知道我可以註冊所有通知（將名稱和對象傳遞給nil），但是如何跟蹤它們從哪個運行循環開始？

2013-03-04 Cody C

恕我直言，這種做法似乎是可疑的。我沒有看到使用NSNotificationCenter的開銷比直接在對象之間發送消息更高的開銷。任何性能問題都將針對通知的處理（與發送）相關。如果有大量對象觀察通知和/或執行線程阻塞任務，這些任務顯然會對應用程序性能產生影響。這就是我將時間和精力集中的地方。 @ JustSid的評論是任意的和推測性的。 – XJones 2013-03-04 23:40:27

當添加通知觀察者時（在移除時減少它），在NSNotificationCenter上有一個類別可以增加某些內部整數，但您必須問自己：多少太多？

如果您認爲它是某個任意整數（例如，舉例來說，例如30），那麼當您在具有比現在更多的內存和處理器限制的設備上測試它時會發生什麼？如果您在可輕鬆處理30名觀察員和浮動通知的設備上進行測試，會發生什麼？（這將會是一種完全浪費）？儘管可以對通用規則進行編碼，但在任何情況下都不可能評估通知對應用程序響應時間的影響。

當觀察者將某些系統函數進行爬網時，另一種可能性是後臺進程查詢通知堆棧（或者以某種方式在上面內部對其進行測量）。當然，如果忽略這樣一個事實，那就是太多的工作，你會設計一個子系統，這個子系統可能會利用盡可能多的內存和竊取，儘可能遠離性能，正如你試圖用它來解決這個問題一樣！

TL; DR有很多其他的模式和結構可以用來代替通知，那麼爲什麼你要滿足NSNotification的需求呢？

來源

2013-03-04 21:20:21 CodaFi

這是我在調試時只計劃運行的東西，我更擔心發送通知的數量，而不是我的情況下觀察者的數量。我只有少數觀察員。我有一個類監視主線程，如果它沒有響應一個可配置的時間段，NSLogs「主線程無響應」。我正在考慮一個類似的工具。通知的數量是非常隨意的，但是如果我每次運行循環發送20個通知並且我做出更改並且突然發送每個運行循環的500個通知，那就太好了。 – 2013-03-04 21:47:39

然後就使用那個類。似乎足以應付阻止通知。或者，如果你願意，可以重新編寫NSNotificationCenter。這真的不應該那麼難。 – CodaFi 2013-03-04 22:12:45

我的答案是：A）你告訴我你有一個工具可以跟蹤線程阻塞，B）這樣的工具太笨重而無法使用。你不僅需要跟蹤主線程，而且還需要篩選* NSNotification的阻塞循環的方法。至少，它的佈局過於笨拙（調試工具通常與應用程序本身分離，所以它們不會干擾應用程序的執行並報告錯誤的數據）。爲了「更好」的答案，重新說明或回答一個問題。 – CodaFi 2013-03-04 22:33:59

監測NSNotifications

回答

相關問題