全面谈谈Aspects和JSPatch兼容问题

1. 背景

Aspects 和 JSPatch 是 iOS 开发中很是常见的两个库。Aspects 提供了方便简单的方法进行面向切片编程(AOP)，JSPatch可让你用 JavaScript 书写原生 iOS APP 和进行热修复。关于实现原理能够参考 面向切面编程之 Aspects 源码解析及应用 和 JSPatch wiki。简单地归纳就是将原方法实现替换为_objc_msgForward（或_objc_msgForward_stret），当执行这个方法是直接进入消息转发过程，最后到达替换后的-forwardInvocation:，在-forwardInvocation:内执行新的方法，这是二者的共同原理。最近项目开发中须要用 JSPatch 替换方法修复一个 bug ，然而这个方法已经使用 Aspects 进行 hook 过了，那么二者同时使用会不会有问题呢？关于这个问题，网上介绍比较详细的是 面向切面编程之 Aspects 源码解析及应用 和 有关Swizzling的一个问题，深刻研究后发现这两篇文章讲得都不够全面。本文基于 Aspects 1.4.1 和 JSPatch 1.1 介绍几种测试结果和缘由。

2. 测试

2.0. 源码

这是本文使用的测试代码，你能够clone下来，泡杯咖啡，找个安静的地方跟着本文一步一步实践。

2.1. 代码说明

ViewController.m中首先定义一个简单类MyClass，只有-test和-test2方法，方法内打印log

@interface MyClass : NSObject - (void)test; - (void)test2; @end @implementation MyClass - (void)test { NSLog(@"MyClass origin log"); } - (void)test2 { NSLog(@"MyClass test2 origin log"); } @end

接着是三个hook方法，分别是对-test进行hook的-jp_hook、-aspects_hook和对-test2进行hook的-aspects_hook_test2

- (void)jp_hook { [JPEngine startEngine]; NSString *sourcePath = [[NSBundle mainBundle] pathForResource:@"demo" ofType:@"js"]; NSString *script = [NSString stringWithContentsOfFile:sourcePath encoding:NSUTF8StringEncoding error:nil]; [JPEngine evaluateScript:script]; } - (void)aspects_hook { [MyClass aspect_hookSelector:@selector(test) withOptions:AspectPositionAfter usingBlock:^(id aspects) { NSLog(@"aspects log"); } error:nil]; } - (void)aspects_hook_test2 { [MyClass aspect_hookSelector:@selector(test2) withOptions:AspectPositionInstead usingBlock:^(id aspects) { NSLog(@"aspects test2 log"); } error:nil]; }

demo.js代码也很是简单，对MyClass的-test进行替换

