Objective-C runtime之消息传递机制（3）

Objective-C runtime之消息传递机制（三）

前边两篇文章，主要介绍了Objective-C的runtime system以及message相关的一些概念上的东西，都是为今天要说的东西做铺垫。

五、消息调用流程
一切还是从消息表达式[receiver message]开始，在被转换成objc_msgSend(receiver, SEL)后，在运行时，runtime system会做以下事情：

1、检查忽略的Selector，比如当我们运行在有垃圾回收机制的环境中，将会忽略retain和release消息。

2、检查receiver是否为nil。不像其他语言，nil在objective-C中是完全合法的，并且这里有很多原因你也愿意这样，比如，至少我们省去了给一个对象发送消息前检查对象是否为空的操作。如果receiver为空，则会将 selector也设置为空，并且直接返回到消息调用的地方。如果对象非空，就继续下一步。

3、接下来会根据SEL到当前类中查找对应的IMP，首先会在cache中检索它，如果找到了就根据函数指针跳转到这个函数执行，否则进行下一步。

4、检索当前类对象中的方法表（method list），如果找到了，加入cache中，并且就跳转到这个函数之行，否则进行下一步。

5、从父类中寻找,直到根类：NSObject类。找到了就将方法加入对应类的cache表中，如果仍为找到，则要进入第七项介绍的内容：动态方法决议。

6、如果动态方法决议仍不能解决问题，只能进行最后一次尝试，进入消息转发流程。

7、如果还不行，去死吧。

下面的图部分展示了这个调用过程：

写到这大家肯定会发出这样的疑问：我仅仅想调用一个方法而已，却不得不经历那么多步骤，效率上怎么保证？？苹果也做了一些优化上的工作。

六、函数检索优化措施

主要从下面两个方面着手：

1、通过SEL进行IMP匹配

先来看看类对象中保存的方法列表和方法的数据结构：

typedef struct method_list_t {
    uint32_t entsize_NEVER_USE;  
    uint32_t count;
    struct method_t first;
} method_list_t;

typedef struct method_t {
    SEL name;
    const char *types;//参数类型和返回值类型
    IMP imp;
} method_t;

在前一篇文章介绍SEL的时候，我们已经说过了苹果在通过SEL检索IMP时做的努力，这里不再累述。

2、cache缓存

cache的原则就是缓存那些可能要执行的函数地址，那么下次调用的时候，速度就可以快速很多。这个和CPU的各种缓存原理相通。好吧，说了这么多了，再来认识几个名词：

struct objc_cache {
    uintptr_t mask;            
    uintptr_t occupied;        
    cache_entry *buckets[1];
};

typedef struct {
    SEL name;     
    void *unused;
    IMP imp;  
} cache_entry;

看这个结构，有没有搞错又是hash table。
objc_msgSend 首先在cache list 中找SEL，没有找到就在class method中找，super class method中找（当然super class 也有cache list）。而cache的机制则非常复杂了，由于Objective-C是动态语言。所以，这里面还有很多的多线程同步问题，而这些锁又是效率的大敌，相关的内容已经远远超过本文讨论的范围。

如果在缓存中已经有了需要的方法选标,则消息仅仅比函数调用慢一点点。如果程序运行了足够长的时间,几乎每个消息都能在缓存中找到方法实现。程序运行时,缓存也将随着新的消息的增加而增加。据牛人说（没有亲测过），苹果通过这些优化，使消息传递和直接的函数调用效率上的差距已经相当的小。

外面的风吹的太猛了点，北京的天气又是雾霾又是大风，真受不鸟

-------------未完待续-------------