iOS之武功秘籍⑥：Runtime之方法与消息

iOS之武功秘籍 文章汇总

写在前面

上文说到cache_t缓存的是方法，我们分析了cache的写入流程，在写入流程之前，还有一个cache读取流程，即objc_msgSend 和 cache_getImp.那么方法又是什么呢？这一切都要从Runtime开始说起...

本节可能用到的秘籍Demo

一、Runtime

① 什么是Runtime？

Runtime是一套API，由c、c++、汇编一起写成的，为OC提供了运行时.

• 运行时：代码跑起来，将可执行文件装载到内存
• 编译时：正在编译的时间——翻译源代码将高级语言（OC、Swift）翻译成机器语言（汇编等），最后变成二进制

② Runtime版本

Runtime有两个版本——Legacy和Modern，苹果开发者文档都写得清清楚楚

源码中-old、__OBJC__代表Legacy版本，-new、__OBJC2__代表Modern版本，以此做兼容

③ Runtime的作用及调用

Runtime底层经过编译会提供一套API和供FrameWork、Service使用

Runtime调用方式：

• Runtime API，如 sel_registerName(),class_getInstanceSize
• NSObject API，如 isKindOf()
• OC上层方式，如 @selector()

原来平常在用的这么多方法都是Runtime啊，那么方法究竟是什么呢？

二、方法的本质

① 研究方法

通过clang编译成cpp文件可以看到底层代码，得到方法的本质

• 兼容编译（代码少）：clang -rewrite-objc main.m -o main.cpp
• 完整编译（不报错）：xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc main.m -o main-arm64.cpp或xcrun -sdk iphonesimulator clang -arch arm64 -rewrite-objc main.m -o main-arm64.cpp

② 代码转换

• ((TCJPerson *(*)(id, SEL))(void *)是类型强转
• (id)objc_getClass("TCJPerson")获取TCJPerson类对象
• sel_registerName("alloc")等同于@selector()

即可以理解为((类型强转)objc_msgSend)(对象, 方法调用)

③ 方法的本质

方法的本质是通过objc_msgSend发送消息，id是消息接收者，SEL是方法编号.

注意:如果外部定义了C函数并调用如void sayHello() {}，在clang编译之后还是sayHello()而不是通过objc_msgSend去调用.因为发送消息就是找函数实现的过程，而C函数可以通过函数名——指针就可以找到.

为了验证，通过objc_msgSend方法来完成[person sayHello]的调用，查看其打印是否是一致.

其打印结果如下，发现是一致的，所以 [person sayHello]等价于objc_msgSend(person,sel_registerName("sayHello"))

这其中需要注意两点:

• 1、直接调用objc_msgSend，需要导入头文件#import
• 2、需要将target --> Build Setting -->搜索msg -- 将enable strict checking of obc_msgSend calls由YES 改为NO，将严厉的检查机制关掉，否则objc_msgSend的参数会报错
  

④ 向不同对象发送消息

子类TCJTeacher有实例方法sayHello、sayNB, 类方法sayNC

父类TCJPerson有实例方法sayHello、sayCode, 类方法sayNA

① 发送实例方法

消息接收者——实例对象

② 发送类方法

③ 对象方法调用-实际执行是父类的实现

注意前面的细节:父类TCJPerson中实现了sayHello方法,而子类TCJTeacher没有实现sayHello方法.现在我们可以尝试让teacher调用sayHello执行父类中实现，通过objc_msgSendSuper实现.

因为objc_msgSend不能向父类发送消息，需要使用objc_msgSendSuper，并给objc_super结构体赋值（在objc2中只需要赋值receiver、super_class)

receiver——实例对象；super_class——父类类对象

发现不论是[teacher sayHello]还是objc_msgSendSuper都执行的是父类中sayHello的实现，所以这里，我们可以作一个猜测：方法调用，首先是在类中查找，如果类中没有找到，会到类的父类中查找.

④ 向父类发送实例方法

receiver——实例对象；super_class——父类类对象

⑤ 向父类发送类方法

