說明：為了區別「本地通知」與「推送通知」這兩種iOS中提醒用戶，可見的「通知」，本文所將Notification翻譯為「通告」。它們的詳細區別，可參考《iOS開發系列--通知與消息機制》一文。

實踐遇到的問題：

最近在維護公司的一個項目中，遇到這樣一個報錯：-[GlobalManager addAlbum:]: unrecognized selector sent to instance

經排查，原因如下：以前同事在利用「通告機制」在GlobalManager類中把「自己/self」注冊為「觀察器」(用了addObserver: selector: name: object:方法)，但是沒有在注冊觀察器的類(GlobalManager類)中實現selector參數中的方法(他在其他類實現了)。所以就報上述錯誤(其實報錯中字面也說得挺明白的，只是總意會不到英文中的那個意思)。

解決：將 selector參數的方法寫在當前類中?；蛘邉h除注冊「觀察器」的代碼，即不報這個錯。

再經過后來的查閱資料，得出結論：如果用addObserver: selector: name: object:方法向「通告中心」注冊「觀察器」，第二個參數，即selector:中的方法，必須在當前類中實現，如果寫在其他類，就會報上述錯誤。詳見圖一：

擴展：另一個注冊觀察器的方法
另外，注冊觀察器還可以用另外一個方法：
addObserverForName: object: queue: usingBlock:
這個是利用block的形式進行「回調」，代碼更簡潔、直觀。而上面的方法是「利用@selector關鍵字傳遞SEL類型的函數名」進行「回調」。

圖一：注冊「觀察器」

插播：「回調/callback」

上述「通告機制」，涉及到「回調」這個概念，因為維基百科上面的定義有點抽象，我自己理解就是：某段代碼/函數，需要由特定用戶事件來觸發，就是「回調」，沒有這個事件，就不會執行這段代碼。術語就是「通過『函數指針』調用的函數」。
而根據《Objective-C PRogramming 2nd Edition》這本書，iOS的回調，分為四類：
1.目標－動作對/Target-action；
2.輔助對象/Helper objects；(包括「委托/delegates」、「數據源/data sources」)
3.通告/Notifications；
4.Block。
這里只簡單復述iOS回調的幾種類型，至于何種情況用何種回調，可以看書中介紹。(我自己也需要更多實踐去體驗。)

詳解：「通告機制」

可以看到，第三種回調：「通告」，就是我們上面應用的「通告機制」。它是基于「觀察者模式」的。
「通告機制」在代碼層面，涉及兩個類：NSNotification類及NSNotificationCenter類，它們都定義在“NSNotification.h”文件中。

NSNotification類：
代表「通告」的內容載體有三個屬性：name(通告的名稱)，object(通告的發送者/誰發送這個通告)，userInfo(通告的附加信息/參數)
此外，NSNotification類及它的擴展類(category)還有5個初始化/實例化「通告」的方法，詳情可在Xcode中查看。

NSNotificationCenter類：
是通告系統的中心，用于獲取通告中心、注冊、移除觀察器、發送通告。有8個方法。詳情可在Xcode中查看。

因此，我們可以總結「應用「通告機制」的步驟」：

1.注冊觀察器。
這一步解決誰觀察通告中心，觀察通什么通告，觀察通誰的通告，接到通告后執行什么方法這些問題。
注冊觀察器的方法
addObserver: selector: name: object:
addObserverForName: object: queue: usingBlock:

2.實現selector中的方法或block中的代碼
這一步具體實現接到通告后執行什么動作。

3.向通告中心發布/post通告。觸發回調， 實現最終要的效果。(此步驟可選)
注意，這里由誰發送通告(在哪個類中寫發送通告代碼)，要看觸發事件是在哪個控制器類中。
另外，如果觀察一些系統通告，如UIDevice的這四種「通告」(UIDeviceOrientationDidChangeNotification、UIDeviceBatteryStateDidChangeNotification、UIDeviceBatteryLevelDidChangeNotification、UIDeviceProximityStateDidChangeNotification)，則由系統自動發布通告，無需自己實現。

發布通告的方法：
postNotification:
postNotificationName: object:
postNotificationName: object: userInfo:

4.將注冊為觀察器的對象移出通告中心
可用方法：
removeObserver:
removeObserver: name: object:

范例：

在工程中AppDelegate類中，添加以下代碼，可觀察/監測是否有物體接近屏幕。

 1 UIDevice *device = [UIDevice currentDevice]; 2 // 打開近身監視功能 3 [device setProximityMonitoringEnabled:YES]; 4  5 // 注冊觀察器 6 [[NSNotificationCenter defaultCenter] addObserverForName:UIDeviceProximityStateDidChangeNotification 7                                                   object:nil 8                                                    queue:[NSOperationQueue mainQueue] 9                                               usingBlock:^(NSNotification *note) {10                                                   NSLog(@"有物體接近屏幕了");11 }];

近身監測功能的實現

擴展：「架構模式/Architectural pattern」與「設計模式/design pattern」

到此，對「通告機制」的基本原理，具體實現有了一定了解。不過在研究「通告機制」的時候，接觸到「觀察者模式」，繼而又接觸到「設計模式」及「架構模式」，一下子信息量太大，感覺如墜云中，只見樹木，不見森林。于是又研究了一陣(主要參考維基百科的資料)，總結并畫出下圖二，感覺能大概從宏觀上把握這些概念了。(不知有無謬誤，如有發現，還請斧正，謝謝。)

圖二：對「架構模式」及「設計模式」的理解

而關于「MVC模式」及「觀察者模式」在整個「軟件設計模式/Software design patterns」中的位置，則如下圖三：

圖三：「MVC」及「觀察者模式/Observer」在整個「軟件設計模式/Software design patterns」中的位置

突然間，感覺舒服蠻多了。