20 / 12 / 19
「重学 OC」内存管理06 - Objective-C中方法的传递过程
我们现在已经清楚方法的调用顺序了，实现从缓存中找没有的话再去rw_t中找，那么再没有的话就去其父类中找，父类中查找也是如此，先去父类中的cache中查找，没有的话再去父类的rw_t中找，以此类推。如果查找到基类还没有呢？难道就直接报unrecognized selector sent to instance 这个经典错误吗？
其实不是，方法的传递主要涉及到三个部分，这也是我们平时用得最多以及面试中经常出现的问题：
我们都知道，当我们调用一个方法是，其实底层是将这个方法转换成了objc_msgSend函数来进行调用，objc_msgSend的执行流程可以分为3大阶段：
消息发送->动态方法解析->消息转发
****这个流程我们是可以从源码中得到确认，以下是源码：
1 /*********************************************************************** 2 * _class_lookupMethodAndLoadCache. 3 * Method lookup for dispatchers ONLY. OTHER CODE SHOULD USE lookUpImp(). 4 * This lookup avoids optimistic cache scan because the dispatcher 5 * already tried that. 6 **********************************************************************/ 7 IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls) 8 { 9 return lookUpImpOrForward(cls, sel, obj, 10 YES/*initialize*/, NO/*cache*/, YES/*resolver*/); 11 } 12 13 14 /*********************************************************************** 15 * lookUpImpOrForward. 16 * The standard IMP lookup. 17 * initialize==NO tries to avoid +initialize (but sometimes fails) 18 * cache==NO skips optimistic unlocked lookup (but uses cache elsewhere) 19 * Most callers should use initialize==YES and cache==YES. 20 * inst is an instance of cls or a subclass thereof, or nil if none is known. 21 * If cls is an un-initialized metaclass then a non-nil inst is faster. 22 * May return _objc_msgForward_impcache. IMPs destined for external use 23 * must be converted to _objc_msgForward or _objc_msgForward_stret. 24 * If you don't want forwarding at all, use lookUpImpOrNil() instead. 25 **********************************************************************/ 26 //这个函数是方法调用流程的函数 即消息发送->动态方法解析->消息转发 27 IMP lookUpImpOrForward(Class cls, SEL sel, id inst, 28 bool initialize, bool cache, bool resolver) 29 { 30 IMP imp = nil; 31 bool triedResolver = NO; 32 33 runtimeLock.assertUnlocked(); 34 35 // Optimistic cache lookup 36 if (cache) { 37 imp = cache_getImp(cls, sel); 38 if (imp) return imp; 39 } 40 41 // runtimeLock is held during isRealized and isInitialized checking 42 // to prevent races against concurrent realization. 43 44 // runtimeLock is held during method search to make 45 // method-lookup + cache-fill atomic with respect to method addition. 46 // Otherwise, a category could be added but ignored indefinitely because 47 // the cache was re-filled with the old value after the cache flush on 48 // behalf of the category. 49 50 runtimeLock.lock(); 51 checkIsKnownClass(cls); 52 53 if (!cls->isRealized()) { 54 realizeClass(cls); 55 } 56 57 if (initialize && !cls->isInitialized()) { 58 runtimeLock.unlock(); 59 _class_initialize (_class_getNonMetaClass(cls, inst)); 60 runtimeLock.lock(); 61 // If sel == initialize, _class_initialize will send +initialize and 62 // then the messenger will send +initialize again after this 63 // procedure finishes. Of course, if this is not being called 64 // from the messenger then it won't happen. 2778172 65 } 66 67 68 retry: 69 runtimeLock.assertLocked(); 70 71 // Try this class's cache. 72 //先从当前类对象的方法缓存中查看有没有对应方法 73 imp = cache_getImp(cls, sel); 74 if (imp) goto done; 75 76 // Try this class's method lists. 77 //没有的话再从类对象的方法列表中寻找 78 { 79 Method meth = getMethodNoSuper_nolock(cls, sel); 80 if (meth) { 81 log_and_fill_cache(cls, meth->imp, sel, inst, cls); 82 imp = meth->imp; 83 goto done; 84 } 85 } 86 87 // Try superclass caches and method lists. 88 { 89 unsigned attempts = unreasonableClassCount(); 90 //遍历所有父类 知道其父类为空 91 for (Class curClass = cls->superclass; 92 curClass != nil; 93 curClass = curClass->superclass) 94 { 95 // Halt if there is a cycle in the superclass chain. 96 if (--attempts == 0) { 97 _objc_fatal("Memory corruption in class list."); 98 } 99 100 // Superclass cache. 101 //先查找父类的方法缓存 102 imp = cache_getImp(curClass, sel); 103 if (imp) { 104 if (imp != (IMP)_objc_msgForward_impcache) { 105 // Found the method in a superclass. Cache it in this class. 106 log_and_fill_cache(cls, imp, sel, inst, curClass); 107 goto done; 108 } 109 else { 110 // Found a forward:: entry in a superclass. 111 // Stop searching, but don't cache yet; call method 112 // resolver for this class first. 113 break; 114 } 115 } 116 117 // Superclass method list. 118 //再查找父类的方法列表 119 Method meth = getMethodNoSuper_nolock(curClass, sel); 120 if (meth) { 121 log_and_fill_cache(cls, meth->imp, sel, inst, curClass); 122 imp = meth->imp; 123 goto done; 124 } 125 } 126 } 127 128 // No implementation found. Try method resolver once. 129 //消息发送阶段没找到imp 尝试进行一次动态方法解析 130 if (resolver && !triedResolver) { 131 runtimeLock.unlock(); 132 _class_resolveMethod(cls, sel, inst); 133 runtimeLock.lock(); 134 // Don't cache the result; we don't hold the lock so it may have 135 // changed already. Re-do the search from scratch instead. 136 triedResolver = YES; 137 //跳转到retry入口 retry入口就在上面,也就是x消息发送过程即找缓存找rw_t 138 goto retry; 139 } 140 141 // No implementation found, and method resolver didn't help. 142 // Use forwarding. 143 //消息发送阶段没找到imp而且执行动态方法解析也没有帮助 那么就执行方法转发 144 imp = (IMP)_objc_msgForward_impcache; 145 cache_fill(cls, sel, imp, inst); 146 147 done: 148 runtimeLock.unlock(); 149 150 return imp; 151 }
首先，消息发送，就是我们刚才提到的系统会先去cache_t中查找，有的话调用，没有的话去类对象的rw_t中查找，有的话调用并缓存到cache_t中，没有的话根据supperclass指针去父类中查找。父类查找也是如此，先去父类的cache_t中查找，有的话进行调用并添加到自己的cache_t中而不是父类的cache_t中，没有的话再去父类的rw_t中查找，有的话调用并缓存到自己的cache_t中，没有的话以此类推。流程如下：
当消息发送找到最后一个父类还没有找到对应的方法时，就会来到动态方法解析。动态解析，就是意味着开发者可以在这里动态的往rw_t中添加方法实现，这样的话系统再次遍历rw_t就会找到对应的方法进行调用了。
动态方法解析的流程示意图如下：
主要涉及到了两个方法：
+resolveInstanceMethod://添加对象方法 也就是-开头的方法 +resolveClassMethod://添加类方法 也就是+开头的方法
我们在实际项目中进行验证：
动态添加类方法也是如此，只不过是添加到元类对象中（此时run方法已经改成了个类方法）:
而且我们也发现，动态添加方法的话其实无非就是找到方法实现，添加到类对象或元类对象中，至于这个方法实现是什么形式都没有关系，比如说我们再给对象方法添加方法实现时，这个实现方法可以是个类方法，同样给类方法动态添加方法实现时也可以是对象方法。也就是说系统根本没有区分类方法和对象方法，只要把imp添加到元类对象的rw_t中就是类方法，添加到类对象中就是对象方法。
当我们在消息发送和动态消息解析阶段都没有找到对应的imp的时候，系统回来到最后一个消息转发阶段。所谓消息转发，就是你这个消息处理不了后可以找其他人或者其他方法来代替，消息转发的流程示意图如下：
即分为两步，第一步是看能不能找其他人代你处理这方法，可以的话直接调用这个人的这个方法，这一步不行的话就来到第二部，这个方法没有的话有没有可以替代的方法，有的话就执行替代方法。我们通过代码来验证：
我们调用dog的run方法是，因为dog本身没有实现这个方法，所以不能处理。正好cat实现了这个方法，所以我们就将这个方法转发给cat处理：
我们发现，确实调用了小猫run方法，但是只转发方法执行者太局限了，要求接收方法对象必须实现了同样的方法才行，否则还是无法处理，所以实用性不强。这时候，我们可以通过methodSignatureForSelector来进行更大限度的转发。
需要注意的是要想来到methodSignatureForSelector这一步需要**将*forwardingTargetForSelector返回nil（即默认状态）*否则系统找到目标执行者后就不会再往下转发了。
**开发者可以在forwardInvocation:方法中自定义任何逻辑。
////为方法重新转发一个目标执行 //- (id)forwardingTargetForSelector:(SEL)aSelector{ // if (aSelector == @selector(run)) { // //dog的run方法没有实现 所以我们将此方法转发到cat对象上去实现 也就是相当于将[dog run]转换成[cat run] // return [[Cat alloc] init]; // } // return [super forwardingTargetForSelector:aSelector]; //} //方法签名 - (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector{ if (aSelector == @selector(run)) { //注意:这里返回的是我们要转发的方法的签名 比如我们现在是转发run方法 那就是返回的就是run方法的签名 //1.可以使用methodSignatureForSelector:方法从实例中请求实例方法签名，或者从类中请求类方法签名。 //2.也可以使用instanceMethodSignatureForSelector:方法从一个类中获取实例方法签名 //这里使用self的话会进入死循环 所以不可以使用 如果其他方法中有同名方法可以将self换成其他类 // return [self methodSignatureForSelector:aSelector]; // return [NSMethodSignature instanceMethodSignatureForSelector:aSelector]; //3.直接输入字符串 return [NSMethodSignature signatureWithObjCTypes:"v@:"]; } return [super methodSignatureForSelector:aSelector]; } //当返回方法签名后 就会转发到这个方法 所以我们可以在这里做想要实现的功能 可操作空间很大 //这个anInvocation里面有转发方法的信息,比如方法调用者/SEL/types/参数等等信息 - (void)forwardInvocation:(NSInvocation *)anInvocation{ //这样写不安全 可以导致cat被过早释放掉引发怀内存访问 // anInvocation.target = [[Cat alloc] init]; Cat *ca = [[Cat alloc] init]; //指定target anInvocation.target = ca; //对anInvocation做出修改后要执行invoke方法保存修改 [anInvocation invoke]; //或者干脆一行代码搞定 [anInvocation invokeWithTarget:[[Cat alloc] init]]; //上面这段代码相当于- (id)forwardingTargetForSelector:(SEL)aSelector{}中的操作 //当然 转发到这里的话可操作性更大 也可以什么都不写 相当于转发到的这个方法是个空方法 也不会报方法找不到的错误 //也可以在这里将报错信息提交给后台统计 比如说某个方法找不到提交给后台 方便线上错误收集 //...很多用处 }
当然我们也可以访问修改anInvocation的参数，比如现在run有个age参数，
// 参数顺序：receiver、selector、other arguments int age; //索引为2的参数已经放到了&age的内存中，我们可以通过age来访问 [anInvocation getArgument:&age atIndex:2]; NSLog(@"%d", age + 10);
我们发现，消息转发有两种情况，一种是forwardingTargetForSelector，一种是methodSignatureForSelector+forwardInvocation：
其实，第一种也称快速转发，特点就是简单方便，缺点就是能做的事情有限，只能转发消息调用者；第二种也称标准转发，缺点就是写起来麻烦点，需要写方法签名等信息，但是好处就是可以很大成都的自定义方法的转发，可以在找不到方法imp的时候做任何逻辑。
当然，我们上面的例子都是通过对象方法来演示消息转发的，类方法同样存在消息转发，只不过对应的方法都是类方法，也就是-变+
所以，以上关于消息传递过程可以用下面这个流程图进一步总结：
关于源码阅读指南：
