NSNotificationCenter深入研究

最近看到一段有趣的代码

      if ([[UIDevice currentDevice].systemVersion floatValue] < 9.0) {
            __weak typeof(self) weakSelf;
            [[NSNotificationCenter defaultCenter] addObserverForName:kMEChangeNotification
                                                              object:nil
                                                               queue:[NSOperationQueue mainQueue]
                                                          usingBlock:^(NSNotification * _Nonnull note) {
                                                              [weakSelf doSomeThing];
                                                          }];
        } else {
            [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(doSomeThing) name:kMEChangeNotification object:nil];
        }

一开始看到就猜想难道不同的系统接受通知的姿势不一样?但是之前一直都在用addObserver,也没出现过问题啊,感觉这串代码是多此一举,就没在管。后来有一次因为没有removeObserver引发了崩溃,才发现这串代码是有深意的。最近整理了一下,留作笔记,因为这里面特别绕

规则只有一个,无论什么时候都不可以打破

规则:addObserverForNameblock里面必须使用weakSelf,否则会造成循环引用导致当前类无法释放

注意事项

  • 注意事项一:doSomeThing里面如果要刷新UI,最好是回调主线程。
    因为通知的接收所在的线程是基于发送通知所在的线程,如果通知是在主线程发出的,通知的接收也是在主线程,如果通知的发送是在子线程,通知的接收也是在子线程。也就是说如果你不能保证你的通知一定是在主线程发送的,就最好回到主线程刷新UI
-(void)doSomeThing
{
        //do something

   dispatch_async(dispatch_get_main_queue(), ^{
       // UI
   });
}
  • 注意事项二:通知的移除要调用各自的移除方法
    addObserverForNameaddObserver通知的移除方法是不一样的
    addObserver通知的移除方法是[[NSNotificationCenter defaultCenter]removeObserver:self],这是最常见的,然而对于addObserverForName是没有用的,
    addObserverForName通知的移除方法是在声明的时候要记录通知变量
@interface SecondViewController ()
{
    id notificationObserver;
}
//或者
//@property (nonatomic, strong) id notificationObserver;
@end

 __weak typeof(self) weakSelf;
    notificationObserver = [[NSNotificationCenter defaultCenter]addObserverForName:@"MYNotificationCenter" object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification * _Nonnull note) {
        NSLog(@"addObserverForName接收到通知");
        [weakSelf doSomeThing];
    }];

然后使用[[NSNotificationCenter defaultCenter]removeObserver:notificationObserver];移除

打破概念特别注意事项

特别注意事项:通知的移除不一定非要写
对于addObserverForName:

__weak typeof(self) weakSelf;
    notificationObserver = [[NSNotificationCenter defaultCenter]addObserverForName:@"MYNotificationCenter" object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification * _Nonnull note) {
        NSLog(@"addObserverForName接收到通知");  //如果没有移除这个通知,每次接到通知时这个NSLog都会输出
        [weakSelf doSomeThing]; //如果没有移除这个通知,如果是直接使用self,则这个通知所在NSObject或者ViewController都不会释放,如果是使用weakSelf,则这个通知所在NSObject或者ViewController都会释放,就不会再继续调用doSomeThing方法
    }];

对于addObserver:
这里要分ViewController和普通NSObject两个说起
ViewController:在调用ViewController的dealloc的时候,系统会调用[[NSNotificationCenter defaultCenter]removeObserver:self]方法,所以如果是在viewDidLoad中使用addObserver添加监听者的话可以省掉移除。当然,如果是在viewWillAppear中添加的话,那么就要在viewWillAppear中自己移除,而且,最好是使用[[NSNotificationCenter defaultCenter] removeObserver:self name:@"test" object:nil];而非[[NSNotificationCenter defaultCenter]removeObserver:self],否则很有可能你会把系统的其他通知也移除了

普通NSObject:在iOS9之后,NSObject也会像ViewController一样在dealloc时调用[[NSNotificationCenter defaultCenter]removeObserver:self]方法,在iOS9之前的不会调用,需要自己写。

文字开头的那段代码应用场景:在使用类别的时候如果我们添加了通知,那么我们是没有办法在类别里面重写dealloc的,如果不移除通知就会出现野指针,这个时候我们就可以在iOS9以上使用addObserver,将通知的移除交给系统,iOS9一下使用addObserverForName+weakSelf,虽然通知依然存在,但是不会调用doSomeThing方法(不要直接在block里面写处理过程啊)。

ViewController、NSObject、Notification释放图表(YES-释放).png

最后附上测试demo下载

再总结一下

当你的通知没办法注销的时候,iOS9以下addObserverForName可以不注销通知的情况下(通知没释放)释放监听者,iOS9以上使用addObserver可以不手动注销通知情况下释放通知和监听者,涉及到内存使用问题。关键在于没办法手动注销通知的情况下,比如你的扩展里面使用了通知,但是扩展不支持调用dealloc.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容