NSNotificationCenter 使用姿勢詳解

發表於2016-09-28

最近在做平板的過程中,發現了一些很不規範的程式碼。偶然修復支付bug的時候,看到其他專案程式碼,使用通知的地方沒有移除,我以為我這個模組的支付閃退是因為他通知沒有移除的緣故。而在debug和看了具體的程式碼的時候才發現和這裡沒有關係。在我印象中,曾經因為沒有移除通知而遇到閃退的問題。所以讓我很意外,於是寫了個demo研究了下,同時來講下NSNotificationCenter使用的正確姿勢。

NSNotificationCenter

對於這個沒必要多說,就是一個訊息通知機制,類似廣播。觀察者只需要向訊息中心註冊感興趣的東西,當有地方發出這個訊息的時候,通知中心會傳送給註冊這個訊息的物件。這樣也起到了多個物件之間解耦的作用。蘋果給我們封裝了這個NSNotificationCenter,讓我們可以很方便的進行通知的註冊和移除。然而,有些人的姿勢還是有點小問題的,下面就看看正確的姿勢吧!

正確姿勢之remove

只要往NSNotificationCenter註冊了,就必須有remove的存在,這點是大家共識的。但是大家在使用的時候發現,在UIViewControlleraddObserver後沒有移除,好像也沒有掛!我想很多人可能和我有一樣的疑問,是不是因為使用了ARC?在你物件銷燬的時候自動置為nil了呢?或者蘋果在實現這個類的時候用了什麼神奇的方式呢?下面我們就一步步來探究下。

首先,向NSNotificationCenteraddObserver後,並沒有對這個物件進行引用計數加1操作,所以它只是儲存了地址。為了驗證這個操作,我們來做下程式碼的測試。

一個測試類,用來註冊通知:

這個類很簡單,就是在初始化的時候,給他註冊一個通知。但是在銷燬的時候不進行remove操作。我們在VC中建立這個物件後,然後銷燬,最後傳送這個通知:

在進入這個vc後,我們發現掛了。。而列印出的資訊是:

我們可以發現,向野指標物件傳送了訊息,所以掛掉了。從這點來看,蘋果實現也基本差不多是這樣的,只儲存了個物件的地址,並沒有在銷燬的時候置為nil

這點就可以證明,addObserver後,必須要有remove操作。

現在我們在UIViewController中註冊通知,不移除,看看會不會掛掉。

首先用navigationController進入到這個頁面,然後pop出去。最後點選傳送通知的按鈕事件:

無論你怎麼點選這個按鈕,他就是不掛!這下,是不是很鬱悶了?我們可以找找看,你程式碼裡面沒有remove操作,但是NSNotificationCenter那邊已經移除了,不然肯定會出現上面野指標的問題。看來看去,也只能說明是UIViewController自己銷燬的時候幫我們暗地裡移除了。

那我們如何證明呢?由於我們看不到原始碼,所以也不知道有沒有呼叫。這個時候,我們可以從這個通知中心下手!!!怎麼下手呢?我只要證明UIViewController在銷燬的時候呼叫了remove方法,就可以證明我們的猜想是對的了!這個時候,就需要用到我們強大的類別這個特性了。我們為NSNotificationCenter新增個類別,重寫他的- (void)removeObserver:(id)observer方法:

這樣在我們VC中匯入這個類別,然後pop出來,看看發生了什麼!

怎麼樣?是不是可以證明系統的UIViewController在銷燬的時候呼叫了這個方法。(不建議大家在開發的時候用類別的方式覆蓋原有的方法,由於類別方法具有更高的優先權,所以有可能影響到其他地方。這裡只是除錯用)。

以上也提醒我們,在你不是銷燬的時候,千萬不要直接呼叫[[NSNotificationCenter defaultCenter] removeObserver:self]; 這個方法,因為你有可能移除了系統註冊的通知

正確姿勢之注意重複addObserver

在我們開發中,我們經常可以看到這樣的程式碼:

就是在頁面出現的時候註冊通知,頁面消失時移除通知。你這邊可要注意了,一定要成雙成對出現,如果你只在viewWillAppear 中 addObserver沒有在viewWillDisappear 中 removeObserver那麼當訊息發生的時候,你的方法會被呼叫多次,這點必須牢記在心。

正確姿勢之多執行緒通知

首先看下蘋果的官方說明:

Regular notification centers deliver notifications on the thread in which the notification was posted. Distributed notification centers deliver notifications on the main thread. At times, you may require notifications to be delivered on a particular thread that is determined by you instead of the notification center. For example, if an object running in a background thread is listening for notifications from the user interface, such as a window closing, you would like to receive the notifications in the background thread instead of the main thread. In these cases, you must capture the notifications as they are delivered on the default thread and redirect them to the appropriate thread.

意思很簡單,NSNotificationCenter訊息的接受執行緒是基於傳送訊息的執行緒的。也就是同步的,因此,有時候,你傳送的訊息可能不在主執行緒,而大家都知道操作UI必須在主執行緒,不然會出現不響應的情況。所以,在你收到訊息通知的時候,注意選擇你要執行的執行緒。下面看個示例程式碼

總結

通知平常使用的知識點差不多就這麼多。希望對大家有幫助。最後,程式碼一定要養成良好的習慣,該移除的還是要移除。

相關文章