Object - C 的消息处理机制与 Method Swizzling(函数混淆)

objc_msgSend

在Object-C中，我们经常调用一个对象的方法，通常我们将这个过程成为 消息传递。不同于 C 语言对对象方法的静态调用，Object-C 是通过 Dynamic Binding (动态绑定) 机制来实现消息传递的，对象对于详细的响应和处理都是在 runtime 运行时才能决定。
通常，一个消息传递是这个样子的

id result = [object messageName:prameter];  

而在程序编译时，编译器会自动将其转为C函数

id objc_msgSend(id self,SEL cmd, ...) ;

这是一个可变参数的函数，它接受了两个或以上的参数，包括消息的目标对象，消息的seletor，还有依照顺序传入的消息参数。
objc_msgSend 函数负责的是处理一个发往对象的消息，让对象调用正确地方法，其机制如下

• 首先，它会在这个Object所在的class中寻找与seletor相应的方法，若找到，就跳至这个方法的实现执行
• 若找不到相应方法，就会按着继承的层次不断在该对象的所属class的父类寻找相应方法
• 若找不到，则进行 消息的前向处理

相对于C中对象方法的静态调用，objc_msgSend 做了更多事情，但这并不是整个程序性能的瓶颈所在，并且，objc_msgSend 还存在一个全局的cache map 进行消息调用结果的缓存 ，同一 class 的 同一方法 多次调用将会十分快速。
当然，在coding过程中，我们并不需要关心消息传递的实现细节，但这些可以帮助我们更好理解程序背后的运行机制，也能更好地理解后面讲的东东~

消息的前向处理

一个类只能理解已经在其内部定义好的消息，在objc的机制中，我们可以在runtime运行时在一个类中加入新的函数，因此我们的编译器无法完全阻止你向一个对象调用一个它并没定义的函数。比如说，我经常遇到的bug就是不小心把一个NSNumber当成NSString时，会发生以下悲剧

NSString *str = @(1);  

NSLog(@"%@",[str lowercaseString]);

程序会crash，并输出

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFNumber lowercaseString]: unrecognized selector sent to instance 0x8d71510' 

当这件不幸的事情发生时，这个对象就会调用其消息的前向机制，决定这个消息的去向。而以上的输出，是当对象的所有前向机制处理方法都没有处理该消息时，由基类 NSobject 的 doesNotRecognizeSeletor: 方法来输出控制台的这些信息，来告诉你没法处理的对象与消息。

处理未定义的消息，一个对象通常有两种途径：

1. 首先，这个对象会调用+ (BOOL)resolveInstanceMethod:(SEL)sel 来决定是否要通过往这个类加入新的方法来处理这个消息，若返回YES，则告诉编译器已经加入了相应的方法实现( 通过 class_addMethod(self,sel,(IMP),@"v@:@") 方法 )，能够再次调用该方法，否则，就进入前向处理的下一步。
2. 如果上一种方法返回NO，那对象将对于这个消息进行第二次处理，调用-(id)forwardingTargetForSelector:(SEL)aSelector这个函数返回了另一对象，告诉编译器发往本对象的消息可以扔给另一对象处理。这个方法有很多应用途径，一般可以返回自己所拥有的对象，这样在外部看起来就像自己能处理这个消息一样，高贵大气有内涵~
   当然，如果该函数返回nil时，就证明第二部也失败了，我们就进入了最终处理方法。
3. 到了这个地步，对象将调用最终的处理函数- (void):(NSInvocation *)anInvocation 可以看到，我们把这个消息包装成了 NSInvocation 对象，里面包含了消息的所有信息，这个函数完成了对于消息的最后分配。
   一般来说，在这个消息里，可以对消息进行重新分配，发往其他对象，不过这就和第二步的效果一样了，或者，可以修改这个消息的参数，或者消息名等等任意处理当我们已经没法处理这个消息时，需要调用父类的[super forwardInvocation:anInvocation];来处理，而层层处理后消息仍未被处理，则 NSObject 对于这个方法的实现将被调用，就会调用 doesNotRecognizeSeletor: 这个方法来抛出异常啦~

函数混淆 (Method Swizzling)

从以上我们可以得知，需要在运行时runtime ，编译器才能决定如何处理传给一个对象的消息，那么，我们也能够在运行时改变一个对象对消息的响应，这就是函数混淆。

一个类在编译器中拥有一张映射表，让动态消息传递系统能够通过方法名来找到响应的实现，这些实现是用一些叫做 IMPs 的函数指针进行储存的，就像这样id (*IMP)(id SEL,...) 而这个表在程序运行时能被修改，让这些方法名指向其他函数实现IMP，甚至指向自己实现的方法。主要通过两个方法：

method_exchangeImplementations(Method m1, Method m2);  

这个方法能够将两个方法名指向的函数指针交换;

class_getInstanceMethod(Class cls, SEL name);  

这个方法能够通过方法名和类名获取相应的函数指针，当然也有获取类方法的函数

class_getClassMethod(Class cls, SEL name);  

通过这两个方法，我们就能自由地交换方法名对应的函数实现，来实现函数混淆的效果。

Method yesMethod = class_getInstanceMethod([self class], @selector(sayYES));  
Method noMethod = class_getInstanceMethod([self class], @selector(sayNO));  
method_exchangeImplementations(yesMethod, noMethod);  

这样子 sayYES 与 sayNO 的方法实现就会交换。

函数混淆在调试程序时十分有效，它能够修改一些隐藏了实现的函数的指向，对其实现进行一些添加，并在全局造成影响。当然，对其的使用要慎重，毕竟影响了可读性，并且随意修改了原来的函数实现，很容易造成一系列的bug~