对iOS runtime的一点理解（1）

在我刚刚接触iOS开发的时候，我一直很奇怪，为什么OC把方法调用称作“发送消息”呢。后来，我还发现，有些方法即便只有声明没有实现，也可以被“调用”，只是在运行时会崩溃。再后来，我还发现了selector这个神奇的东西，却不甚明白它是做什么用的。就那么稀里糊涂的做了大半年小码农，直到有一天我看了runtime programming guide这篇文档，才开始明白我以前疑惑的到底是什么。

在OC中，消息是直到运行时才被绑定在方法实现上的。

在编译的过程中，编译器会把一个消息表达式转换成对objc_msgSend方法的调用。objc_msgSend方法会以接收消息的对象（receiver）和消息的方法名（selector）作为两个主要的参数，再加上消息本身带有的参数。比如：

[receiver message];

就会被转化成：

objc_msgSend(receiver, selector);

当程序运行的时候，运行时系统会根据传入objc_msgSend方法的receiver和selector来查找应该被执行的过程。也就是说，具体哪段代码被执行是由receiver和selector这两者共同决定的。

那么怎么根据receiver和selector来查找对应的过程呢？
发送消息的关键就是，编译器给每个类和每个对象都构建了一个结构。每个类的结构都包含了一个指向自己父类的指针，和一个分发表。分发表中存放着这个类的每个selector和这个selector对应的过程的入口。

而当一个继承自NSObject或NSProxy的对象被创建的时候，在对象的变量中，还有一个指向它对应的类结构的指针，这个指针叫做isa。所以，当得知receiver时，objc_msgSend方法会通过receiver的isa指针找到它对应的类的结构，并查找这个类的分发表中是否有需要的selector。如果没有找到，则沿着指向父类的指针，去父类的分发表中查找。

为了加速这个过程，运行时系统会为每个类缓存selector和对应的方法的地址。每个类都有一个这样的cache，其中存放的不仅有它本身的方法，还有它继承的方法。

如果objc_msgSend方法找到了这个过程，它会调用这个过程，并且传递所有的参数以及两个隐藏参数：receiver和selector。正是因为传递了这两个隐藏参数，程序员才能在OC源代码中使用self和_cmd。

唯一一个能绕过晚绑定的方式，就是直接得到某个方法的地址，然后像调用函数一样调用它。NSObject中有一个方法methodForSelector:，它可以直接返回对应方法的函数指针。
注意，在调用这个函数指针的时候，也需要传递receiver和selector的这两个隐藏参数。
这是苹果的一段示例代码：

void (*setter)(id, SEL, BOOL);
int i;
 
setter = (void (*)(id, SEL, BOOL))[target
    methodForSelector:@selector(setFilled:)];
for ( i = 0 ; i < 1000 ; i++ )
    setter(targetList[i], @selector(setFilled:), YES);

那么如果objc_msgSend没有找到对应的方法呢？接下来会有动态方法和消息转发两个机会，就放在下一篇博客里讲吧。

以上就是基于我的理解大致复述了一下苹果官方文档，而下面是我自己的一些实验和理解。

关于self和_cmd

我相信是个OC程序员都用过self，因为它是用来指代“当前的对象”的。而_cmd我还是在读这篇文档的时候第一次听说，是“当前这个方法的selector”。
以前我从来没有考虑过self是从哪里来的，当然更没考虑过_cmd是从哪里来的。但是看完这篇文档后又看了一些blog后，我知道了它们实际上是objc_msgSend方法中，传递给这个方法的函数指针的两个隐藏参数。
既然通过methodForSelector:可以直接得到这个函数指针，那也就是说，程序员也可以自己给这个函数指针传递receiver和selector这两个隐藏参数。
所以我做了这个实验：

#import <Foundation/Foundation.h>

@interface XSQObject : NSObject

@end

@implementation XSQObject

- (void)runtimeTest {
    NSLog(@"self: %@", [self class]);
    NSLog(@"_cmd: %@", NSStringFromSelector(_cmd));
    NSLog(@"----------------------");
}

- (void)randomMethod {
    NSLog(@"random Method");
}

@end

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        
        //正常的发送消息
        XSQObject *xsqObj = [XSQObject new];
        [xsqObj runtimeTest];
        
        //绕过晚绑定，自己获取函数指针
        void (*function)(id, SEL) = (void(*)(id, SEL))[xsqObj methodForSelector:@selector(runtimeTest)];
        NSObject *obj = [NSObject new];
        function(obj, @selector(randomMethod));

    }
    return 0;
}

得到了这样的输出结果：

2015-04-21 18:19:26.022 XSQRuntimeDemo[2378:303] self: XSQObject
2015-04-21 18:19:26.024 XSQRuntimeDemo[2378:303] _cmd: runtimeTest
2015-04-21 18:19:26.024 XSQRuntimeDemo[2378:303] ----------------------
2015-04-21 18:19:26.025 XSQRuntimeDemo[2378:303] self: NSObject
2015-04-21 18:19:26.025 XSQRuntimeDemo[2378:303] _cmd: randomMethod
2015-04-21 18:19:26.025 XSQRuntimeDemo[2378:303] ----------------------

第一次正常的消息发送得到了正常的输出结果，即self的类型就是当前对象的类型，_cmd的名字也是当前方法的名字。而第二次，绕过晚绑定时，self的类型不再是当前对象的类型了，而_cmd的名字也不再是自己方法的名字了。

这也就验证了，self和_cmd只是形参，只是运行时系统会“恰好”把正确的receiver和正确的selector传递过去。

知道了self的本质，那么super又是什么呢？看了这篇文章：刨根问底ObjectiveC Runtime（1）觉得好好厉害0.0
http://chun.tips/blog/2014/11/05/bao-gen-wen-di-objective%5Bnil%5Dc-runtime(1)%5Bnil%5D-self-and-super/