receiver——类对象；super_class——父类元类对象

三、消息查找流程

消息查找流程其实是通过上层的方法编号sel发送消息objc_msgSend找到具体实现imp的过程

objc_msgSend是用汇编写成的，至于为什么不用C而是用汇编写，是因为：

• C语言不能通过写一个函数，保留未知的参数，跳转到任意的指针，而汇编有寄存器
• 对于一些调用频率太高的函数或操作，使用汇编来实现能够提高效率和性能，容易被机器来识别

① 开始查找

打开objc4源码，由于主要研究arm64结构的汇编实现，来到objc-msg-arm64.s,先附上其汇编整体执行的流程图

p0表示0寄存器的指针，x0表示它的值，w0表示低32位的值（不用过多在意）

• ①开始objc_msgSend
• ②判断消息接收者是否为空，为空直接返回
• ③判断tagged_pointers（之后会讲到）
• ④取得对象中的isa存一份到p13中
• ⑤根据isa进行mask地址偏移得到对应的上级对象（类、元类）
  

查看GetClassFromIsa_p16定义，主要就是进行isa & mask得到class操作

• ⑥开始在缓存中查找imp——开始了快速流程

② 快速查找流程

从CacheLookup开始了快速查找流程（此时x1是sel，x16是class）

• ①通过cache首地址平移16字节（因为在objc_class中，首地址距离cache正好16字节，即isa首地址 占8字节，superClass占8字节），获取cahce，cache中高16位存mask，低48位存buckets，即p11 = cache
• ②从cache中分别取出buckets和mask，并由mask根据哈希算法计算出哈希下标
  • 通过cache和掩码（即0x0000ffffffffffff）的 & 运算，将高16位mask抹零，得到buckets指针地址，即p10 = buckets
  • 将cache右移48位，得到mask，即p11 = mask
  • 将objc_msgSend的参数p1（即第二个参数_cmd）& msak,通过哈希算法，得到需要查找存储sel-imp的bucket下标index，即p12 = index = _cmd & mask,为什么通过这种方式呢？因为在存储sel-imp时，也是通过同样哈希算法计算哈希下标进行存储，所以读取也需要通过同样的方式读取,如下所示
    

• ③根据所得的哈希下标index 和 buckets首地址，取出哈希下标对应的bucket
  • 其中PTRSHIFT等于3，左移4位（即2^4 = 16字节）的目的是计算出一个bucket实际占用的大小,结构体bucket_t中sel占8字节，imp占8字节
  • 根据计算的哈希下标index 乘以 单个bucket占用的内存大小，得到buckets首地址在实际内存中的偏移量
  • 通过首地址 + 实际偏移量，获取哈希下标index对应的bucket
• ④根据获取的bucket，取出其中的imp存入p17，即p17 = imp，取出sel存入p9，即p9 = sel
• ⑤第一次递归循环
  • 比较获取的bucket中sel 与 objc_msgSend的第二个参数的_cmd(即p1)是否相等
  • 如果相等，则直接跳转至CacheHit，即缓存命中，返回imp
  • 如果不相等，有以下两种情况
    • 如果一直都找不到，直接跳转至CheckMiss，因为$0是normal，会跳转至__objc_msgSend_uncached，即进入慢速查找流程
    • 如果根据index获取的bucket 等于 buckets的第一个元素，则人为的将当前bucket设置为buckets的最后一个元素（通过buckets首地址+mask右移44位（等同于左移4位）直接定位到bucker的最后一个元素），然后继续进行递归循环（第一个递归循环嵌套第二个递归循环），即⑥
    • 如果当前bucket不等于buckets的第一个元素，则继续向前查找，进入第一次递归循环
• ⑥第二次递归循环：重复⑤的操作，与⑤中唯一区别是，如果当前的bucket还是等于 buckets的第一个元素，则直接跳转至JumpMiss，此时的$0是normal，也是直接跳转至__objc_msgSend_uncached，即进入慢速查找流程

以下是整个快速查找过程值的变化过程流程图

③ 慢速查找流程

