前言
最近在开发的时候遇到了一个Swizzling的问题，特别在此记录，希望有相同遭遇的朋友能参考。
问题
原因
于是我去看了Aspects的源码，发现它的实现是这样的（假如现在要Swizzling classA类的methodA方法）：
- 在methodA被Swizzling的时候先看classA的
-forwardInvocation:方法是否被替换，如果不是，就使用自己的-AspectsForwardInvocation:方法来替换classA的-forwardInvocation:。
- 将methodA的IMP指向
_objc_msgForward，这是一个全局 IMP，OC 调用方法不存在时都会转发到这个 IMP 上，这样做了之后，当methodA被调用的时候，就会先进入-AspectsForwardInvocation:方法。 - 接下来我们看
-AspectsForwardInvocation:的实现，这个方法会将NSInvocation的Selector拿出来，再拼上一个前缀（aspects_），然后检查这个方法是否是已经被Aspects替换过，如果是，就查询相关的实现并执行，如果不是，就执行原有的-forwardInvocation:方法来进行转发。
这下问题就很清楚了，当Aspects的Swizzling方法先被执行的时候，原方法Selector对应的IMP已经指向_objc_msgForward，所以当另一个框架再进行Swizzling的时候，存起来的原有实现就是这个“错的”_objc_msgForward。那么当执行完自己加的代码后，想要再通过objc_msgSend执行原有实现，就是会找不到，因为原有实现已经被替换为_objc_msgForward，而真的IMP由于被Aspects先Swizzling掉了，所以找不到！
具体Swizzling结果如下图：
Aspects处理结果（先） 另一处理结果（后）具体执行逻辑如下图：
执行流程解决办法
方案1:如果在你的Swizzling方法内部需要调用原有方法，那么在执行原有方法的IMP之前先判断一下，如果为_objc_msgForward（或_objc_msgForward_stret），那么就使用原有Selector拼成一个NSInvocation，再使用objc_msgSend执行。使用原有Selector的原因是：在进入已被替换的-forwardInvocation:时，只有原有Selector可以帮助找到真实的实现。使用NSInvocation进行消息转发的原因是：这样可以走到-forwardInvocation:方法。这种方法的缺点是需要在每个地方都做处理，而且之前的判断也比较特殊。
方案2:参考Aspects或JSPatch相关代码，将-forwardInvocation:也进行Swizzling，在自己的-forwardInvocation:方法中进行同样的操作，就是判断传入的NSInvocation的Selector，如果是自己可以识别的Selector，那么就将Selector变为原有Selector在执行，如果不识别，就直接转发。（这也是为什么我们项目中Aspects和JSPatch不冲突的原因，因为都将被Swizzling的方法指向了_objc_msgForward（或_objc_msgForward_stret），然后再监控-forwardInvocation:方法，使得方法最终通过原有Selector经消息转发流程得到正确的实现）。
最后
欢迎讨论，欢迎指出问题。