iOS 源码解析 - Runtime篇(1)

objc-runtime 开源地址

在Objective-C中runtime主要充当了一个消息传递者，但其实它还有很多更加强大的特性。

工程打开之后可以看到如下结构

• Public Headers 部分 这是我们平常能够用到的api包括
  • NSObjCRuntime.h
  • NSObject .h NSObject类的本体，Foundation里也有Foundation/NSObject.h 但里面只是一些分类和protocol
  • message.h
  • objc-api.h
  • objc-auto.h
  • objc-sync.h
  • objc-exception.h
  • objc.h
  • runtime.h

我们主要从上述几个头文件来展开源码阅读。

1.我们先从最熟悉的NSObject.h 类开始。与runtime相关的首先是两个属性:

Class isa  OBJC_ISA_AVAILABILITY; 
Class superclass;

我们用一张图说明它们无与伦比的重要性！

20170307194653265.png

由于oc设计模式也是基于原型模式，所以在oc中一切皆对象的说法也适用。

可以看到NSObject的继承体系离不开这两条线，isa指针负责 "横向指向"，superclass指针负责 "纵向指向"。runtime的方法调用大部分也是依托于它们来获取方法列表。具体会在runtime的消息机制部分涉及。

这里有人可能会问，Instance of Subclass的superclass指针指向哪里呢？
我们可以在源码中找到答案：
- (Class)superclass {
    return [self class]->superclass;
}
- (Class)class {
    return object_getClass(self);
}
Class object_getClass(id obj){
    if (obj) return obj->getIsa();
    else return Nil;
}
可以看到其实实例对象通过isa指着获取当前类对象，然后直接拿到类对象的superclass 所以他们是共用的一个superclass

其实Instance of Subclass属于另外一种类型:

struct objc_object {
private:
    isa_t isa;
}

2. 除了上边两个属性，NSObject.h中还有几个方法和runtime关系密切！

• 我们先说定义在名为NSObject protocol中的方法:

- (id)performSelector:(SEL)aSelector;
- (id)performSelector:(SEL)aSelector withObject:(id)object;
- (id)performSelector:(SEL)aSelector withObject:(id)object1 withObject:(id)object2;

- (BOOL)respondsToSelector:(SEL)aSelector;

前三者的实现大同小异

- (id)performSelector:(SEL)sel {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL))objc_msgSend)(self, sel);
}

- (id)performSelector:(SEL)sel withObject:(id)obj {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL, id))objc_msgSend)(self, sel, obj);
}

- (id)performSelector:(SEL)sel withObject:(id)obj1 withObject:(id)obj2 {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL, id, id))objc_msgSend)(self, sel, obj1, obj2);
}

先判断SEL类型的参数是否存在，SEL类型是一个方法签名。我们可以用这两个方法来获取SEL:

 NSSelectorFromString(@"selectorName");
 @selector(selectorName);

关于SEL的生成方法，可能由于不同框架下的生成方法不一致，苹果并没有给出具体的实现，但是在objc-sel.mm文件中我们可以看到一个类似实现，这也说明了SEL的本质其实就是单纯对方法名字的一个定向处理:

static SEL sel_alloc(const char *name, bool copy)
{
    selLock.assertWriting();
    return (SEL)(copy ? strdup(name) : name);    
}

通过这个SEL当做key来寻找具体的函数实现地址（即IMP）；

值得一提的是每次创建SEL前都会从namedSelectors这个NXMapTable hash表中去查找缓存下来的SEL,如果这里面没有找到才会去在内存中创建，并且插入到缓存表中。

我们再回退到刚才的三个方法中。
当SEL不存在的时候，会触发

 - (void)doesNotRecognizeSelector:(SEL)sel {
    _objc_fatal("-[%s %s]: unrecognized selector sent to instance %p", 
                object_getClassName(self), sel_getName(sel), self);
}

最终打印log日志，生成crash日志，调用__builtin_trap函数触发内核陷阱，交还控制权，安全退出程序。

_objc_syslog(buf2); 
_objc_crashlog(buf2);
_objc_trap();

接下来如果SEL存在，则调用objc_msgSend()函数，runtime中最重要的函数！
这个函数真正开启了runtime的消息机制！苹果源码里给出了它的汇编代码的实现。篇幅有限，下篇见。

NSObject.mm 中还有很多内容，比如Autorelease pool的实现，准备在Runloop篇在进行阅读。
另外还有一些针对于Swift的处理，笔者会选择性的忽略它，放到以后Swift篇中说明。