① 慢速查找-汇编部分

在快速查找流程中，如果没有找到方法实现，无论是走到CheckMiss还是JumpMiss，最终都会走到__objc_msgSend_uncached汇编函数

• 在objc-msg-arm64.s文件中查找__objc_msgSend_uncached的汇编实现，其中的核心是MethodTableLookup（即查询方法列表），其源码如下
  

• 搜索MethodTableLookup的汇编实现，其中的核心是_lookUpImpOrForward，汇编源码实现如下
  

验证
上述汇编的过程，可以通过汇编调试来验证

• 在main中，例如[person sayHello]对象方法调用处加一个断点，并且开启汇编调试【Debug -- Debug worlflow -- 勾选Always show Disassembly】，运行程序

  

• 汇编中objc_msgSend加一个断点，执行断住，按住control + stepinto，进入objc_msgSend的汇编

  

• 在_objc_msgSend_uncached加一个断点，执行断住，按住control + stepinto，进入汇编

  

从上可以看出最后走到的就是lookUpImpOrForward，此时并不是汇编实现.

注意

• 1、C/C++中调用 汇编 ，去查找汇编时，C/C++调用的方法需要多加一个下划线
• 2、汇编 中调用 C/C++方法时，去查找C/C++方法，需要将汇编调用的方法去掉一个下划线

② 慢速查找-C/C++部分

根据汇编部分的提示，全局续搜索lookUpImpOrForward，最后在objc-runtime-new.mm文件中找到了源码实现，这是一个c实现的函数

其整体的慢速查找流程如图所示

慢速流程主要分为几个步骤：

• ①cache缓存中进行查找，即快速查找，找到则直接返回imp，反之，则进入②
• ②判断cls
  • 是否是已知类，如果不是，则报错
  • 类是否实现，如果没有，则需要先实现，确定其父类链，此时实例化的目的是为了确定父类链、ro、以及rw等，方便后续数据的读取以及查找的循环
  • 是否初始化，如果没有，则初始化
• ③for循环，按照类继承链 或者 元类继承链的顺序查找
  • 当前cls的方法列表中使用二分查找算法查找方法，如果找到，则进入cache写入流程（在iOS之武功秘籍⑤：cache_t分析文章中已经详述过），并返回imp，如果没有找到，则返回nil
  • 当前cls被赋值为父类，如果父类等于nil，则imp = 消息转发，并终止递归，进入④
  • 如果父类链中存在循环，则报错，终止循环
  • 父类缓存中查找方法
    • 如果未找到，则直接返回nil，继续循环查找
    • 如果找到，则直接返回imp，执行cache写入流程
• ④判断是否执行过动态方法解析
  • 如果没有，执行动态方法解析
  • 如果执行过一次动态方法解析，则走到消息转发流程

以上就是方法的慢速查找流程，下面在分别详细解释二分查找原理 以及 父类缓存查找详细步骤

getMethodNoSuper_nolock方法：二分查找方法列表

查找方法列表的流程如下所示

其二分查找核心的源码实现如下

算法原理简述为：从第一次查找开始，每次都取中间位置，与想查找的key的value值作比较，如果相等，则需要排除分类方法，然后将查询到的位置的方法实现返回，如果不相等，则需要继续二分查找，如果循环至count = 0还是没有找到，则直接返回nil，如下所示：

以查找TCJPerson类的sayHello实例方法为例，其二分查找过程如下

cache_getImp方法：父类缓存查找

cache_getImp方法是通过汇编_cache_getImp实现，传入的$0 是 GETIMP，如下所示

• 如果父类缓存中找到了方法实现，则跳转至CacheHit即命中，则直接返回imp
• 如果在父类缓存中，没有找到方法实现，则跳转至CheckMiss 或者 JumpMiss，通过判断$0 跳转至LGetImpMiss，直接返回nil.

总结

