通知NSNotificationCenter详解(二)

版本记录

版本号 时间
V1.0 2017.07.17

前言

前面说了一下通知的一些基本问题,这里要说明的在多线程中通知的安全问题。感兴趣的可以看我前面的几篇文章。
1.通知NSNotificationCenter详解(一)
下面我们说的就是通知的多线程安全问题

问题讨论

NSNotificationCenter虽然是线程安全的,这是官方文档给的,但是实际使用时候真的如此吗?

通知的多线程问题其实在官方技术文档里面已经写的很清楚了。

In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself.

它的意思就是

  • 在多线程中,Notification在哪个线程中post,就在哪个线程中被转发,而不一定是在注册观察者的线程中,也就是说,Notification的发送与接收处理都是在同一个线程中。

我们在看一下下面这个例子。

#pragma mark - Override Base Function

- (void)viewDidLoad 
{
    [super viewDidLoad];
 
    NSLog(@"current thread = %@", [NSThread currentThread]);
 
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil];
 
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
 
        [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil];
    });
}
 
#pragma mark - Action && Notification

- (void)handleNotification:(NSNotification *)notification
{
    NSLog(@"current thread = %@", [NSThread currentThread]);
 
    NSLog(@"test notification");
}

下面看输出结果

2017-07-17 17:16:10.259 test[865:45102] current thread = {number = 1, name = main}
2017-07-17 17:16:10.259 test[865:45174] current thread = {number = 2, name = (null)}
2017-07-17 17:16:10.259 test[865:45174] test notification

可以看到,虽然我们在主线程中注册了通知的观察者,但在全局队列中post的Notification,并不是在主线程处理的。所以,这时候就需要注意,如果我们想在回调中处理与UI相关的操作,需要确保是在主线程中执行回调。

这时,就有一个问题了,如果我们的Notification是在二级线程中post的,如何能在主线程中对这个Notification进行处理呢?

下面看一下官方文档

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.

  • 这里讲到了“重定向”,就是我们在Notification所在的默认线程中捕获这些分发的通知,然后将其重定向到指定的线程中。
  • 一种重定向的实现思路是自定义一个通知队列(注意,不是NSNotificationQueue对象,而是一个数组),让这个队列去维护那些我们需要重定向的Notification。我们仍然是像平常一样去注册一个通知的观察者,当Notification来了时,先看看post这个Notification的线程是不是我们所期望的线程,如果不是,则将这个Notification存储到我们的队列中,并发送一个信号(signal)到期望的线程中,来告诉这个线程需要处理一个Notification。指定的线程在收到信号后,将Notification从队列中移除,并进行处理。

通知重定向

根据上面的思路,下面我们就看一下,通知重定向的实现。

#import "JJSecurityVC.h"

@interface JJSecurityVC () 

@property (nonatomic, strong) NSMutableArray  *notifications;         // 通知队列
@property (nonatomic, strong) NSThread          *notificationThread;                    // 期望线程
@property (nonatomic, strong) NSLock            *notificationLock;                      // 用于对通知队列加锁的锁对象,避免线程冲突
@property (nonatomic, strong) NSMachPort        *notificationPort;                      //消息端口,用于加到runloop中

@end

@implementation JJSecurityVC

#pragma mark - Override Base Function

- (void)viewDidLoad
{
    [super viewDidLoad];
    
    self.view.backgroundColor = [UIColor darkGrayColor];
    
    NSLog(@"current thread = %@", [NSThread currentThread]);
    
    // 初始化
    self.notifications = [[NSMutableArray alloc] init];
    self.notificationLock = [[NSLock alloc] init];
    
    self.notificationThread = [NSThread currentThread];
    self.notificationPort = [[NSMachPort alloc] init];
    self.notificationPort.delegate = self;
    
    // 往当前线程的run loop添加端口源
    // 当Mach消息到达而接收线程的run loop没有运行时,则内核会保存这条消息,直到下一次进入run loop
    [[NSRunLoop currentRunLoop] addPort:self.notificationPort
                                forMode:(__bridge NSString *)kCFRunLoopCommonModes];
    
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(processNotification:) name:@"TestNotification" object:nil];
    
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        
        [[NSNotificationCenter defaultCenter] postNotificationName:@"TestNotification" object:nil userInfo:nil];
        
    });
}

#pragma mark - Action && Notification

- (void)processNotification:(NSNotification *)notification
{
    
    if ([NSThread currentThread] != _notificationThread) {
        // 转发通知到想要的线程,这里就是重定向
        [self.notificationLock lock];
        [self.notifications addObject:notification];
        [self.notificationLock unlock];
        [self.notificationPort sendBeforeDate:[NSDate date]
                                   components:nil
                                         from:nil
                                     reserved:0];
    }
    else {
        // 处理通知
        NSLog(@"current thread = %@", [NSThread currentThread]);
        NSLog(@"process notification");
    }
}



#pragma mark - NSMachPortDelegate

- (void)handleMachMessage:(void *)msg
{
    
    [self.notificationLock lock];
    
    while ([self.notifications count]) {
        NSNotification *notification = [self.notifications objectAtIndex:0];
        [self.notifications removeObjectAtIndex:0];
        [self.notificationLock unlock];
        [self processNotification:notification];
        [self.notificationLock lock];
    };
    
    [self.notificationLock unlock];
}

@end

下面我们就看输出结果

