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匹配
先来看看类对象中保存的方法列表和方法的数据结构：
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。如果在缓存中已经有了需要的方法选标,则消息仅仅比函数调用慢一点点。如果程序运行了足够长的时间,几乎每个消息都能在缓存中找到方法实现。程序运行时,缓存也将随着新的消息的增加而增加。据牛人说（没有亲测过），苹果通过这些优化，使消息传递和直接的函数调用效率上的差距已经相当的小。
外面的风吹的太猛了点，北京的天气又是雾霾又是大风，真受不鸟
-------------未完待续-------------