大家都知道OC是一门动态语言，其动态性由底层的runtime库来支撑实现。OC所有的方法都是通过runtime来发送消息，当我们探讨消息发送，其实也就是在探讨OC方法的调用过程。
[receiver message];
这是我们很熟悉的一个OC方法的调用，大家都知道这个方法最终会被编译器转换为消息发送函数
objc_msgSend(receiver, @selector(message));
首先声明咱们这篇文章不去讲解具体的class的数据结构一类的细节问题，我们主要关注的是这个过程。
很遗憾，objc_msgSend的实现是用汇编写的，我并不能看懂。但是从runtime的源码中我发现了一个关键的方法：
//查找方法的实现
extern IMP lookUpImpOrForward(Class, SEL, id obj, bool initialize, bool cache, bool resolver);
我们要执行一个方法，其实最重要的就是找到这个方法的实现。下面我们来看一下这个lookUpImpOrForward函数的源码。
lookUpImpOrForward
通过源码中的注释可以看出来，主要的流程分为以下几个阶段：
无锁状态下从缓存中查找方法的实现
runtimeLock.assertUnlocked();
// Optimistic cache lookup
if (cache) {
imp = cache_getImp(cls, sel);
if (imp) return imp;
}
类的实现和初始化
// 判断类是否已经实现
if (!cls->isRealized()) {
realizeClass(cls);
}
// 是否初始化
if (initialize && !cls->isInitialized()) {
runtimeLock.unlock();
_class_initialize (_class_getNonMetaClass(cls, inst));
runtimeLock.lock();
在执行这两段代码之前还有两行代码，一个是runtimeLock.lock();，注释里面解释是通过加锁在遇到并发实现类的时候保护实现的过程。
另一个是checkIsKnownClass(cls);。看名字是检测这个类是不是我们已知的类，什么情况下可能出现我们未知的类呢？我猜测是通过NSClassFromString()来获取类的时候，如果class的string写错了，就会生成一个未知的类，这时候肯定找不到方法的实现，直接就crash掉行了。
我们的Class在底层其实是一个名为objc_class的结构体，大家可以去源码中看一下，这里我们不细说。执行realizeClass方法其实等于对类的第一次初始化，包括配置类的读写空间（class_rw_t）并且返回类的正确的结构体，就相当于搭好了这个类的框架。_class_initialize则是让类执行我们熟悉的+initialize方法。
加锁，查找
加锁
下面就要开始真正的IMP查找了，查找之前有一个runtimeLock.assertLocked();加锁。
注释中给出了解释，runtimeLock在查找方法的时候加锁，是为了保持method-lookup（查找方法）和 cache-fill（缓存填充）这两种方法的原子性，
// Otherwise, a category could be added but ignored indefinitely because
// the cache was re-filled with the old value after the cache flush on
// behalf of the category.
这几行注释我没读明白啥意思，感觉是说如果不加锁，有添加category的情况时，会导致缓存被冲洗掉。
在类中查找
通过代码可以看出，首先依然是从缓存中查找，然后在当前的类中查找，最后通过一个循环来从各级父类中查找。
这部分代码我们就不展示出来了，大家自己可以看源码，如果找到了这个方法的实现，我们看到会调用log_and_fill_cache这样一个方法，其实就是把这次查找缓存起来，方便下次使用。
如果没有找到就进入到下一个环节。
动态决议
这个名称大家应该是耳熟的，我们都知道消息转发机制，也就是说在我们调用了一个未实现的方法时，并不会直接crash掉，然后报unrecognized selector sent to instance错误。我们的系统会给我们两次机会，第一次就是动态决议。
if (resolver && !triedResolver) {
runtimeLock.unlock();
_class_resolveMethod(cls, sel, inst);
runtimeLock.lock();
// Don't cache the result; we don't hold the lock so it may have
// changed already. Re-do the search from scratch instead.
triedResolver = YES;
goto retry;
}
在OC层面最直接的表现形式就是看我们是否实现了+ (BOOL)resolveClassMethod:(SEL)sel或者+ (BOOL)resolveInstanceMethod:(SEL)sel方法（对应类方法和实例方法）。
void _class_resolveMethod(Class cls, SEL sel, id inst)
{
if (! cls->isMetaClass()) {//不是元类
// try [cls resolveInstanceMethod:sel]
_class_resolveInstanceMethod(cls, sel, inst);
}
else {
// try [nonMetaClass resolveClassMethod:sel]
// and [cls resolveInstanceMethod:sel]
_class_resolveClassMethod(cls, sel, inst);
if (!lookUpImpOrNil(cls, sel, inst,
NO/*initialize*/, YES/*cache*/, NO/*resolver*/))
{
_class_resolveInstanceMethod(cls, sel, inst);
}
}
}
根据cls是否为元类来调用_class_resolveInstanceMethod或_class_resolveClassMethod。
/***********************************************************************
* lookUpImpOrNil.
* Like lookUpImpOrForward, but returns nil instead of _objc_msgForward_impcache
**********************************************************************/
IMP lookUpImpOrNil(Class cls, SEL sel, id inst,
bool initialize, bool cache, bool resolver)
{
IMP imp = lookUpImpOrForward(cls, sel, inst, initialize, cache, resolver);
// 这个imp或者是一个正经的IMP指针,或者是一个汇编的入口
//_objc_msgForward_impcache 是一个汇编的入口 (看名字应该是消息转发相关的)
// 本方法是不进行消息转发的 ~ 所以如果获取到的IMP是这个入口,就直接return nil
if (imp == _objc_msgForward_impcache) return nil;
else return imp;
}
通过lookUpImpOrNil的源码我们知道，其实它封装了lookUpImpOrForward，不进行lookUpImpOrForward中最后的消息转发这一步，而且在这个if中，参数resolver传入了NO，也就是动态决议这一步也不进行，只进行了方法在本类和各级父类中的查找，如果找不到，则跟非元类一样执行_class_resolveInstanceMethod。
else中为什么要再执行这一段if代码，我不是很理解。
具体的动态决议实现的代码，我们看其中一个就行来看，用_class_resolveInstanceMethod当例子吧
static void _class_resolveInstanceMethod(Class cls, SEL sel, id inst)
{
if (! lookUpImpOrNil(cls->ISA(), SEL_resolveInstanceMethod, cls,
NO/*initialize*/, YES/*cache*/, NO/*resolver*/))
{
// Resolver not implemented.
// 没有找到SEL_resolveInstanceMethod(resolveInstanceMethod)方法
return;
}
// 下面应该是类型转换的代码而已吧？
BOOL (*msg)(Class, SEL, SEL) = (typeof(msg))objc_msgSend;
// 执行实现的+resolveInstanceMethod方法
bool resolved = msg(cls, SEL_resolveInstanceMethod, sel);
// Cache the result (good or bad) so the resolver doesn't fire next time.
// +resolveInstanceMethod adds to self a.k.a. cls
//通过+resolveInstanceMethod动态添加了方法，在进行一次查找
IMP imp = lookUpImpOrNil(cls, sel, inst,
NO/*initialize*/, YES/*cache*/, NO/*resolver*/);
if (resolved && PrintResolving) {
if (imp) {
_objc_inform("RESOLVE: method %c[%s %s] "
"dynamically resolved to %p",
cls->isMetaClass() ? '+' : '-',
cls->nameForLogging(), sel_getName(sel), imp);
}
else {
// Method resolver didn't add anything?
_objc_inform("RESOLVE: +[%s resolveInstanceMethod:%s] returned YES"
", but no new implementation of %c[%s %s] was found",
cls->nameForLogging(), sel_getName(sel),
cls->isMetaClass() ? '+' : '-',
cls->nameForLogging(), sel_getName(sel));
}
}
}
一开始先通过调用lookUpImpOrNil来查找是否已经实现了+resolveInstanceMethod，没有实现就直接返回了。
如果实现了，通过objc_msgSend来执行实现的+resolveInstanceMethod方法。
我们在+resolveInstanceMethod方法中都是动态的添加方法，所以在执行完之后在进行一次查找。
消息转发
如果在动态决议之后，依然没有找到方法，那我们还有最后一次机会，那就是消息转发。
imp = (IMP)_objc_msgForward_impcache;
cache_fill(cls, sel, imp, inst);
很遗憾_objc_msgForward_impcache汇编实现看不懂。不过我们还是可以从另一个方向来研究消息转发到底做了什么。
先补充一个骚操作，这也是我这两天刚学到的，就是打印runtime的代码执行日志，这么说可能不太贴切，反正就是能看到我们执行一个方法的过程中调用了哪些方法。
想要开始打印的地方加上下面代码
extern void instrumentObjcMessageSends(BOOL);
instrumentObjcMessageSends(YES);
想要关闭的地方加上下面代码
extern void instrumentObjcMessageSends(BOOL);
instrumentObjcMessageSends(NO);
当然还有别的方式，大家可以去查一下。
首先我们新建一个工程，类型就选择macOS->Common Line Tool。
因为我用iOS的工程不管用。
main函数中这样写
#import <Foundation/Foundation.h>
#import <objc/runtime.h>
#import "Sark.h"
int main(int argc, const char * argv[]) {
@autoreleasepool {
extern void instrumentObjcMessageSends(BOOL);
instrumentObjcMessageSends(YES);
Sark * test = [[Sark alloc] init];
[test performSelector:@selector(xxx)];
instrumentObjcMessageSends(NO);
}
return 0;
}
创建SEL选择子的时候我们故意穿进去一个xxx，就是为了让类找不到方法，然后走消息转发的的这个过程。
执行一下代码，运行时发送的所有消息都会打印到/private/tmp/msgSend-xxxx文件里了。(这是电脑系统的路径)
如果找起来不方便可以直接使用下面的命令行打开该文件。
open /private/tmp/
从该路径的msgSend-xxx文件中我们找到了这么一部分代码
+ Sark NSObject initialize
+ Sark NSObject alloc
- Sark NSObject init
- Sark NSObject performSelector:
+ Sark NSObject resolveInstanceMethod:
+ Sark NSObject resolveInstanceMethod:
- Sark NSObject forwardingTargetForSelector:
- Sark NSObject forwardingTargetForSelector:
- Sark NSObject methodSignatureForSelector:
- Sark NSObject methodSignatureForSelector:
- Sark NSObject class
- Sark NSObject doesNotRecognizeSelector:
- Sark NSObject doesNotRecognizeSelector:
- Sark NSObject class
我们可以看到在执行完了resolveInstanceMethod之后又执行forwardingTargetForSelector:和methodSignatureForSelector:，最后才因为找不到方法执行doesNotRecognizeSelector:。
现在我们可以大概了解在消息转发的过程中执行了哪些方法了，经过查阅资料我们得出：
全部的消息转发过程做了如下几件事：（包括动态决议+消息转发）
调用resolveInstanceMethod:方法，允许用户在此时为该Class动态添加实现。如果有实现了，则调用并返回。如果仍没实现，继续下面的动作。
调用forwardingTargetForSelector:方法，尝试找到一个能响应该消息的对象。如果获取到，则直接转发给它。如果返回了nil，继续下面的动作。
调用methodSignatureForSelector:方法，尝试获得一个方法签名。如果获取不到，则直接调用doesNotRecognizeSelector抛出异常。
调用forwardInvocation:方法，将地3步获取到的方法签名包装成Invocation传入，如何处理就在这里面了。
上面这4个方法均是模板方法，开发者可以override，由runtime来调用。
具体如何重写使用这几个方法，大家可以自己查一下。