• 对于对象方法（即实例方法），即在类中查找，其慢速查找的父类链是：类--父类--根类--nil
• 对于类方法，即在元类中查找，其慢速查找的父类链是：元类--根元类--根类--nil
• 如果快速查找、慢速查找也没有找到方法实现，则尝试动态方法决议
• 如果动态方法决议仍然没有找到，则进行消息转发

常见方法未实现报错源码

如果在快速查找、慢速查找、方法解析流程中，均没有找到实现，则使用消息转发，其流程如下

消息转发会实现

• 其中_objc_msgForward_impcache是汇编实现，会跳转至__objc_msgForward，其核心是__objc_forward_handler
  

• 汇编实现中查找__objc_forward_handler，并没有找到，在源码中去掉一个下划线进行全局搜索_objc_forward_handler，有如下实现，本质是调用的objc_defaultForwardHandler方法
  

看着objc_defaultForwardHandler有没有很眼熟，这就是我们在日常开发中最常见的错误：没有实现函数，运行程序，崩溃时报的错误提示.

:定义TCJPerson父类，其中有sayNB实例方法 和 sayHappay类方法

定义子类:TCJStudent类,有实例方法sayHello和sayMaster,类方法sayObjc,其中实例方法sayMaster未实现.

在main中 调用TCJStudend的实例方法sayMaster ，运行程序报错，提示方法未实现，如下所示

下面，我们来讲讲如何在崩溃前，如何操作，可以防止方法未实现的崩溃.

四、动态方法解析

在慢速查找流程未找到方法实现时，首先会尝试一次动态方法决议，其源码实现如下：

主要分为以下几步

• 判断类是否是元类
  • 如果是类，执行实例方法的动态方法决议resolveInstanceMethod
  • 如果是元类，执行类方法的动态方法决议resolveClassMethod，如果在元类中没有找到或者为空，则在元类的实例方法的动态方法决议resolveInstanceMethod中查找，主要是因为类方法在元类中是实例方法，所以还需要查找元类中实例方法的动态方法决议
• 如果动态方法决议中，将其实现指向了其他方法，则继续查找指定的imp，即继续慢速查找lookUpImpOrForward流程

其流程如下

① 实例方法

针对实例方法调用，在快速-慢速查找均没有找到实例方法的实现时，我们有一次挽救的机会，即尝试一次动态方法决议，由于是实例方法，所以会走到resolveInstanceMethod方法，其源码如下

主要分为以下几个步骤：

• 在发送resolveInstanceMethod消息前，需要查找cls类中是否有该方法的实现，即通过lookUpImpOrNil方法又会进入lookUpImpOrForward慢速查找流程查找resolveInstanceMethod方法
  • 如果没有，则直接返回
  • 如果有，则发送resolveInstanceMethod消息
• 再次慢速查找实例方法的实现，即通过lookUpImpOrNil方法又会进入lookUpImpOrForward慢速查找流程查找实例方法

② 崩溃修改--动态方法决议

针对实例方法say666未实现的报错崩溃，可以通过在类中重写resolveInstanceMethod类方法，并将其指向其他方法的实现，即在TCJPerson中重写resolveInstanceMethod类方法，将实例方法say666的实现指向sayMaster方法实现，如下所示

假如我们在resolveInstanceMethod类方法中，不指向其他方法的实现,它会来两次,为什么会这样呢?我们在后面在解释...

③ 类方法

针对类方法，与实例方法类似，同样可以通过重写resolveClassMethod类方法来解决前文的崩溃问题，即在TCJPerson类中重写该方法，并将sayNB类方法的实现指向类方法sayHappy

resolveClassMethod类方法的重写需要注意一点，传入的cls不再是类，而是元类，可以通过objc_getMetaClass方法获取类的元类，原因是因为类方法在元类中是实例方法.

④ 优化方案

上面的这种方式是单独在每个类中重写，有没有更好的，一劳永逸的方法呢？其实通过方法慢速查找流程可以发现其查找路径有两条

• 实例方法：类 -- 父类 -- 根类 -- nil
• 类方法：元类 -- 根元类 -- 根类 -- nil

