最近在做平板的過程中，發(fā)現(xiàn)了一些很不規(guī)范的代碼。偶然修復(fù)支付bug的時(shí)候，看到其他項(xiàng)目代碼，使用通知的地方?jīng)]有移除，我以為我這個(gè)模塊的支付閃退是因?yàn)樗ㄖ獩]有移除的緣故。而在debug和看了具體的代碼的時(shí)候才發(fā)現(xiàn)和這里沒有關(guān)系。在我印象中，曾經(jīng)因?yàn)闆]有移除通知而遇到閃退的問題。所以讓我很意外，于是寫了個(gè)demo研究了下，同時(shí)來講下NSNotificationCenter使用的正確姿勢。

NSNotificationCenter

對(duì)于這個(gè)沒必要多說，就是一個(gè)消息通知機(jī)制，類似廣播。觀察者只需要向消息中心注冊感興趣的東西，當(dāng)有地方發(fā)出這個(gè)消息的時(shí)候，通知中心會(huì)發(fā)送給注冊這個(gè)消息的對(duì)象。這樣也起到了多個(gè)對(duì)象之間解耦的作用。蘋果給我們封裝了這個(gè)NSNotificationCenter，讓我們可以很方便的進(jìn)行通知的注冊和移除。然而，有些人的姿勢還是有點(diǎn)小問題的，下面就看看正確的姿勢吧！

正確姿勢之remove

只要往NSNotificationCenter注冊了，就必須有remove的存在，這點(diǎn)是大家共識(shí)的。但是大家在使用的時(shí)候發(fā)現(xiàn)，在UIViewController 中addObserver后沒有移除，好像也沒有掛！我想很多人可能和我有一樣的疑問，是不是因?yàn)槭褂昧薃RC？在你對(duì)象銷毀的時(shí)候自動(dòng)置為nil了呢？或者蘋果在實(shí)現(xiàn)這個(gè)類的時(shí)候用了什么神奇的方式呢？下面我們就一步步來探究下。

首先，向NSNotificationCenter中addObserver后，并沒有對(duì)這個(gè)對(duì)象進(jìn)行引用計(jì)數(shù)加1操作，所以它只是保存了地址。為了驗(yàn)證這個(gè)操作，我們來做下代碼的測試。

一個(gè)測試類，用來注冊通知：

@implementation MRCObject

- (id)init
{
    if (self = [super init]) {
        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(test) name:@"test" object:nil];
    }
    return self;
}

- (void)test
{
    NSLog(@"=================");
}

- (void)dealloc
{
    [super dealloc];
}

@end

這個(gè)類很簡單，就是在初始化的時(shí)候，給他注冊一個(gè)通知。但是在銷毀的時(shí)候不進(jìn)行remove操作。我們在VC中創(chuàng)建這個(gè)對(duì)象后，然后銷毀，最后發(fā)送這個(gè)通知：

- (void)viewDidLoad {
    [super viewDidLoad];

    MRCObject *obj = [[MRCObject alloc] init];
    [obj release];

    [[NSNotificationCenter defaultCenter] postNotificationName:@"test" object:nil];
}

在進(jìn)入這個(gè)vc后，我們發(fā)現(xiàn)掛了。。而打印出的信息是：

2015-01-19 22:49:06.655 測試[1158:286268] *** -[MRCObject test]: message sent to deallocated instance 0x17000e5b0

我們可以發(fā)現(xiàn)，向野指針對(duì)象發(fā)送了消息，所以掛掉了。從這點(diǎn)來看，蘋果實(shí)現(xiàn)也基本差不多是這樣的，只保存了個(gè)對(duì)象的地址，并沒有在銷毀的時(shí)候置為nil。

這點(diǎn)就可以證明，addObserver后，必須要有remove操作。

現(xiàn)在我們在UIViewController中注冊通知，不移除，看看會(huì)不會(huì)掛掉。

