當我們像一個對象發送消息［Receiver message］，Receiver沒有實現該消息，即[Receiver respondsToSelector:SEL]返回為NO情況下，其實系統不會立刻出現cash，這時Runtime system會對message進行轉發。轉發之后，如果該消息依然沒有被執行就會出現Cash！Runtime System為我們提供了三種解決這種給對象發送沒有實現消息方案。
消息轉發機制基本上分為三個步驟：
1. 動態方法解析
2. 備用接收者
3. 完整轉發
我們可以通過控制這三個步驟其中一環來解決這一個問題
特別注意：如果是正常類的消息，是不會走到這三個步驟的。所以走到這三個不步驟的前提條件已經確定該消息為未知消息
這篇博客的前置知識點是 OC 的消息傳遞機制，如果你對此還不了解，請先學習之，再來看這篇。這篇博客我嘗試用口語的方式像講述 PPT 一樣給大家講述這個知識點。
我們來思考一個問題，如果對象在收到無法解讀的消息時，會發生什么？例如，我們實現一個 viewcontroller，其中并沒有一個成員方法名為『setText:』,當編寫這條語句時
[selfsetText:@"你好"];
示例
由于 OC 是一門動態語言，在編譯期只是顯示一條 warning，而不是阻止運行的 error。如果忽略 warning 運行，程序會 crash，在控制臺會顯示類似
unrecognized selector sent to instance0x7f931a4180d0
的報錯信息。
unrecognized selector
消息被發送給了不能處理它的對象。我們學習 iOS 的消息轉發機制可不是為了故意造這樣的 crash 玩，說上面的這個例子，是為了說明如果我們不通過消息轉發機制做任何事情的話，系統最終會以 crash 結束。等等，剛才我們說到 OC 是一門動態語言，那么是否可以在運行期做一些事來讓 crash 不會發生呢？
消息轉發機制就是來干這件事的，在運行期通過3個『接盤俠』方法，給對象和消息更多的機會來完成成功的調用，而不是直接 crash。
一號接盤俠
第一個接盤俠代表動態方法解析階段，對應的具體方法是+(BOOL)resolveInstanceMethod:(SEL)sel 和+(BOOL)resolveClassMethod:(SEL)sel，當方法是實例方法時調用前者，當方法為類方法時，調用后者。這個方法設計的目的是為了給類利用 class_addMethod 添加方法的機會。
看下面這個示例，MyTestObject類重寫了第一個接盤俠方法，可以看到這個方法傳入一個 selector，返回 BOOL 類型。被傳入的 selector 就是未被處理的方法，在一號接盤俠方法中，判斷若方法名為 XXX 則給這個類添加同名的方法，把方法的實現指向跟 XXX 名字不一致的 AAA，并返回 YES。若 selector 名字不是 XXX，就返回父類。
resolveInstanceMethod
通過這個示例，可以看出，我們可以通過一號接盤俠方法讓 方法名和方法實現在運行期任意搭配。
再說一下這個返回值，其實可以試驗一下，無論返回 YES 還是 NO，系統都會嘗試用 SEL 來尋找 IMP，如果找到函數實現，則執行，所以無論返回 YES\NO都會進入二號接盤俠方法。
二號接盤俠
第二個階段是備援接收者階段，對象的具體方法是-(id)forwardingTargetForSelector:(SEL)aSelector ，此時，運行時詢問能否把消息轉給其他接收者處理，也就是此時系統給了個將這個 SEL 轉給其他對象的機會。我們繼續來研究下參數和返回值，參數和一號接盤俠一樣，都是 selector，返回值是 id 類型，當返回 非self\非nil 時，消息被轉給新對象執行。
forwardingTargetForSelector
三號接盤俠
第三個階段是完整消息轉發階段，對應方法-(void)forwardInvocation:(NSInvocation *)anInvocation，這是消息轉發流程的最后一個環節。參數 anInvocation 中包含未處理消息的各種信息（selector\target\參數...）。在這個方法中，可以把 anInvocation 轉發給多個對象，與二號接盤俠不同，二號只能轉給一個對象。
forwardInvocation
如果上述3個方法都沒有來處理這個消息，就會進入 NSObject 的-(void)doesNotRecognizeSelector:(SEL)aSelector方法中，拋出異常。等等，為什么我們不能通過給 NSObject 創建一個 category，重寫這個方法，在這里處理消息未被處理的情況呀？在蘋果的官方文檔中，明確提到，“一定不能讓這個函數就這么結束掉，必須拋出異常”。除了聽官方文檔的話，其實在分類中通過重寫該方法處理各種消息未被處理的情況，會讓這個分類的方法特別長，不利于維護。而且還有個原因，明明方法名叫『無法識別 selector』，其中卻是一大堆處理該情況的代碼，也很奇怪。
doesNotRecognizeSelector
總結
總結一下整個消息轉發的流程：
消息轉發的流程
可以通過重寫3個接盤俠方法，在其中打斷點來驗證執行順序。
斷點驗證順序
總結：
在一個函數找不到時，OC提供了三種方式去補救：
1、調用resolveInstanceMethod給個機會讓類添加這個實現這個函數
2、調用forwardingTargetForSelector讓別的對象去執行這個函數
3、調用forwardInvocation（函數執行器）靈活的將目標函數以其他形式執行。
如果都不中，調用doesNotRecognizeSelector拋出異常。
疑問
Q1:那我們只用最后一個接盤俠方法多好啊，為什么還需要前2個呢？
其實還與這3個方法的用途不同有關：
運行期添加方法，用1；
轉發給另1個對象、改變方法時，用2；
需要轉發給多個對象時，用3；
而且，步驟越往后，處理消息的代價越大，到最后一個階段時，都創建了 NSInvocation 對象了。
Q2:消息轉發有哪些應用場景呢？
可以在運行期再加入某方法,例如 Teacher 類里有teach方法，DrugDealer 類里有letsCook方法，通過一號接盤俠方法，我們可以在運行期把 saleDrug 偷摸加到 teacher 的方法列表中，讓 teacher 具備販毒的功能，[teacher? guessWhatHeDo]，實際調用的是[teacher letsCook]，唉呀媽呀，絕命毒師啊。
把方法轉給其他對象處理，再舉個例子，還是 Teacher 類（博主跟老師有仇嗎...），[teacher letsCook]，可以把對象在運行期換為drugDealer。再來一個 Cook 類，也有 letsCook 方法，但這次這方法不是 cook 毒品，而是 cook 菜。因此既可以通過[teacher letsCook] 實現[drugDealer letsCook],也可以實現[cook letsCook]。相當于 OC 實現了多重繼承，雖然有點不太恰當...
注意
respondsToSelector我們再熟悉不過了，用來檢查某對象是否實現了某方法。此函數通常是不需要重載的，但是在動態實現了查找過程后，需要重載此函數讓對外接口查找動態實現函數的時候返回YES，保證對外接口的行為統一。
respondsToSelector
最后說一下 warning 的事。編譯器很好心的報的那個 warning 咋辦呢，不管那個小黃條不是一個愛整潔的程序員的風格，所以我們要想辦法把它去掉。
有兩種方法，第一種比較暴力，通過在配置文件中把 Complier Flag 加-w，對該類去除所有 warning。
去掉所有warning
第二種是推薦的做法，在 xcode 的 error 面板對 warning 右鍵-Reveal in Log,這里有個小 bug，如果這個選項不可選擇，需要你重新 build 一下就可選了，
小 Bug
在右側，可以看到這個warning 的名稱，
如何看warning名稱
所以用這個宏把出現 warning 的代碼包圍起來，就可以讓編譯器不再報錯：
#pragmaclang diagnostic push#pragmaclang diagnostic ignored"-Wobjc-method-access"[self setText:@"你好"];#pragmaclang diagnostic pop
文／毀小慕（簡書作者）
原文鏈接：http://www.lxweimin.com/p/fa29c920409d
著作權歸作者所有，轉載請聯系作者獲得授權，并標注“簡書作者”。