2017-07-17 17:16:10.259 JJNotification[17266:1723827] current thread = {number = 1, name = main}
2017-07-17 17:16:10.265 JJNotification[17266:1723827] current thread = {number = 1, name = main}
2017-07-17 17:16:10.265 JJNotification[17266:1723827] process notification

可见都是在主线程处理的问题,实现了通知的重定向和转发。


通知安全性具体分析

上面我们发送的通知发送和监听不在一个线程,采用重定向的思路解决了问题,但是问题的本质是什么?下面我们分析一下通知安全问题的几种情况。

苹果之所以采取通知中心在同一个线程中post和转发同一消息这一策略,应该是出于线程安全的角度来考量的。官方文档告诉我们,NSNotificationCenter是一个线程安全类,我们可以在多线程环境下使用同一个NSNotificationCenter对象而不需要加锁。原文在Threading Programming Guide中。

但是事实真是如此吗?让我们看几种情况。

情况1

#import "JJSafeConditionVC.h"

@interface JJSafeConditionVC ()

@property (nonatomic, strong) UIButton *senderButton;

@end

@implementation JJSafeConditionVC

- (void)viewDidLoad
{
    [super viewDidLoad];
    
    self.view.backgroundColor = [UIColor lightGrayColor];
    
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:@"notificationName" object:nil];
    
    //UI 
    UIButton *senderButton = [UIButton buttonWithType:UIButtonTypeCustom];
    [senderButton setTitle:@"发送通知" forState:UIControlStateNormal];
    [senderButton setTitleColor:[UIColor blueColor] forState:UIControlStateNormal];
    [senderButton sizeToFit];
    senderButton.center = self.view.center;
    [senderButton addTarget:self action:@selector(buttonDidClick) forControlEvents:UIControlEventTouchUpInside];
    [self.view addSubview:senderButton];
    self.senderButton = senderButton;
}

- (void)dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

#pragma mark - Action && Notification

- (void)handleNotification:(NSNotification *)noti
{
    NSLog(@"handle notification ");
}

- (void)buttonDidClick
{
    [[NSNotificationCenter defaultCenter] postNotificationName:@"notificationName" object:nil];
}

@end

下面看效果

通知NSNotificationCenter详解(二)_第1张图片
效果

点击发送通知按钮就接收到通知了,下面看输出结果。

2017-07-17 20:55:18.257 JJNotification[1074:26357] handle notification 

上面的代码就是我们通常所做的事情:添加一个通知监听者,定义一个回调,并在所属对象释放时移除监听者;然后在程序的某个地方post一个通知。简单明了,如果这一切都是发生在一个线程里面,或者至少dealloc方法是在-postNotificationName:的线程中运行的(注意:NSNotification的post和转发是同步的),那么都OK,没有线程安全问题。但如果dealloc方法和-postNotificationName:方法不在同一个线程中运行时,会出现什么问题呢?

情况2

#pragma mark - Poster

@interface Poster : NSObject

@end

@implementation Poster

- (instancetype)init

{
    self = [super init];
    if (self)
    {
        [self performSelectorInBackground:@selector(postNotification) withObject:nil];
    }
    return self;
}

- (void)postNotification
{
    [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil];
}

@end


#pragma mark - Observer

@interface Observer : NSObject

{
    Poster  *_poster;
}

@property (nonatomic, assign) NSInteger i;

@end

@implementation Observer

- (instancetype)init
{
    self = [super init];
    if (self)
    {
        _poster = [[Poster alloc] init];
        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil];
    }
    return self;
}

- (void)handleNotification:(NSNotification *)notification
{
    NSLog(@"handle notification begin");
    sleep(1);
    NSLog(@"handle notification end");
    self.i = 10;
}

- (void)dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:self];
    NSLog(@"Observer dealloc");
}

@end

#pragma mark - ViewController

@implementation ViewController

- (void)viewDidLoad 
{
    [super viewDidLoad];

    __autoreleasing Observer *observer = [[Observer alloc] init];

}

@end


程序在self.i = 10处抛出了"Thread 6: EXC_BAD_ACCESS(code=EXC_I386_GPFLT)"

经典的内存错误,程序崩溃了。其实从输出结果中,我们就可以看到到底是发生了什么事。我们简要描述一下:

  • 当我们注册一个观察者是,通知中心会持有观察者的一个弱引用,来确保观察者是可用的。
  • 主线程调用dealloc操作会让Observer对象的引用计数减为0,这时对象会被释放掉。
  • 后台线程发送一个通知,如果此时Observer还未被释放,则会用其转出消息,并执行回调方法。而如果在回调执行的过程中对象被释放了,就会出现上面的问题。

由于以上几点因素,下面我们提出几点建议:

  • 尽量在一个线程中处理通知相关的操作。
  • 使用带有安全生命周期的对象,这一点对象单例对象来说再合适不过了。
  • 注册监听都时,使用基于block的API。这样我们在block还要继续调用self的属性或方法,就可以通过weak-strong的方式来处理。具体大家可以改造下上面的代码试试是什么效果。

后记

这一篇主要说的是通知的安全问题,这里借鉴了很多别人的文章,谢谢的帮助。关于通知还有很多其他东西需要说明和讲解。

通知NSNotificationCenter详解(二)_第2张图片
风景

你可能感兴趣的:(通知NSNotificationCenter详解(二))