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

　　若想令類能理解某條消息，我們必須以程序碼實(shí)現(xiàn)出對(duì)應(yīng)的方法才行。但是，在編譯器向類發(fā)送了其無法解讀的消息并不會(huì)報(bào)錯(cuò)，因?yàn)樵谶\(yùn)行期可以繼續(xù)向類中添加方法（動(dòng)態(tài)添加），所以編譯器在編譯時(shí)還無法確知類中到底會(huì)不會(huì)有某個(gè)方法實(shí)現(xiàn)。當(dāng)對(duì)象接收到無法解讀的消息后，就會(huì)啟動(dòng)“消息轉(zhuǎn)發(fā)”（message forwarding）機(jī)制，程序員可經(jīng)由此過程告訴對(duì)象應(yīng)該如何處理未知消息。

　　你可能早就遇到過經(jīng)由消息轉(zhuǎn)發(fā)流程所處理的消息了，只是未加留意。如果在控制臺(tái)中看到下面這種提示信息，那就說明你曾向某個(gè)對(duì)象發(fā)送過一條無法解讀的消息，從而啟動(dòng)了消息轉(zhuǎn)發(fā)機(jī)制，并將次消息轉(zhuǎn)發(fā)給了NSObject得默認(rèn)實(shí)現(xiàn)。

　　-［__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的選擇子。本例所列舉的這種情況并不奇怪，因?yàn)镹SNumber類里本來就沒有名為lowercaseString的方法。在本例中，消息轉(zhuǎn)發(fā)過程以應(yīng)用程序崩潰而告終，不過，開發(fā)者在編寫自己的類時(shí)，可于轉(zhuǎn)發(fā)過程中設(shè)置掛鉤，用以執(zhí)行預(yù)定的邏輯，而不使應(yīng)用程序崩潰。

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

　　動(dòng)態(tài)方法解析