NSNOTIFICATIONCENTER 正確使用姿勢(shì)

? ? ? ? 最近在開發(fā)的過程中,發(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使用的正確姿勢(shì)。

NSNotificationCenter

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

正確姿勢(shì)之remove

只要往NSNotificationCenter注冊(cè)了售碳,就必須有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è)操作缰趋,我們來做下代碼的測(cè)試捧杉。

一個(gè)測(cè)試類,用來注冊(cè)通知:

@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

這個(gè)類很簡(jiǎn)單秘血,就是在初始化的時(shí)候味抖,給他注冊(cè)一個(gè)通知。但是在銷毀的時(shí)候不進(jìn)行remove操作灰粮。我們?cè)赩C中創(chuàng)建這個(gè)對(duì)象后非竿,然后銷毀,最后發(fā)送這個(gè)通知:

-?(void)viewDidLoad?{

[superviewDidLoad];

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?測(cè)試[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)在我們?cè)赨IViewController中注冊(cè)通知蚂会,不移除淋样,看看會(huì)不會(huì)掛掉。

-?(void)viewDidLoad?{

[superviewDidLoad];

[[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)上面野指針的問題酵镜〉锏铮看來看去,也只能說明是UIViewController自己銷毀的時(shí)候幫我們暗地里移除了笋婿。

那我們?nèi)绾巫C明呢誉裆?由于我們看不到源碼顿颅,所以也不知道有沒有調(diào)用缸濒。這個(gè)時(shí)候,我們可以從這個(gè)通知中心下手A荒濉1优洹!怎么下手呢绍些?我只要證明UIViewController在銷毀的時(shí)候調(diào)用了remove方法捞慌,就可以證明我們的猜想是對(duì)的了!這個(gè)時(shí)候柬批,就需要用到我們強(qiáng)大的類別這個(gè)特性了啸澡。我們?yōu)镹SNotificationCenter添加個(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?測(cè)試[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)槟阌锌赡芤瞥讼到y(tǒng)注冊(cè)的通知。

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

在我們開發(fā)中奠衔,我們經(jīng)匙慌伲可以看到這樣的代碼:

-?(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)的時(shí)候注冊(cè)通知,頁面消失時(shí)移除通知归斤。你這邊可要注意了痊夭,一定要成雙成對(duì)出現(xiàn),如果你只在viewWillAppear 中 addObserver沒有在viewWillDisappear 中 removeObserver那么當(dāng)消息發(fā)生的時(shí)候脏里,你的方法會(huì)被調(diào)用多次她我,這點(diǎn)必須牢記在心。

正確姿勢(shì)之多線程通知

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

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.

意思很簡(jiǎn)單迫横,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í)慣,該移除的還是要移除膀哲。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末往产,一起剝皮案震驚了整個(gè)濱河市被碗,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌仿村,老刑警劉巖蛮放,帶你破解...
    沈念sama閱讀 216,496評(píng)論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異奠宜,居然都是意外死亡包颁,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,407評(píng)論 3 392
  • 文/潘曉璐 我一進(jìn)店門压真,熙熙樓的掌柜王于貴愁眉苦臉地迎上來娩嚼,“玉大人,你說我怎么就攤上這事滴肿≡牢颍” “怎么了?”我有些...
    開封第一講書人閱讀 162,632評(píng)論 0 353
  • 文/不壞的土叔 我叫張陵泼差,是天一觀的道長(zhǎng)贵少。 經(jīng)常有香客問我,道長(zhǎng)堆缘,這世上最難降的妖魔是什么滔灶? 我笑而不...
    開封第一講書人閱讀 58,180評(píng)論 1 292
  • 正文 為了忘掉前任,我火速辦了婚禮吼肥,結(jié)果婚禮上录平,老公的妹妹穿的比我還像新娘。我一直安慰自己缀皱,他們只是感情好斗这,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,198評(píng)論 6 388
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著啤斗,像睡著了一般表箭。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上钮莲,一...
    開封第一講書人閱讀 51,165評(píng)論 1 299
  • 那天免钻,我揣著相機(jī)與錄音,去河邊找鬼臂痕。 笑死伯襟,一個(gè)胖子當(dāng)著我的面吹牛猿涨,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播叛赚,決...
    沈念sama閱讀 40,052評(píng)論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼稽揭,長(zhǎng)吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來了肥卡?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 38,910評(píng)論 0 274
  • 序言:老撾萬榮一對(duì)情侶失蹤步鉴,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后氛琢,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,324評(píng)論 1 310
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡阳似,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,542評(píng)論 2 332
  • 正文 我和宋清朗相戀三年骚勘,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片撮奏。...
    茶點(diǎn)故事閱讀 39,711評(píng)論 1 348
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡俏讹,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出畜吊,到底是詐尸還是另有隱情泽疆,我是刑警寧澤,帶...
    沈念sama閱讀 35,424評(píng)論 5 343
  • 正文 年R本政府宣布玲献,位于F島的核電站于微,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏青自。R本人自食惡果不足惜株依,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,017評(píng)論 3 326
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望延窜。 院中可真熱鬧恋腕,春花似錦、人聲如沸逆瑞。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,668評(píng)論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽获高。三九已至哈肖,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間念秧,已是汗流浹背淤井。 一陣腳步聲響...
    開封第一講書人閱讀 32,823評(píng)論 1 269
  • 我被黑心中介騙來泰國(guó)打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人币狠。 一個(gè)月前我還...
    沈念sama閱讀 47,722評(píng)論 2 368
  • 正文 我出身青樓游两,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親漩绵。 傳聞我的和親對(duì)象是個(gè)殘疾皇子贱案,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,611評(píng)論 2 353

推薦閱讀更多精彩內(nèi)容