OC的消息转发机制的深度解读

　　相信大家对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对象中，再给接收者最后一次机会，令其设法解决当前还未处理的这条消息。

　　动态方法解析