OC的消息轉(zhuǎn)發(fā)機制的深度解讀

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

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

　　你可能早就遇到過經(jīng)由消息轉(zhuǎn)發(fā)流程所處理的消息了，只是未加留意。如果在控制臺中看到下面這種提示信息，那就說明你曾向某個對象發(fā)送過一條無法解讀的消息，從而啟動了消息轉(zhuǎn)發(fā)機制，并將次消息轉(zhuǎn)發(fā)給了NSObject得默認實現(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的選擇子。本例所列舉的這種情況并不奇怪，因為NSNumber類里本來就沒有名為lowercaseString的方法。在本例中，消息轉(zhuǎn)發(fā)過程以應(yīng)用程序崩潰而告終，不過，開發(fā)者在編寫自己的類時，可于轉(zhuǎn)發(fā)過程中設(shè)置掛鉤，用以執(zhí)行預(yù)定的邏輯，而不使應(yīng)用程序崩潰。

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

　　動態(tài)方法解析