require('MyClass') defineClass('MyClass', { test: function() { // self.ORIGtest(); console.log("jspatch log") } });

2.2. 具体测试

2.2.1. JSPatch 先 hook 、Aspects 采用 AspectPositionInstead (替换) hook

那么代码就是下面这样，注意把-aspects_hook方法设置为AspectPositionInstead

// ViewController.m - (void)viewDidLoad { [super viewDidLoad]; [self jp_hook]; [self aspects_hook]; MyClass *a = [[MyClass alloc] init]; [a test]; }

执行结果：

JPAndAspects[2092:1554779] aspects log

结果是 Aspects 正确替换了方法

2.2.2. Aspects 先采用随便一种Position hook，JSPatch再hook

那么代码就是下面这样

- (void)viewDidLoad { [super viewDidLoad]; [self aspects_hook]; [self jp_hook]; MyClass *a = [[MyClass alloc] init]; [a test]; }

执行结果：

JPAndAspects[2774:1565702] JSPatch.log: jspatch log

结果是 JSPatch 正确替换了方法

Why？

前面说到，hook 会替换该方法和 -forwardInvocation:，咱们先看看方法被 hook 先后的变化

原方法对应关系

方法替换后原方法指向了_objc_msgForward，同时添加一个方法PREFIXtest(JSPatch 是ORIGtest，Aspects 是aspects_test)指向了原来的实现。JSPatch新增了一个方法指向IMP(NEWtest)，Aspects则保存block为关联属性

-test变化

-forwardInvocation: 的变化也类似，原来的-forwardInvocation: 没实现是这样的

-forwardInvocation:变化

若是原来的-forwardInvocation:有实现，就新加一个-ORIGforwardInvocation:指向原IMP(forwardInvocation:)

-forwardInvocation:变化

因为-test方法指向了_objc_msgForward，这时调用-test方法就会进入消息转发，消息转发的第三步进入-forwardInvocation:执行新的IMP(NEWforwardInvocation)，拿到invocation，invocation.selector拼上前缀，而后拼上其余信息直接invoke，最终执行IMP(NEWtest)(Aspects是执行替换的block)。

---

以上是只有一次hook的状况，咱们看看二者都hook的变化

JSPatch先hook， -test变化

JSPatch先hook， -forwardInvocation:变化

这时调用-test一样发生消息转发，进入-forwardInvocation:执行Aspects的IMP(AspectsforwardInvocation)，上文提到Aspects把替换的block保存为关联属性了，到了-forwardInvocation:直接拿出来执行，和原来的实现没有任何关系，因此有了2.2.1 正确的结果。

---

Aspects先hook， -test变化

Aspects先hook， -forwardInvocation:变化

这时调用-test一样发生消息转发，进入-forwardInvocation:执行JSPatch的IMP(JSPatchforwardInvocation)，执行_JPtest，和原来的实现
没有任何关系，因此有了2.2.2 正确的结果。
看到这里，若是细心的话会发现ORIGtest指向了_objc_msgForward，若是咱们在JSPatch代码里调用self.ORIGtest()会怎么样呢？

2.2.3. Aspects 先采用随便一种Position hook，JSPatch再hook，JSPatch代码里调用self.ORIGtest()

代码是下面这样的

// demo.js require('MyClass') defineClass('MyClass', { test: function() { self.ORIGtest(); console.log("jspatch log") } }); // ViewController.m - (void)viewDidLoad { [super viewDidLoad]; [self aspects_hook]; [self jp_hook]; MyClass *a = [[MyClass alloc] init]; [a test]; }

执行结果：

JPAndAspects[8668:1705052] -[MyClass ORIGtest]: unrecognized selector sent to instance 0x7ff592421a30

Why?

-test和-forwardInvocation:的变化同上一步Aspects先hook。
因为-ORIGtest指向了_objc_msgForward，调用方法时进入-forwardInvocation:执行IMP(JSPatchforwardInvocation)，JSPatchforwardInvocation中有这样一段代码

static void JPForwardInvocation(__unsafe_unretained id assignSlf, SEL selector, NSInvocation *invocation) { ... JSValue *jsFunc = getJSFunctionInObjectHierachy(slf, JPSelectorName); if (!jsFunc) { JPExecuteORIGForwardInvocation(slf, selector, invocation); return; } ... }

这个-ORIGtest在对象中找不到具体的实现，所以转发给了-ORIGINforwardInvocation:。注意：这里直接把-ORIGtest转发出去了，很显然IMP(AspectsforwardInvocation)也是处理不了这个消息的。所以，出现了unrecognized selector异常。
这里是二者兼容出现的最大问题，若是JSPatch在转发前判断一下这个方法是本身添加的-ORIGxxx，把前缀ORIG去掉再转发，这个问题就解决了。

2.2.4. JSPatch先hook， Aspects 再采用AspectPositionInstead(替换)hook，JSPatch代码里调用self.ORIGtest()

和2.2.1 相同，无论JSPatch hook以后是什么样的，都只执行Aspects的block

2.2.5. JSPatch先hook， Aspects 再采用AspectPositionBefore(替换)hook

代码以下，注意把AspectPositionInstead替换为AspectPositionBefore

// demo.js require('MyClass') defineClass('MyClass', { test: function() { console.log("jspatch log") } }); // ViewController.m - (void)viewDidLoad { [super viewDidLoad]; [self jp_hook]; [self aspects_hook]; MyClass *a = [[MyClass alloc] init]; [a test]; }

执行结果：

JPAndAspects[10943:1756624] aspects log JPAndAspects[10943:1756624] JSPatch.log: jspatch log

执行结果如期是正确的。
IMP(AspectsforwardInvocation)的部分代码以下

SEL originalSelector = invocation.selector; SEL aliasSelector = aspect_aliasForSelector(invocation.selector); invocation.selector = aliasSelector; AspectsContainer *objectContainer = objc_getAssociatedObject(self, aliasSelector); AspectsContainer *classContainer = aspect_getContainerForClass(object_getClass(self), aliasSelector); AspectInfo *info = [[AspectInfo alloc] initWithInstance:self invocation:invocation]; // Before hooks. aspect_invoke(classContainer.beforeAspects, info); aspect_invoke(objectContainer.beforeAspects, info); // Instead hooks. BOOL respondsToAlias = YES; if (objectContainer.insteadAspects.count || classContainer.insteadAspects.count) { aspect_invoke(classContainer.insteadAspects, info); aspect_invoke(objectContainer.insteadAspects, info); }else { Class klass = object_getClass(invocation.target); do { if ((respondsToAlias = [klass instancesRespondToSelector:aliasSelector])) { [invocation invoke]; break; } }while (!respondsToAlias && (klass = class_getSuperclass(klass))); } // After hooks. aspect_invoke(classContainer.afterAspects, info); aspect_invoke(objectContainer.afterAspects, info); // If no hooks are installed, call original implementation (usually to throw an exception) if (!respondsToAlias) { invocation.selector = originalSelector; SEL originalForwardInvocationSEL = NSSelectorFromString(AspectsForwardInvocationSelectorName); if ([self respondsToSelector:originalForwardInvocationSEL]) { ((void( *)(id, SEL, NSInvocation *))objc_msgSend)(self, originalForwardInvocationSEL, invocation); }else { [self doesNotRecognizeSelector:invocation.selector]; } }

首先执行Before hooks；接着查找是否有Instead hooks，若是有就执行，若是没有就在类继承链中查找父类可否响应-aspects_test，若是能够就invoke这个invocation，不然把respondsToAlias置为NO；接着执行After hooks；接着if (!respondsToAlias)把这个-test转发给ORIGINforwardInvocation即IMP(JSPatchforwardInvocation)处理了这个消息。注意这里是把-test转发

2.2.6. JSPatch先hook， Aspects 再采用AspectPositionAfter hook

代码同2.2.5，注意把AspectPositionBefore替换为AspectPositionAfter

JPAndAspects[11706:1776713] aspects log JPAndAspects[11706:1776713] JSPatch.log: jspatch log

结果都输出了，可是顺序不对。
从IMP(AspectsforwardInvocation)代码中不难看出，After hooks先执行了，再将这个消息转发。这也能够说是Aspects的不足。

2.2.7. Aspects随便一种Position hook方法-test2，JSPatch再hook -test，JSPatch代码里调用self.ORIGtest()， Aspects 以随便一种Position hook方法-test

同2.2.5和2.2.6很像，不过前面多了对-test2的hook，代码以下：

// demo.js require('MyClass') defineClass('MyClass', { test: function() { self.ORIGtest(); console.log("jspatch log") } }); // ViewController.m - (void)viewDidLoad { [super viewDidLoad]; [self aspects_hook_test2]; [self jp_hook]; [self aspects_hook]; MyClass *a = [[MyClass alloc] init]; [a test]; }

代码执行结果：

JPAndAspects[12597:1797663] MyClass origin log JPAndAspects[12597:1797663] JSPatch.log: jspatch log

结果是Aspects对-test的hook没有生效。

Why?

不废话，直接看Aspects代码：

static Class aspect_hookClass(NSObject *self, NSError **error) { NSCParameterAssert(self); Class statedClass = self.class; Class baseClass = object_getClass(self); NSString *className = NSStringFromClass(baseClass); // Already subclassed if ([className hasSuffix:AspectsSubclassSuffix]) { return baseClass; // We swizzle a class object, not a single object. }else if (class_isMetaClass(baseClass)) { return aspect_swizzleClassInPlace((Class)self); // Probably a KVO'ed class. Swizzle in place. Also swizzle meta classes in place. }else if (statedClass != baseClass) { return aspect_swizzleClassInPlace(baseClass); } // Default case. Create dynamic subclass. const char *subclassName = [className stringByAppendingString:AspectsSubclassSuffix].UTF8String; Class subclass = objc_getClass(subclassName); if (subclass == nil) { subclass = objc_allocateClassPair(baseClass, subclassName, 0); if (subclass == nil) { NSString *errrorDesc = [NSString stringWithFormat:@"objc_allocateClassPair failed to allocate class %s.", subclassName]; AspectError(AspectErrorFailedToAllocateClassPair, errrorDesc); return nil; } aspect_swizzleForwardInvocation(subclass); aspect_hookedGetClass(subclass, statedClass); aspect_hookedGetClass(object_getClass(subclass), statedClass); objc_registerClassPair(subclass); } object_setClass(self, subclass); return subclass; }

这段代码的做用是区分self的类型，进行不一样的swizzleForwardInvocation。self自己多是一个Class；或者self经过-class方法返回的self真正的Class不一样，最典型的KVO，会建立一个子类加上NSKVONotify_前缀，而后重写class方法，看不懂的能够参考Objective-C 对象模型。这两种状况都对self真正的Class进行aspect_swizzleClassInPlace；若是self是一个普通对象，则模仿KVO的实现方式，建立一个子类，swizzle子类的-forwardInvocation:，经过object_setClass强行设置Class。

---

再看aspect_swizzleClassInPlace

static Class aspect_swizzleClassInPlace(Class klass) { ... if (![swizzledClasses containsObject:className]) { aspect_swizzleForwardInvocation(klass); [swizzledClasses addObject:className]; } ... }

问题就出在这个aspect_swizzleClassInPlace，它会判断若是这个类的-forwardInvocation: swizzle过，就什么都不作，可是经过数组这种方式是会出问题，第二次hook的时候就不会-forwardInvocation:替换成IMP(AspectsforwardInvocation)，因此第二次hook不生效。相比，JSPatch的实现就比较合理，判断两个IMP是否相等。

if (class_getMethodImplementation(cls, @selector(forwardInvocation:)) != (IMP)JPForwardInvocation) { }

2.2.8. Aspects 先采用随便一种Position hook父类，JSPatch再hook子类，JSPatch代码里调用self.super().xxx()

代码是下面这样的

// demo.js require('MySubClass') defineClass('MySubClass', { test: function() { self.super().test(); console.log("jspatch log") } }); // ViewController.m // 增长一个子类 @interface MySubClass : MyClass @end @implementation MySubClass - (void)test { NSLog(@"MySubClass origin log"); } @end - (void)viewDidLoad { [super viewDidLoad]; [self aspects_hook]; [self jp_hook]; MySubClass *a = [[MySubClass alloc] init]; [a test]; }

执行结果：

JPAndAspects[89642:1600226] -[MySubClass SUPER_test]: unrecognized selector sent to instance 0x7fa4cadabc70

Why?

父类MyClass的-test和-forwardInvocation:的变化同2.2.1中原-forwardInvocation没有实现的状况。
JSPatch中super的实现是新增长一个方法-SUPER_test，IMP指向了父类的IMP，因为-test指向了_objc_msgForward，调用方法时进入-forwardInvocation:执行IMP(JSPatchforwardInvocation)，执行self.super().test()时，实际执行了-SUPER_test，这个-SUPER_test在对象中找不到具体的实现，发生了-ORIGtest同样的异常。
这里是二者兼容出现的第二个比较严重的问题。

2.3 总结

写到这里，除了Aspects对对象的hook(这种状况不多见，你能够本身测试)，可能已经解答了二者兼容的大部分问题。经过以上分析，得出不兼容的四种状况：

• Aspects先hook某一方法，JSPatch再hook同一方法且JSPatch调用了self.ORIGxxx()，结果是异常崩溃。
• Aspects先hook父类某一方法，JSPatch再hook子类同一方法且JSPatch调用了self.super().xxx()，结果是异常崩溃。
• JSPatch先hook某一方法，Aspects以After的方式hook同一方法，结果是执行顺序不对
• Aspects先hook任何方法，JSPatch再hook另外一方法，Aspects再hook和JSPatch相同的方法，结果是最后一次hook不生效

3. 写在最后

简书做为一个优质原创内容社区，拥有大量优质原创内容，提供了极佳的阅读和书写体验，吸引了大量文字爱好者和程序员。简书技术团队在这里分享技术心得体会，是但愿抛砖引玉，吸引更多的程序员大神来简书记录、分享、交流本身的心得体会。这个专题之后会不按期更新简书技术团队的文章，包括Android、iOS、前端、后端等等，欢迎你们关注。

参考

• http://wereadteam.github.io/2016/06/30/Aspects/
• http://www.jianshu.com/p/d5c3c2f236b8

文／zhao0（简书做者） 原文连接：http://www.jianshu.com/p/dc1deaa1b28e 著做权归做者全部，转载请联系做者得到受权，并标注“简书做者”。