它们的共同点是如果前面没找到，都会来到根类即NSObject中查找，所以我们是否可以将上述的两个方法统一整合在一起呢？答案是可以的，可以通过NSObject添加分类的方式来实现统一处理，而且由于类方法的查找，在其继承链，查找的也是实例方法，所以可以将实例方法 和 类方法的统一处理放在resolveInstanceMethod方法中,如下所示

这种方式的实现，正好与源码中针对类方法的处理逻辑是一致的，即完美阐述为什么调用了类方法动态方法决议，还要调用对象方法动态方法决议，其根本原因还是类方法在元类中是实例方法.

当然，上面这种写法还是会有其他的问题，比如系统方法也会被更改，针对这一点，是可以优化的，即我们可以针对自定义类中方法统一方法名的前缀，根据前缀来判断是否是自定义方法，然后统一处理自定义方法，例如可以在崩溃前pop到首页，主要是用于app线上防崩溃的处理，提升用户的体验.

⑤ 动态方法决议总结

• 实例方法可以重写resolveInstanceMethod添加imp
• 类方法可以在本类重写resolveClassMethod往元类添加imp，或者在NSObject分类重写resolveInstanceMethod添加imp
• 动态方法解析只要在任意一步lookUpImpOrNil查找到imp就不会查找下去——即本类做了动态方法决议，不会走到NSObjct分类的动态方法决议
• 所有方法都可以通过在NSObject分类重写resolveInstanceMethod添加imp解决崩溃

那么把所有崩溃都在NSObjct分类中处理，加以前缀区分业务逻辑，岂不是美滋滋？错！

• 统一处理起来耦合度高
• 逻辑判断多
• 可能在NSObjct分类动态方法决议之前已经做了处理
• SDK封装的时候需要给一个容错空间

因此前面的 ④ 优化方案 也不是一个最完美的解决方案.那么,这也不行，那也不行，那该怎么办？放心，苹果爸爸已经给我们准备好后路了！

五、消息转发机制

在慢速查找的流程(lookUpImpOrForward)中，我们了解到，如果快速+慢速没有找到方法实现，动态方法决议也不行，就使用消息转发，但是，我们找遍了源码也没有发现消息转发的相关源码，可以通过以下方式来了解，方法调用崩溃前都走了哪些方法

• 通过instrumentObjcMessageSends方式打印发送消息的日志

instrumentObjcMessageSends

通过lookUpImpOrForward --> log_and_fill_cache --> logMessageSend,在logMessageSend源码下方找到instrumentObjcMessageSends的源码实现，所以，在main中调用instrumentObjcMessageSends打印方法调用的日志信息，有以下两点准备工作

• 1、打开 objcMsgLogEnabled 开关，即调用instrumentObjcMessageSends方法时，传入YES

• 2、在main中通过extern 声明instrumentObjcMessageSends方法[图片上传失败...(image-1b897a-1614008219381)]

• 通过logMessageSend源码，了解到消息发送打印信息存储在/tmp/msgSends 目录，如下所示

  

• 运行代码，并前往/tmp/msgSends 目录，发现有msgSends开头的日志文件，打开发现在崩溃前，执行了以下方法
  • 两次动态方法决议：resolveInstanceMethod方法
  • 两次消息快速转发：forwardingTargetForSelector方法
  • 两次消息慢速转发：methodSignatureForSelector + resolveInvocation
    

快速转发流程

forwardingTargetForSelector在源码中只有一个声明，并没有其它描述，好在帮助文档中提到了关于它的解释：

• 该方法的返回对象是执行sel的新对象，也就是自己处理不了会将消息转发给别的对象进行相关方法的处理，但是不能返回self，否则会一直找不到
• 该方法的效率较高，如果不实现，会走到forwardInvocation:方法进行处理
• 底层会调用objc_msgSend(forwardingTarget, sel, ...);来实现消息的发送

• 被转发消息的接受者参数、返回值等应和原方法相同
  

快速转发流程解决崩溃

如下代码就是通过快速转发解决崩溃——即TCJPerson实现不了的方法，转发给TCJStudent去实现（转发给已经实现该方法的对象）

