有关Swizzling的一个问题
前言
最近在开发的时候遇到了一个Swizzling的问题，特别在此记录，希望有相同遭遇的朋友能参考。
问题
问题概况：被Swizzling的方法在调用原有实现的时候提示“Selector无法被响应”。
问题过程：项目中A框架使用Aspects（一个帮助开发者实现快速Swizzling的框架）来替换UIViewController的- (void)viewDidLoad方法，这个步骤是先被执行的。之后的某个情况下，项目中B框架又使用自己写的Swizzling方法替换了UIViewController的- (void)viewDidLoad方法。这时我发现，当代码运行到B框架的替换方法，并且要执行原有的方法时，会报Selector无法被响应的错。很奇怪，因为从B框架中Swizzling的实现上来看，会保存之前的IMP，所以应该能找到才对。
原因
于是我去看了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处理结果（先）
另一处理结果（后）
具体执行逻辑如下图：
执行流程
解决办法
依照上面的说法，当项目里面有类似Aspects这种Swizzling方式，而且它先于其他Swizzling方式执行，且Swizzling了相同的代码，那么这个问题就会发生了，目前知道的另一个这么做的库是JSPatch（具体可以参考它Wiki中方法替换章节的第5小节）。使用Aspects库的人数我无法估计，但JSPatch的应该不少吧。所以给出合理的解决办法还是很有必要的。
方案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经消息转发流程得到正确的实现）。
最后
欢迎讨论，欢迎指出问题。
