在Objective-C中, 如果向某对象传递消息, 那就会使用动态绑定机制来决定需要调用的方法. 在底层, 所有方法都是普通的C语言函数, 然而对象收到消息之后, 究竟该调用哪个方法则完全于运行期决定, 甚至可以在程序运行时改变, 这些特性使得Objective-C 成为一门真正的动态语言.
id returnValue = [someObject messageName:parameter];
在本例中, someObject叫做"接收者"(receiver), messageName叫做"选择子"(selector). 选择子与参数合起来称为"消息"(messge). 编译器看到此消息后, 将其转换为一条标准的C语言函数调用, 所调用的函数乃是消息传递机制中的核心函数, 叫做 objc_msgSend, 其"原型"(prototype) 如下:
void objc_msgSend(id self, SEL cmd, ...)
第一个参数代表接收者, 第二个参数代表选择子(SEL 是选择子的类型), 后续参数就是消息中的那些参数, 其顺序不变
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) 那样迅速
objc_msgSend_stret. 如果待发送的消息要返回结构体, 那么可交由此函数处理. 只有当CPU的寄存器能够容纳得下消息返回类型时, 这个函数才能处理此消息. 若是返回值无法容纳于CPU 寄存器中 (比如说返回的结构体太大了) , 那么就由另一个函数执行派发. 此时, 那个函数会通过分配在栈上的某个变量来处理消息所返回的结构体.
objc_msgSend_fpret. 如果消息返回的是浮点数, 那么可交由此函数处理. 在某些架构的CPU 中调用函数时, 需要对"浮点数寄存器" (floating-point register) 做特殊处理, 也就是说, 通常所用的 objc_msgSend 在这种情况下并不合适. 这个函数是为了处理x86等架构CPU中某些令人稍觉惊讶的奇怪状况.
objc_msgSendSuper. 如果要给超类发消息, 例如[super message:parameter], 那么就交由此函数处理. 也有别外两个与objc_msgSend_stret和 objc_msgSend_fpret 等效的函数, 用于处理发给super 的相应消息
每个类里都有一张表格, 其中的指针都会指向这种函数, 而选择子的名称则是查表时所用的"键". objc_msgSend 等函数正是通过这张表格来寻找应该执行的方法并跳至其实现的.
尾调用优化
如果某函数的最后一项操作是调用别外一个函数, 那么就可以运用"尾调用优化"技术. 编译器会生成调转至另一函数所需的指令码, 而且不会向调用堆栈中推入新的"栈帧" (frame stack). 只有当某函数的最后一个操作仅仅是调用其他函数而不会将其返回值另作他用时, 才能执行"尾调用优化". 这项优化对 objc_msgSend 非常关键, 如果不这么做的话, 那么每次调用 Objective-C 方法之前, 都需要为调用 objc_msgSend 函数准备 "栈帧", 大家在"栈踪迹" (stack trace) 中可以看到这种"栈帧". 此外, 若是不优化, 还会过早地发生"栈溢出" (stack overflow) 现象