也可以直接不指定消息接收者，直接调用父类的该方法，如果还是没有找到，则直接报错

慢速转发流程

在快速转发流程找不到转发的对象后，会来到慢速转发流程methodSignatureForSelector
依葫芦画瓢，在帮助文档中找到methodSignatureForSelector

点击查看forwardInvocation

• forwardInvocation和methodSignatureForSelector必须是同时存在的，底层会通过方法签名，生成一个NSInvocation，将其作为参数传递调用
• 查找可以响应NSInvocation中编码的消息的对象（对于所有消息，此对象不必相同）
• 使用anInvocation将消息发送到该对象.anInvocation将保存结果，运行时系统将提取结果并将其传递给原始发送者
  

慢速转发流程解决崩溃

慢速转发流程就是先methodSignatureForSelector提供一个方法签名，然后forwardInvocation通过对NSInvocation来实现消息的转发

其实也可以对forwardInvocation方法中的invocation不进行处理，也不会崩溃报错

所以，由上述可知，无论在forwardInvocation方法中是否处理invocation事务，程序都不会崩溃.

通过hopper/IDA反汇编消息转发机制

Hopper和IDA是一个可以帮助我们静态分析可视性文件的工具，可以将可执行文件反汇编成伪代码、控制流程图等，下面以Hopper为例.

• 运行程序崩溃，查看堆栈信息
  

• 发现___forwarding___来自CoreFoundation
  

• 通过image list，读取整个镜像文件,然后搜索CoreFoundation，查看其可执行文件的路径
  

• 通过文件路径，找到CoreFoundation的可执行文件
  

• 打开hopper，选择Try the Demo，然后将上一步的可执行文件拖入hopper进行反汇编，选择x86(64 bits)
  
  

• 以下是反汇编后的界面，主要使用上面的三个功能，分别是 汇编、流程图、伪代码
  

• 通过左侧的搜索框搜索__forwarding_prep_0___，然后选择伪代码

• 以下是__forwarding_prep_0___的汇编伪代码，跳转至___forwarding___

  

• 以下是___forwarding___的伪代码实现，首先是查看是否实现forwardingTargetForSelector方法，如果没有响应，跳转至loc_6459b即快速转发没有响应，进入慢速转发流程

  

• 跳转至loc_6459b，在其下方判断是否响应methodSignatureForSelector方法

  

• 如果没有响应，跳转至loc_6490b，则直接报错

• 如果获取methodSignatureForSelector的方法签名为nil，也是直接报错

  

• 如果methodSignatureForSelector返回值不为空，则在forwardInvocation方法中对invocation进行处理

  

通过上面两种查找方式可以验证，消息转发的方法有3个

• 【快速转发】forwardingTargetForSelector
• 【慢速转发】
  • methodSignatureForSelector
  • forwardInvocation

