最近在做平板的過程中，發(fā)現(xiàn)了一些很不規(guī)范的代碼。偶然修復(fù)支付bug的時候耘柱，看到其他項目代碼，使用通知的地方?jīng)]有移除棍现，我以為我這個模塊的支付閃退是因為他通知沒有移除的緣故调煎。而在debug和看了具體的代碼的時候才發(fā)現(xiàn)和這里沒有關(guān)系。在我印象中己肮，曾經(jīng)因為沒有移除通知而遇到閃退的問題士袄。所以讓我很意外，于是寫了個demo研究了下谎僻，同時來講下NSNotificationCenter使用的正確姿勢娄柳。
NSNotificationCenter
對于這個沒必要多說，就是一個消息通知機制艘绍，類似廣播西土。觀察者只需要向消息中心注冊感興趣的東西，當有地方發(fā)出這個消息的時候鞍盗，通知中心會發(fā)送給注冊這個消息的對象需了。這樣也起到了多個對象之間解耦的作用。蘋果給我們封裝了這個NSNotificationCenter般甲，讓我們可以很方便的進行通知的注冊和移除肋乍。然而，有些人的姿勢還是有點小問題的敷存，下面就看看正確的姿勢吧墓造！
正確姿勢之remove
只要往NSNotificationCenter注冊了，就必須有remove的存在锚烦，這點是大家共識的觅闽。但是大家在使用的時候發(fā)現(xiàn)，在UIViewController?中addObserver后沒有移除涮俄，好像也沒有掛蛉拙！我想很多人可能和我有一樣的疑問，是不是因為使用了ARC彻亲？在你對象銷毀的時候自動置為nil了呢孕锄？或者蘋果在實現(xiàn)這個類的時候用了什么神奇的方式呢吮廉？下面我們就一步步來探究下。
首先畸肆，向NSNotificationCenter中addObserver后宦芦，并沒有對這個對象進行引用計數(shù)加1操作，所以它只是保存了地址轴脐。為了驗證這個操作调卑，我們來做下代碼的測試。
一個測試類大咱，用來注冊通知：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21@implementation?MRCObject
-?(id)init
{
if(self?=?[superinit])?{
[[NSNotificationCenter?defaultCenter]?addObserver:self?selector:@selector(test)?name:@"test"object:nil];
}
returnself;
}
-?(void)test
{
NSLog(@"=================");
}
-?(void)dealloc
{
[superdealloc];
}
@end
這個類很簡單令野，就是在初始化的時候，給他注冊一個通知徽级。但是在銷毀的時候不進行remove操作气破。我們在VC中創(chuàng)建這個對象后，然后銷毀餐抢，最后發(fā)送這個通知：
1
2
3
4
5
6
7
8-?(void)viewDidLoad?{
[superviewDidLoad];
MRCObject?*obj?=?[[MRCObject?alloc]?init];
[obj?release];
[[NSNotificationCenter?defaultCenter]?postNotificationName:@"test"object:nil];
}
在進入這個vc后现使，我們發(fā)現(xiàn)掛了。旷痕。而打印出的信息是：
1
2015-01-19?22:49:06.655?測試[1158:286268]?***?-[MRCObject?test]:?message?sent?to?deallocated?instance?0x17000e5b0
我們可以發(fā)現(xiàn)碳锈，向野指針對象發(fā)送了消息，所以掛掉了欺抗。從這點來看售碳，蘋果實現(xiàn)也基本差不多是這樣的，只保存了個對象的地址绞呈，并沒有在銷毀的時候置為nil贸人。
這點就可以證明，addObserver后佃声，必須要有remove操作艺智。
現(xiàn)在我們在UIViewController中注冊通知，不移除圾亏，看看會不會掛掉十拣。
1
2
3
4-?(void)viewDidLoad?{
[superviewDidLoad];
[[NSNotificationCenter?defaultCenter]?addObserver:self?selector:@selector(test)?name:@"test"object:nil];
}
首先用navigationController進入到這個頁面，然后pop出去志鹃。最后點擊發(fā)送通知的按鈕事件：
1
2
3
4-?(void)didButtonClicked:(id)sender
{
[[NSNotificationCenter?defaultCenter]?postNotificationName:@"test"object:nil];
}
無論你怎么點擊這個按鈕夭问，他就是不掛！這下曹铃，是不是很郁悶了缰趋？我們可以找找看，你代碼里面沒有remove操作，但是NSNotificationCenter那邊已經(jīng)移除了埠胖，不然肯定會出現(xiàn)上面野指針的問題〈就妫看來看去直撤，也只能說明是UIViewController自己銷毀的時候幫我們暗地里移除了。
那我們?nèi)绾巫C明呢蜕着？由于我們看不到源碼谋竖，所以也不知道有沒有調(diào)用。這個時候承匣，我們可以從這個通知中心下手１统恕！韧骗！怎么下手呢嘉抒？我只要證明UIViewController在銷毀的時候調(diào)用了remove方法，就可以證明我們的猜想是對的了袍暴！這個時候些侍，就需要用到我們強大的類別這個特性了。我們?yōu)镹SNotificationCenter添加個類別政模，重寫他的- (void)removeObserver:(id)observer方法：
1
2
3
4-?(void)removeObserver:(id)observer
{
NSLog(@"====%@?remove===",?[observer?class]);
}
這樣在我們VC中導(dǎo)入這個類別岗宣，然后pop出來，看看發(fā)生了什么淋样！
1
2015-01-19?22:59:00.580?測試[1181:288728]?====TestViewController?remove===
怎么樣耗式？是不是可以證明系統(tǒng)的UIViewController在銷毀的時候調(diào)用了這個方法。（不建議大家在開發(fā)的時候用類別的方式覆蓋原有的方法趁猴，由于類別方法具有更高的優(yōu)先權(quán)刊咳，所以有可能影響到其他地方。這里只是調(diào)試用）儡司。
以上也提醒我們芦缰，在你不是銷毀的時候，千萬不要直接調(diào)用[[NSNotificationCenter defaultCenter] removeObserver:self];?這個方法枫慷，因為你有可能移除了系統(tǒng)注冊的通知让蕾。
正確姿勢之注意重復(fù)addObserver
在我們開發(fā)中，我們經(jīng)郴蛱可以看到這樣的代碼：
1
2
3
4
5
6
7
8
9
10
11-?(void)viewWillAppear:(BOOL)animated
{
[superviewWillAppear:animated];
[[NSNotificationCenter?defaultCenter]?addObserver:self?selector:@selector(test)?name:@"test"object:nil];
}
-?(void)viewWillDisappear:(BOOL)animated
{
[superviewWillDisappear:animated];
[[NSNotificationCenter?defaultCenter]?removeObserver:self?name:@"test"object:nil];
}
就是在頁面出現(xiàn)的時候注冊通知探孝，頁面消失時移除通知。你這邊可要注意了誉裆，一定要成雙成對出現(xiàn)顿颅，如果你只在viewWillAppear 中 addObserver沒有在viewWillDisappear 中 removeObserver那么當消息發(fā)生的時候，你的方法會被調(diào)用多次足丢，這點必須牢記在心粱腻。
正確姿勢之多線程通知
首先看下蘋果的官方說明：
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消息的接受線程是基于發(fā)送消息的線程的。也就是同步的绍些，因此捞慌，有時候，你發(fā)送的消息可能不在主線程柬批，而大家都知道操作UI必須在主線程啸澡，不然會出現(xiàn)不響應(yīng)的情況。所以氮帐，在你收到消息通知的時候嗅虏，注意選擇你要執(zhí)行的線程。下面看個示例代碼
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22//接受消息通知的回調(diào)
-?(void)test
{
if([[NSThread?currentThread]?isMainThread])?{
NSLog(@"main");
}else{
NSLog(@"not?main");
}
dispatch_async(dispatch_get_main_queue(),?^{
//do?your?UI
});
}
//發(fā)送消息的線程
-?(void)sendNotification
{
dispatch_queue_t?defaultQueue?=?dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,?0);
dispatch_async(defaultQueue,?^{
[[NSNotificationCenter?defaultCenter]?postNotificationName:@"test"object:nil];
});
}
