从消息发送（方法调用）看Objective-C的运行时

原文网址：http://www.cocoachina.com/ios/20141212/10616.html

前言：Objective-C是一门动态语言，可以在运行的时候动态决定调用哪个方法实现，甚至增加、替换方法的具体实现，而这些都归功于Objective-C的运行时（runtime）系统。本篇文章，我们就从消息发送的角度来看下Objective-C的运行时。

0. 决定方法调用的动态性

Objective-C语言是一门面向对象编程语言，而面向对象的一个基本特征就是多态。在一个复杂的类的继承层次结构中，子类可以和父类具有同名的方法（override），父类的引用也可以接受子类对象。而在这种情况下，调用父类引用的方法（或者说发送某个消息），那么如果这个方法在父类和子类中的实现逻辑不同，哪种实现会被执行呢，答案自然应该是子类的实现逻辑被调用执行。这是面向对象语言的基本特性之一。

C作为一门非面向对象语言，肯定是不支持这些的，而建立在C基础之上的Objective-C通过运行时库做到了这点。比如有两个类，ParentClass和它的子类SonClass，具有同名不同实现的无参实例方法（“-”）doSomething，instance是一个ParentClass*类型引用，但却被指向了一个SonClass的实际对象。那么调用[instance doSomething]; 毫无疑问会执行SonClass里的逻辑。

这怎么做到？这正是通过Objective-C运行时对消息发送的分派机制。赘言无益，看看下面一段代码就明白了：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

void funcA() {    printf("hello world!\n"); }    void funcB() {    printf("world hello!\n"); }    void receiveMessage() {    void (*function)();    if ( shouldFunctionAorB )    {       function = &funcA;    }    else    {       function = &funcB;    }    (*function)(); }

这是一段C语言代码，使用了函数指针，函数主体逻辑在receiveMessage函数里，它通过运行时shouldFunctionAorB变量的状态选择最终执行funcA还是funcB。

虽然本人未看过Objective-C运行时库的源代码，但相信其实现的方式与此并无太大区别，原理就是如此。而决定运行时执行哪个方法实现的条件可能会比较复杂，但runtime肯定是可以得到并以此决断的。

1. SEL和IMP

使用过UIControl的朋友应该知道addTarget:action:forControlEvents:这个方法，里面的action参数通常用到一个@selector()，而这个语句的结果就是得到了一个SEL变量。SEL变量我们就叫做一个selector。Selector其实很好理解，就是在发送消息/方法调用时标识是哪个消息（方法）的东西。这个通常都是通过方法全名得来的，就比如上面UIControl的（addTarget:action:forControlEvents:）。

IMP实际上就是具体的一个方法逻辑实现（implementation，貌似IMP就是这么来的）。这个和上面代码示例中的C语言函数指针概念相似。到funcA的指针和到funcB的指针都是IMP变量。

Obejctive-C的运行时系统提供的消息的分派机制把SEL和IMP关联起来。但每次消息发送/方法调用都做一遍查找显然是很麻烦很低效的，所以在Objective-C的runtime这里一定是有缓存机制的， 使得对每个类特定selector对应的IMP可以很快找到。

当然，即使用最好的数据结构和最快的查找算法，和直接执行C函数调用的静态绑定方式相比，也一定有性能损失。但比起Objective-C运行时为开发者提供的诸多动态特性相比，这些都是值得的。

2. objc_msgSend

0中的代码例子中阐述了Objective-C中消息发送的原理，而1中也解释了SEL和IMP的概念。那么当这一切都清楚了的时候，实际消息发送的时候是怎么操作的呢？那就是通过objc_msgSend这一系列的运行时C函数调用来做到的了。

在苹果官方文档《Objective-C Runtime Programming Guide》中提出和Objective-C运行时交互有三种方式，其中最底层的一种方式就是直接使用runtime的函数。我们下面就来看下和发送消息直接相关的几个函数：

1 2 3 4 5

objc_msgSend objc_msgSend_fpret objc_msgSend_stret objc_msgSendSuper objc_msgSendSuper_stret

我们看到他们都是以objc_msgSend开头的，也就是Objective-C“消息发送”的意思，我们就来看最基础的，也就是第一个。

1	id objc_msgSend ( id self, SEL op, ... );

我们看到后面有self、op和变长参数列表。我们知道对于不同的两个Objective-C的类对象，执行消息发送结果可能是不同的，那么第一个参数id类型的参数self就是用来标识不同对象的，而SEL的op就是标识发送哪个消息/调用哪个方法的selector，后面的变参我们其实可以猜想到，就是selector对应方法的实际参数。

而具体找IMP的过程显然被包装在objc_msgSend里面，或者说selector和IMP的对应关系被运行时系统记录了下来，无需objc_msgSend的调用者直接关注。

这样看来，这个objc_msgSend实际上就相当于0中示例代码的receiveMessage函数了。

上面列表中objc_msgSend一族的其它几个函数其实功能上是差不多的：

1) 带有ret结尾的标识返回值在某些情况下可以特殊处理（比如使用处理器的寄存器存储而非开辟栈空间），以进行优化。

2) 带有super的标识的回去找id参数的父类。关于怎么找一个Objective-C的当前类和父类，本小站后面的技术文章会找机会解释。

3. Method swizzling

上问提到了SEL和IMP的对应关系，那么这个能不能改呢？了解运行时机制除了知道objc_msgSend原理和怎么调用外还有什么意义？Method swizzling就是两个问题的一个很好的答案。

Method swizzling比较直接的翻译就是方法（实现）交换（“搅合”）。下面是一个简单的例子（源自《Effective Objective-C》）：

1 2 3

Method originalMethod = class_getInstanceMethod([NSString class],@selector(lowercaseString)); Method swappedMethod = class_getInstanceMethod([NSString class], @selector(uppercaseString)); method_exchangeImplementations(originalMethod, swappedMethod);

这样，NSString之后的lowercaseString和uppercaseString就是相反的效果了！

方法实现的交换可以有很多应用场景，尤其在调试系统库等领域。

4. 消息转发

我不知道阅读本文的朋友们在开发调试时有没有遇到过“unrecognized selector”这个异常。这个错误提示告诉我们在程序运行时调用的方法没找到对应的实现，通常一个app就这样直接crash了。而其实这个情况系统是做过处理尝试的，最终这个异常也是系统库中NSObject的方法实现抛出来的。

这一段我们整理下Objective-C运行时中的消息转发机制，然后我们就明白上面这个异常提示是怎么出来的了。

消息转发通常是在Objective-C运行时系统找不到一个selector对应的实现时，这时候系统会回过来询问这个对象所属的类应该怎么做，主要分为几步：

1) 要不要对此次消息调用（实例方法/类方法）做动态解析和执行处理。这个我们可以通过class_addMethod函数，给这个类一个IMP，这样就可以去执行了。很多@dynamic的标记就需要这么配合来做。

2) 不做动态解析，那么是否转移消息给别的对象，转给谁。

3) 不转给别的对象，那么这次消息发送通过调用哪个Invocation对象来处理。

如上过程可参看如下取自《Effective Objective-C》的截图：

实际上，所有类的forwardInvocation方法都从NSObject那里继承到了，而其会调用：

1	- (void)doesNotRecognizeSelector:(SEL)aSelector;

除了这些，消息转发很强大，用好了大有作为，比如可以做到类似C++中多继承的一些效果。