消息转发整体的流程如下!](https://upload-images.jianshu.io/upload_images/2340353-0630f3b4f1f7b6ec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

消息转发的处理主要分为两部分：

• 【快速转发】当慢速查找，以及动态方法决议均没有找到实现时，进行消息转发，首先是进行快速消息转发，即走到forwardingTargetForSelector方法
  • 如果返回消息接收者，在消息接收者中还是没有找到方法实现，则进入另一个方法的查找流程
  • 如果返回nil，则进入慢速消息转发
• 【慢速转发】执行到methodSignatureForSelector方法
  • 如果返回的方法签名为nil，则直接崩溃报错
  • 如果返回的方法签名不为nil，走到forwardInvocation方法中，对invocation事务进行处理，如果不处理也不会报错

六、动态方法决议为什么执行两次？

在前文中提及了动态方法决议方法执行了两次，有以下两种分析方式

启用上帝视角的探索

在慢速查找流程中，我们了解到resolveInstanceMethod方法的执行是通过lookUpImpOrForward --> resolveMethod_locked --> resolveInstanceMethod来到resolveInstanceMethod源码，在源码中通过发送resolve_sel消息触发，如下所示

所以可以在resolveInstanceMethod方法中IMP imp = lookUpImpOrNil(inst, sel, cls);处加一个断点，通过bt打印堆栈信息来看到底发生了什么

• 在resolveInstanceMethod方法中IMP imp = lookUpImpOrNil(inst, sel, cls);处加一个断点，运行程序，直到第一次“来了”，通过bt查看第一次动态方法决议的堆栈信息，此时的sel是say666
  

• 继续往下执行，直到第二次“来了”打印，查看堆栈信息，在第二次中，我们可以看到是通过CoreFoundation的-[NSObject(NSObject) methodSignatureForSelector:]方法，然后通过class_getInstanceMethod再次进入动态方法决议
  

• 通过上一步的堆栈信息，我们需要去看看CoreFoundation中到底做了什么？通过Hopper反汇编CoreFoundation的可执行文件，查看methodSignatureForSelector方法的伪代码
  

• 通过methodSignatureForSelector伪代码进入___methodDescriptionForSelector的实现
  

• 进入 ___methodDescriptionForSelector的伪代码实现，结合汇编的堆栈打印，可以看到，在___methodDescriptionForSelector这个方法中调用了objc4源码的class_getInstanceMethod
  

• 在objc4源码中搜索class_getInstanceMethod，其源码实现如下所示
  

这一点可以通过代码调试来验证，如下所示，在class_getInstanceMethod方法处加一个断点，在执行了methodSignatureForSelector方法后，返回了签名，说明方法签名是生效的，苹果在走到invocation之前，给了开发者一次机会再去查询，所以走到class_getInstanceMethod这里，又去走了一遍方法查询say666,然后会再次走到动态方法决议

所以，上述的分析也印证了前文中resolveInstanceMethod方法执行了两次的原因

无上帝视角的探索

如果在没有上帝视角的情况下，我们也可以通过代码来推导在哪里再次调用了动态方法决议

• TCJPerson类中重写resolveInstanceMethod方法，并加上class_addMethod操作即赋值IMP，此时resolveInstanceMethod会走两次吗？
  

通过运行发现，如果赋值了IMP，动态方法决议只会走一次，说明不是在这里走第二次动态方法决议

继续往下探索

• 去掉resolveInstanceMethod方法中的赋值IMP，在TCJPerson类中重写forwardingTargetForSelector方法，并指定返回值为[TCJStudent alloc]，重新运行，如果resolveInstanceMethod打印了两次，说明是在forwardingTargetForSelector方法之前执行了动态方法决议，反之，在forwardingTargetForSelector方法之后
  

结果发现resolveInstanceMethod中的打印还是只打印了一次，数排名第二次动态方法决议 在forwardingTargetForSelector方法后

• 在TCJPerson类中重写 methodSignatureForSelector 和 forwardInvocation，运行
  

结果发现第二次动态方法决议在 methodSignatureForSelector 和 forwardInvocation方法之间.

第二种分析同样可以论证前文中resolveInstanceMethod执行了两次的原因.
经过上面的论证，我们了解到其实在慢速消息转发流程中，在methodSignatureForSelector 和 forwardInvocation方法之间还有一次动态方法决议，即苹果再次给的一个机会，如下图所示

写在后面

到目前为止，objc_msgSend发送消息的流程就分析完成了，在这里简单总结下

• 【快速查找流程】首先，在类的缓存cache中查找指定方法的实现
• 【慢速查找流程】如果缓存中没有找到，则在类的方法列表中查找，如果还是没找到，则去父类链的缓存和方法列表中查找
• 【动态方法决议】如果慢速查找还是没有找到时，第一次补救机会就是尝试一次动态方法决议，即重写resolveInstanceMethod/resolveClassMethod 方法
• 【消息转发】如果动态方法决议还是没有找到，则进行消息转发，消息转发中有两次补救机会：快速转发+慢速转发
• 如果转发之后也没有，则程序直接报错崩溃unrecognized selector sent to instance

最后,和谐学习,不急不躁.我还是我,颜色不一样的烟火.