iOS runtime方法详解之消息
由于Objective-C是C的超集，C语言的函数调用方式是“静态绑定”，也就是在编译期就能决定运行时所应调用的函数；
在Objective-C中，如果向某对象传递消息，那就会使用动态绑定机制来决定需要调用的方法，在底层，所有方法都是普通的C语言函数，然而对象接收到消息之后，究竟该调用哪个方法则完全于运行期决定，甚至可以在程序运行时改变，这些特性使得Objective-C成为一门真正的动态语言。
Objective-C中给对象发送消息写法如下：
id returnValue = [someObject messageName:parameter];
someObject叫做"接收者"(receiver),messageName叫做"选择器"(selector)；选择器和参数合起来称为"消息"(message)，编译器看到此消息以后，将其转换为一条标准的C语言函数调用，所调用的函数乃是消息传递机制中的核心函数，叫做objc_msgSend，原型如下：
id objc_msgSend(id self, SEL op, ...)
第一个参数代表接收者，第二个参数是选择器，后面是消息中的参数，编译器会把上面的消息转换成如下函数：
id returnValue = objc_msgSend(someObject,
@selector(messageName:),
parameter);
objc_msgSend函数会依据接收者与选择器的类型在接收者所属的类中搜索其"方法列表"(list of methods),如果能找到与选择器名称相符的方法，就跳至其实现代码，如果找不到，就沿着继承体系继续向上查找，找到则跳转，如果最终都没找到，就执行"消息转发"(message forwarding)。
这么说来，调用一个方法似乎需要很多步骤，所幸objc_msgSend会将匹配结果缓存在"快速映射表"(fast map)里面，每个类都有这样一块缓存，若是稍后还向该类发送与选择器相同的消息，那么执行起来就很快了，当然，这种"快速执行路径"(fast path)还是不如"静态绑定的函数调用操作"(statically bound function call)那样迅速，不过只要把选择器缓存起来了，也就不会慢很多，实际上，消息派发(message dispatch)并非应用程序的瓶颈所在。
objc_msgSend等函数一旦找到应该调用的方法实现之后，就会跳转过去，之所以这样做，是因为Objective-C对象的每个方法都可以视为简单的C函数，原型如下：
每个类都有一张表格，其中的指针都会指向这种函数，而选择器的名称则是查表时所用的"键"，objc_msgSend等函数正是通过这张表格来寻找应该执行的方法并跳至其实现的。
请注意，原型的样子和objc_msgSend函数很像，这不是巧合，而是为了利用"尾调用优化"(tail-call optimization)技术，令"跳至方法实现"这一操作变得更简单些。
要点：
1.消息由接收者，选择器和参数构成。给某对象"发送消息"(invoke a message)也就相当于在该对象上"调用方法"(call a method)。
2.发给某对象的全部消息都要由"动态消息派发系统"(dynamic message dispatch system)来处理，该系统会查出对应的方法，并执行其代码。
若想令类能理解某条消息，我们必须以程序实现出对应的方法才行，但是，在编译期向类发送了其无法理解的消息并不会报错，因为在运行期可以继续向类中添加方法，所以编译器在编译时还无法确定类中到底会不会有某个方法实现，当对象接收到无法解读的消息后，就会启动"消息转发"((message forwarding)机制，程序员可经由此过程告诉对象应该如何处理未知消息。
-[Book InstanceMethod]: unrecognized selector sent to instance 0x7fe9c370f0a0
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[Book InstanceMethod]: unrecognized selector sent to instance 0x7fe9c370f0a0'
上面的崩溃信息就是当我们调用了一个对象没有实现的方法，而程序又没有实现消息转发的时候触发的。
消息转发分为两大阶段：
第一阶段先征询接收者，所属的类，看其是否能动态添加方法，以处理当前这个"未知的选择器"(unknown selector)，这叫做"动态方法解析"(dynamic method resolution)。
第二阶段涉及"完整的消息转发机制"(full forwarding mechanical)。
第一阶段中，首先，请接收者看看有没有其他对象能处理这个消息，如果有，则运行期系统会把消息转给那个对象，于是消息转发过程结束，如果没有"备援的接收者"(replacement receiver)，则启动完整的消息转发机制，运行期系统会把与消息有关的全部细节都封装到NSInvocation对象中，再给接收者最后一次机会，令其设法解决当前还未处理的这条消息。
动态方法解析：
对象在收到无法解读的消息后，首先将调用其所属类的下列类方法：
+(BOOL)resolveInstanceMethod:(SEL)selector
该方法的参数就是那个未知的选择器，其返回值为布尔类型，表示这个类是否能新增一个实例方法用以处理这个选择器。在继续往下执行转发机制之前，本类有机会新增一个处理此选择器的方法。假如尚未实现的方法不是实例方法而是类方法，那么运行期系统就会调用另外一个方法，该方法与"resolveInstanceMethod:"类似，叫做"resolveClassMethod:"。
使用这种方法的前提是：相关方法的实现代码已经存在，只等运行时动态插在类里面就可以了。此方法用来实现@dyanmic属性(阻止编译器自动合成存取方法和创建相应实例变量)，例如要访问CoreData框架中NSManagedObject对象的属性时就可以这么做，因为实现这些属性所需的存取方法在编译器就能确定。
备援接收者：
当前接收者还有第二次机会能处理未知的选择器，在这一步中，运行期系统会问它：能不能把这条消息转给其他接收者来处理。该步骤对应的处理方法如下：
- (id)forwardingTargetForSelector:(SEL)aSelector
方法参数代表未知的选择器，若当前接收者能找到备援对象，则将其返回，找不到就返回nil。通过此方案，我们可以用"组合"(composition)来模拟出"多重继承"(multiple inheritance)的某些特性。在一个对象内部，可能还有一系列其他对象，该对象可经由此方法将能够处理某选择器的相关内部对象返回，这样的话，在外界看来，好像是该对象亲自处理了这些消息。
通过下面的例子来熟悉这个过程：
@interface BaseClass : NSObject
- (void)uppercaseString;
@end
@implementation BaseClass
+(BOOL)resolveInstanceMethod:(SEL)name
{
NSLog(@"%s %@",__FUNCTION__, NSStringFromSelector(name));
if (name == @selector(uppercaseString)) {
class_addMethod([self class], name, (IMP)dynamicMethodIMP, "v@:");
return YES;
}
return [super resolveInstanceMethod:name];
}
void dynamicMethodIMP(id self, SEL _cmd) {
NSLog(@"%s",__FUNCTION__);
}
- (id)forwardingTargetForSelector:(SEL)aSelector
{
NSLog(@"%s",__FUNCTION__);
return @"abcd";
}
@end BaseClass *object = [[BaseClass alloc]init];
[object uppercaseString];+[BaseClass resolveInstanceMethod:] uppercaseString
dynamicMethodIMP
我们再屏蔽掉resolveInstanceMethod:方法后打印信息如下：
-[BaseClass forwardingTargetForSelector:]
说明：对象在收到无法解读的消息后（自身和超类都没实现的方法），首先查看是否实现resolveInstanceMethod:类方法来动态的添加实例方法来处理这个选择器，如果对象没有实现这个类方法来处理未知的选择器，就会继续跳转到forwardingTargetForSelector:方法，将这个未知选择器转给这个方法返回的对象来处理，这个例子中BaseClass并没有实现uppercaseString方法，而NSString的实例是已经实现uppercaseString方法的，因此，在没有动态添加方法的情况下，程序会跳转到forwardingTargetForSelector:中让@"abcd"这个字符串对象去实现uppercaseString方法。
消息转发:
如果上面说到的动态方法解析和备援接收者都没有实现，那么就开启了消息转发。
首先创建NSInvocation对象，把与尚未处理的那条消息有关的全部细节都封装进去，此对象包含选择器，目标及参数。在触发NSInvocation对象时，"消息派发系统"(message-dispatch system)将亲自出马，把消息指派给目标对象。
此步骤会调用下列方法来转发消息：
- (void)forwardInvocation:(NSInvocation *)anInvocation
这个方法可以实现得很简单，只需改变调用目标，使消息在新目标上得以调用即可。然而这样实现出来的方法与"备援接收者"方案所实现的方法等效，所以很少有人采用这么简单地实现方式。
实现此方法时，若发现某调用操作不应由本类处理，则需调用超类的同名方法，这样的话，继承体系中的每个类都有机会处理此调用请求，直至NSObject。如果最后调用了NSObject类的方法，那么该方法还会继而调用"doesNotRecognizeSelector:"以抛出异常，此异常表明选择器最终未能得到处理。
我们再看下面的例子：
@interface BaseClass : NSObject
- (void)uppercaseString;
@end
@implementation BaseClass
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
SEL name = [anInvocation selector];
NSLog(@"%s %@",__FUNCTION__, NSStringFromSelector(name));
NSString * proxy = [[NSString alloc] init];
if ([proxy respondsToSelector:name]) {
[anInvocation invokeWithTarget:proxy];
}
else {
[super forwardInvocation:anInvocation];
}
}
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {
NSLog(@"%s",__FUNCTION__);
return [NSString instanceMethodSignatureForSelector:aSelector];
}
@end BaseClass *object = [[BaseClass alloc]init];
[object uppercaseString];打印信息：
-[BaseClass methodSignatureForSelector:]
-[BaseClass forwardInvocation:] uppercaseString
消息转发流程图：
接收者在每一步中均有机会处理消息，步骤越往后，处理消息的代价就越大。最好能在第一部就处理完，这样的话，运行期系统就可以将此方法缓存起来了。如果这个类的实例稍后还收到同名选择器，那么根本无须启动消息转发流程。若想在第三步里把消息转给备援的接收者，那还不如把转发操作提前到第二步。因为第三步只是修改了调用目标，这项改动放到第二步执行会更加简单，不然的话，还得创建并处理完整的NSInvocation。
总结：
消息发送流程
1.接收者首先在其所属的类中搜索其"方法列表"(list of methods),如果能找到与选择器名称相符的方法，就跳至其实现代码，如果找不到，就沿着继承体系继续向上查找，找到则跳转，如果最终都没找到，则执行2；
2.查看是否实现resolveInstanceMethod:类方法来动态的添加实例方法来处理这个选择器，如果对象没有实现这个类方法来处理未知的选择器，则执行3；
3.查看是否实现forwardingTargetForSelector:方法，将这个未知选择器转给这个方法返回的备援对象来处理，如果没有实现这个方法或者备援对象为nil，则执行4；
4.是否实现methodSignatureForSelector:和forwardInvocation:方法来执行消息转发，如果没有实现消息转发则crash；
参考资料
- Effective Objective-C