1、通知的移除

（1）针对ViewController来说：不管是iOS9之前，还是iOS9之后，系统在调用dealloc方法时，会自动调用[[NSNotificationCenter defaultCenter]removeObserver:self]，所以使用addObserver添加监听者的话无需手动移除通知。

（2）针对NSObject来说，iOS9之前系统在调用dealloc方法时，不会自动调用[[NSNotificationCenter defaultCenter]removeObserver:self]，所以需要手动移除，不然会崩溃。iOS9之后，增加了在调用dealloc方法时，自动调用[[NSNotificationCenter defaultCenter]removeObserver:self]的方法，所以添加通知后，无需手动移除通知。

注意：在viewWillAppear方法里面注册通知，需要在viewWillDisappear方法里移除通知，不然页面多次调用viewWillAppear会导致通知多次回调

1. 为什么 iOS9之前需要手动移除通知了呢？

在iOS9之前，观察者注册时，通知中心并不会对观察者对象做 retain操作，而是对观察者对象进行unsafe_unretained（不安全） 引用。导致观察者对象被释放后，不安全引并不会自动被置为nil,从而变成野指针，对野指针发送消息导致程序崩溃。

2. 什么是unsafe_unretained引用？

不安全引用（unsafe reference）和弱引用 (weak reference) 类似，它并不会让被引用的对象保持存活，但是和弱引用不同的是，当被引用的对象释放的时，不安全引用并不会自动被置为 nil，这就意味着它变成了野指针，而对野指针发送消息会导致程序崩溃。

3. 为什么要进行unsafe_unretained引用？

因为 Cocoa 和 Cocoa Touch 中的一些类仍然还没有支持 weak 引用。所以，当我们想对这些类使用 weak 引用的时候，只能用unsafe_unretained来替代。

4. 为什么 iOS9之后不需要手动移除通知了呢？

从 iOS 9 开始通知中心会对观察者进行 weak 引用，所以不需要在观察者对象释放之前从通知中心移除

但是使用- (id <NSObject>)addObserverForName:(nullable NSNotificationName)name object:(nullable id)obj queue:(nullable NSOperationQueue *)queue usingBlock:(void (^)(NSNotification *note))block 这个方法添加的通知，仍需手动移除通知,因为通知中心对它的持有是强引用

添加通知

_observe =  [[NSNotificationCenter defaultCenter]addObserverForName:@"noti3" object:nil queue:nil usingBlock:^(NSNotification * _Nonnull note) {
        NSLog(@"%s",__func__);
    }];

参数queue：接收到通知的回调在哪个线程中调用，如果传mainQueue则通知在主线程回调，否则在子线程回调

移除通知

[[NSNotificationCenter defaultCenter] removeObserver:_observe];

这个block里面，对self进行了强引用，所以在block使用self时，要进行弱引用，避免循环引用引发的内存泄漏。

2、通知的同步异步

1、使用(void)addObserver:(id)observer selector:(SEL)aSelector name:(nullable NSNotificationName)aName object:(nullable id)anObject方式添加通知，
（1）默认通知在哪个线程发出，就在哪个线程接收
（2）默认通知的发送和接收和同步的

poster发出一个通知后，通知事件之后的代码被堵塞，通知中心会一直等待所有的observer（监听者）都收到，并且处理完通知才会返回到poster

当然为了防止阻塞，可以将通知改成异步

方式1: 将observer收到通知后的方法，放在子线程中执行，这种方式接收到通知还是同步，但是接收到通知后的处理改成异步

- (void)receiveNoti2:(NSNotification *)noti{
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        NSLog(@"%@",noti.object);
        NSLog(@"%@",[NSThread currentThread]);
        
    });
}

方式2、通过- (void)enqueueNotification:(NSNotification *)notification postingStyle:(NSPostingStyle)postingStyle;和- (void)enqueueNotification:(NSNotification *)notification postingStyle:(NSPostingStyle)postingStyle coalesceMask:(NSNotificationCoalescing)coalesceMask forModes:(nullable NSArray<NSRunLoopMode> *)modes发送通知，不是让通知回调在异步执行，只是让通知等待到runloop空闲的时候再去执行

发送通知方式如下

 NSNotification *noti = [NSNotification notificationWithName:@"noti2" object:nil];
    [[NSNotificationQueue defaultQueue] enqueueNotification:noti postingStyle:NSPostWhenIdle coalesceMask:NSNotificationNoCoalescing forModes:@[NSDefaultRunLoopMode]];
    
    NSLog(@"sss=========%@",[NSThread currentThread]);

接收到通知后

- (void)receiveNoti2:(NSNotification *)noti{
    NSLog(@"%s",__func__);
    NSLog(@"%@",[NSThread currentThread]);
    sleep(3);
    NSLog(@"nnnnnn ===== %@",[NSThread currentThread]);
}

打印顺序图

由图可见，发送通知后，先完成poster后面的事情，再完成通知的发送和observer接收到通知后的处理，整个流程都是在主线程中进行，并没有切换线程，只是让通知等待到runloop空闲的时候再去执行

NSPostingStyle

1. NSPostWhenIdle：runloop空闲的时候回调通知方法(runloop 进入kCFRunLoopBeforeWaiting)
2. NSPostASAP：runloop能够调用的时候就回调通知方法(runloop 进入kCFRunLoopBeforeTimers)
3. NSPostNow：runloop立即回调通知方法（和默认通知方式一样）

详情查看iOS 通知的多线程处理 & 与Runloop的关系

coalesceMask

1. NSNotificationNoCoalescing = 0, // 不合成
2. NSNotificationCoalescingOnName = 1, // 根据NSNotification的name字段进行合成
3. NSNotificationCoalescingOnSender = 2 // 根据NSNotification的object字段进行合成

详情查看 NSNotification，看完你就都懂了

2、使用- (id <NSObject>)addObserverForName:(nullable NSNotificationName)name object:(nullable id)obj queue:(nullable NSOperationQueue *)queue usingBlock:(void (^)(NSNotification *note))block这个方法添加的通知,通知回调的block在哪个线程执行只和queue参数有关，无论发送通知是在主线程或子线程发送的，都不会影响。

参考文章

1. iOS 通知 观察者移除注意点
2. iOS 通知的多线程处理 & 与Runloop的关系
3. NSNotification，看完你就都懂了