相信大家對Object-C的消息傳遞機制并不陌生（如果不熟悉，我后續會再寫一篇關于消息傳遞機制的文章），今天我來講解另外一個重要的問題，就是對象在收到無法解讀的消息之后會發生什么情況。

　　若想令類能理解某條消息，我們必須以程序碼實現出對應的方法才行。但是，在編譯器向類發送了其無法解讀的消息并不會報錯，因為在運行期可以繼續向類中添加方法（動態添加），所以編譯器在編譯時還無法確知類中到底會不會有某個方法實現。當對象接收到無法解讀的消息后，就會啟動“消息轉發”（message forwarding）機制，程序員可經由此過程告訴對象應該如何處理未知消息。

　　你可能早就遇到過經由消息轉發流程所處理的消息了，只是未加留意。如果在控制臺中看到下面這種提示信息，那就說明你曾向某個對象發送過一條無法解讀的消息，從而啟動了消息轉發機制，并將次消息轉發給了NSObject得默認實現。

　　-［__NSCFNumber lowercaseString］：unrecognized selector

　　sent to instance 0x87

　　*** Terminating app due to uncaught exception

　　‘NSInvalidArgumentException’，reason：

　　‘-［__NSCFNumber lowercaseString］：unrecognized selector sent to instance ox87’

　　上面這段異常信息是由NSObject的“doesNotRecognizeSelector：”方法所拋出的，此異常表明：消息接收者的類型是__NSCFNumber，而該接受者無法理解名位lowercaseString的選擇子。本例所列舉的這種情況并不奇怪，因為NSNumber類里本來就沒有名為lowercaseString的方法。在本例中，消息轉發過程以應用程序崩潰而告終，不過，開發者在編寫自己的類時，可于轉發過程中設置掛鉤，用以執行預定的邏輯，而不使應用程序崩潰。

　　消息的轉發分為兩大階段。第一階段先征詢接收者，所屬的類，看其是否能動態添加方法，以處理當前這個“未知的選擇子”（unknown selector），這叫做“動態方法解析”（dynamic method resolution）。第二階段涉及“完整的消息轉發機制”。如果運行期系統已經把第一階段執行完了，那么接收者自己就無法再以動態新增方法的手段來響應包含該選擇子的消息了。此時，運行期系統會請求接受者以其他手段來處理與消息相關的方法調用。這又細分為兩小步。首先，請接受者看看有沒有其他對象處理這條消息。若有，則運行期系統會把消息轉給那個對象，于是消息轉發過程結束，一起如常。若沒有“備援的接收者”，則啟動完整的消息轉發機制，運行期系統會把于消息有關的全部細節都封裝到NSInvocation對象中，再給接收者最后一次機會，令其設法解決當前還未處理的這條消息。

　　動態方法解析