通知中心是如何維護(hù)觀察者對(duì)象的檬输。
可以明確的是照瘾，添加觀察者時(shí)，通知中心沒有對(duì)觀察者做retain操作丧慈，即不會(huì)使觀察者的引用計(jì)數(shù)加1析命。那通知中心維護(hù)的是觀察者的weak引用呢還是unsafe_unretained引用呢主卫？
個(gè)人認(rèn)為可能是unsafe_unretained的引用，因?yàn)槲覀冎廊绻?code>weak引用鹃愤，其所指的對(duì)象被釋放后簇搅，這個(gè)引用會(huì)被置成nil。而實(shí)際情況是通知中心還會(huì)給這個(gè)對(duì)象發(fā)送消息软吐，并引發(fā)一個(gè)異常瘩将。而如果向nil發(fā)送一個(gè)消息是不會(huì)導(dǎo)致異常的。
【非常感謝 @lv-pw凹耙，上面這個(gè)問題在《斯坦福大學(xué)公開課：iOS 7應(yīng)用開發(fā)》的第5集的第57分50秒中得到了解答：確實(shí)使用的是unsafe_unretained姿现，老師的解釋是，之所以使用unsafe_unretained肖抱，而不使用weak备典，是為了兼容老版本的系統(tǒng)∫馐觯】
Notification的發(fā)送與接收處理都是在同一個(gè)線程中
如果我們希望一個(gè)Notification的post線程與轉(zhuǎn)發(fā)線程不是同一個(gè)線程則需要重定向
一種重定向的實(shí)現(xiàn)思路是自定義一個(gè)通知隊(duì)列(注意熊经，不是NSNotificationQueue對(duì)象，而是一個(gè)數(shù)組)欲险，讓這個(gè)隊(duì)列去維護(hù)那些我們需要重定向的Notification。我們?nèi)匀皇窍衿匠Ｒ粯尤プ?cè)一個(gè)通知的觀察者匹涮，當(dāng)Notification來了時(shí)天试，先看看post這個(gè)Notification的線程是不是我們所期望的線程，如果不是然低，則將這個(gè)Notification存儲(chǔ)到我們的隊(duì)列中喜每，并發(fā)送一個(gè)信號(hào)(signal)到期望的線程中，來告訴這個(gè)線程需要處理一個(gè)Notification雳攘。指定的線程在收到信號(hào)后带兜，將Notification從隊(duì)列中移除，并進(jìn)行處理吨灭。
1刚照、http://southpeak.github.io/2015/03/20/cocoa-foundation-nsnotificationcenter/
2、http://southpeak.github.io/2015/03/14/nsnotification-and-multithreading/