- (void)viewDidLoad {
    [super viewDidLoad];
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(test) name:@"test" object:nil];
}

首先用navigationController進(jìn)入到這個(gè)頁面，然后pop出去。最后點(diǎn)擊發(fā)送通知的按鈕事件：

- (void)didButtonClicked:(id)sender
{
    [[NSNotificationCenter defaultCenter] postNotificationName:@"test" object:nil];
}

無論你怎么點(diǎn)擊這個(gè)按鈕，他就是不掛！這下，是不是很郁悶了？我們可以找找看，你代碼里面沒有remove操作，但是NSNotificationCenter那邊已經(jīng)移除了，不然肯定會(huì)出現(xiàn)上面野指針的問題?？磥砜慈ィ仓荒苷f明是UIViewController自己銷毀的時(shí)候幫我們暗地里移除了。

那我們?nèi)绾巫C明呢？由于我們看不到源碼，所以也不知道有沒有調(diào)用。這個(gè)時(shí)候，我們可以從這個(gè)通知中心下手！?。≡趺聪率帜?？我只要證明UIViewController在銷毀的時(shí)候調(diào)用了remove方法，就可以證明我們的猜想是對(duì)的了！這個(gè)時(shí)候，就需要用到我們強(qiáng)大的類別這個(gè)特性了。我們?yōu)?code>NSNotificationCenter添加個(gè)類別，重寫他的- (void)removeObserver:(id)observer方法：

- (void)removeObserver:(id)observer
{
    NSLog(@"====%@ remove===", [observer class]);
}

這樣在我們VC中導(dǎo)入這個(gè)類別，然后pop出來，看看發(fā)生了什么！

2015-01-19 22:59:00.580 測試[1181:288728] ====TestViewController remove===

怎么樣？是不是可以證明系統(tǒng)的UIViewController在銷毀的時(shí)候調(diào)用了這個(gè)方法。（不建議大家在開發(fā)的時(shí)候用類別的方式覆蓋原有的方法，由于類別方法具有更高的優(yōu)先權(quán)，所以有可能影響到其他地方。這里只是調(diào)試用）。

以上也提醒我們，在你不是銷毀的時(shí)候，千萬不要直接調(diào)用[[NSNotificationCenter defaultCenter] removeObserver:self]; 這個(gè)方法，因?yàn)槟阌锌赡?strong>移除了系統(tǒng)注冊的通知。

正確姿勢之注意重復(fù)addObserver

在我們開發(fā)中，我們經(jīng)?？梢钥吹竭@樣的代碼：

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(test) name:@"test" object:nil];
}

- (void)viewWillDisappear:(BOOL)animated
{
    [super viewWillDisappear:animated];
    [[NSNotificationCenter defaultCenter] removeObserver:self name:@"test" object:nil];
}

就是在頁面出現(xiàn)的時(shí)候注冊通知，頁面消失時(shí)移除通知。你這邊可要注意了，一定要成雙成對(duì)出現(xiàn)，如果你只在viewWillAppear 中 addObserver沒有在viewWillDisappear 中 removeObserver那么當(dāng)消息發(fā)生的時(shí)候，你的方法會(huì)被調(diào)用多次，這點(diǎn)必須牢記在心。

正確姿勢之多線程通知

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

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ā)送消息的線程的。也就是同步的，因此，有時(shí)候，你發(fā)送的消息可能不在主線程，而大家都知道操作UI必須在主線程，不然會(huì)出現(xiàn)不響應(yīng)的情況。所以，在你收到消息通知的時(shí)候，注意選擇你要執(zhí)行的線程。下面看個(gè)示例代碼

//接受消息通知的回調(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];
    });
}

總結(jié)

通知平常使用的知識(shí)點(diǎn)差不多就這么多。希望對(duì)大家有幫助。最后，代碼一定要養(yǎng)成良好的習(xí)慣，該移除的還是要移除。