上一篇文章《iOS-底層原理09-msgSend消息轉(zhuǎn)發(fā)》中提到，如果慢速查找在父類的緩存中沒(méi)有找到，則傳入父類的class,進(jìn)而重新進(jìn)行父類的慢速查找流程...一層層遞歸循環(huán)，直到找到方法的Imp后返回。實(shí)質(zhì)上并不是走的這個(gè)遞歸循環(huán)，因?yàn)樵诟割惖木彺嬷凶邊R編代碼快速查找找不到之后，并不會(huì)進(jìn)入__objc_msgSend_uncached，就不會(huì)走入MethodTableLookup
從父類的緩存中查找的流程imp = cache_getImp(curClass, sel);走到匯編，CacheLookup GETIMP, _cache_getImp，CacheLookup將參數(shù)GETIMP帶入到寄存器p0中，
當(dāng)父類的緩存中一直沒(méi)有找到此方法時(shí)，則進(jìn)入JumpMiss/CheckMiss $0,
從而判斷$0是否等于GETIMP,沒(méi)有找到就是GETIMP,進(jìn)入cbz p9, LGetImpMiss,將空值0存入寄存器p0位置，并直接返回ret = nil。并沒(méi)有進(jìn)行從匯編開(kāi)始的慢速查找遞歸循環(huán)。
故以上根本沒(méi)有再次進(jìn)入父類的方法慢速查找流程，遞歸循環(huán)，正確的流程圖如下
方法查找流程:先進(jìn)入本類的快速查找流程->本類的多線程緩存中查找->本類的慢速查找(二分查找)->父類的緩存中查找->父類的慢速查找(二分查找),如果還沒(méi)找到呢？且不做任何處理。程序?qū)?huì)崩潰報(bào)錯(cuò)。
通過(guò)代碼調(diào)試能夠看到進(jìn)入了父類的實(shí)例方法慢速查找流程，新建LGMankind為L(zhǎng)GPerson的父類，本類實(shí)例方法慢速查找流程LGPerson->LGMankind->NSObject->nil
類中沒(méi)有實(shí)現(xiàn)對(duì)象方法或類方法，調(diào)用的對(duì)象方法或類方法的時(shí)候會(huì)報(bào)錯(cuò)，最常見(jiàn)的錯(cuò)誤，最熟悉的陌生人
unrecognized selector sent to instance 0x10102c040
- 調(diào)用沒(méi)有實(shí)現(xiàn)的對(duì)象方法
-[LGPerson say666]: unrecognized selector sent to instance 0x10102c040
2020-11-03 20:25:47.362425+0800 KCObjc[2999:669876] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[LGPerson say666]: unrecognized selector sent to instance 0x10102c040'
- 調(diào)用沒(méi)有實(shí)現(xiàn)的類方法
沒(méi)有實(shí)現(xiàn)對(duì)象方法或類方法，則會(huì)返回forward_imp，forward_imp = (IMP)_objc_msgForward_impcache; _objc_msgForward_impcache是匯編實(shí)現(xiàn)，匯編到C++多一個(gè)下劃線_,C++到C少一個(gè)下劃線_。
// Default forward handler halts the process.
__attribute__((noreturn, cold)) void
objc_defaultForwardHandler(id self, SEL sel)
{
_objc_fatal("%c[%s %s]: unrecognized selector sent to instance %p "
"(no message forward handler is installed)",
class_isMetaClass(object_getClass(self)) ? '+' : '-',
object_getClassName(self), sel_getName(sel), self);
}
void *_objc_forward_handler = (void*)objc_defaultForwardHandler;
沒(méi)有實(shí)現(xiàn)實(shí)例方法或類方法，系統(tǒng)提供一次挽救的機(jī)會(huì)實(shí)現(xiàn):動(dòng)態(tài)方法決議
1.實(shí)例方法的動(dòng)態(tài)方法決議
根據(jù)isa的走位圖，實(shí)例方法慢速查找流程LGPerson->LGMankind->NSObject->nil
重寫(xiě)類方法+ (BOOL)resolveInstanceMethod:(SEL)sel，給類添加一個(gè)sayMaster的方法,在編譯類加載的時(shí)候，+ (BOOL)resolveInstanceMethod:(SEL)sel就已經(jīng)加載進(jìn)內(nèi)存了，將sayMaster的實(shí)現(xiàn)Imp寫(xiě)進(jìn)sel中。
+ (BOOL)resolveInstanceMethod:(SEL)sel{
if (sel == @selector(say666)) {
NSLog(@"%@ 來(lái)了哦",NSStringFromSelector(sel));
IMP imp = class_getMethodImplementation(self, @selector(sayMaster));
Method sayMMethod = class_getInstanceMethod(self, @selector(sayMaster));
const char *type = method_getTypeEncoding(sayMMethod);
return class_addMethod(self, sel, imp, type);
}
return [super resolveInstanceMethod:sel];
}
若動(dòng)態(tài)方法決議+ (BOOL)resolveInstanceMethod:(SEL)sel里面，沒(méi)有對(duì)sel方法say666進(jìn)行重新指定imp，則此動(dòng)態(tài)決議方法+ (BOOL)resolveInstanceMethod:(SEL)sel會(huì)走兩次，為什么會(huì)走兩次呢？？？
- 第一次動(dòng)態(tài)方法決議后，方法返回，是什么時(shí)候進(jìn)入第二次動(dòng)態(tài)方法決議方法的呢？？？通過(guò)打印第二進(jìn)入前的堆棧情況，獲取堆棧信息如下，得到第二次觸發(fā)是在CoreFoundation`-[NSObject(NSObject) methodSignatureForSelector:],后面探索實(shí)質(zhì)為消息的慢速轉(zhuǎn)發(fā)流程。
- 第二次動(dòng)態(tài)方法決議還沒(méi)找到imp，程序報(bào)錯(cuò)_objc_msgForward_impcache
2.類方法的動(dòng)態(tài)方法決議
根據(jù)isa的走位圖，查找類方法流程元類(metaClass)->根元類(rootMetaClass:NSObject)->根類(NSObject)->nil，根元類繼承于NSObject。
- 查找類方法，先傳入LGPerson的元類的地址0x0000000100002270，進(jìn)行查找類方法sayNB,獲取類方法，類方法在元類中是以實(shí)例方法的形式存在的，類中存在兩個(gè)類方法+ (void)lgClassMethod和+ (BOOL)resolveInstanceMethod:(SEL)sel
- 1 通過(guò)lldb獲取LGPerson元類中的方法，相當(dāng)于獲取類方法的個(gè)數(shù)兩個(gè)+ (void)lgClassMethod和+ (BOOL)resolveInstanceMethod:(SEL)sel
- 方法列表中不存在sayNB的類方法，此時(shí)繼續(xù)for循環(huán)在LGPerson元類的父類，也就是根元類NSObject中查找sayNB方法，curClass = curClass->superclass，curClass的地址為0x00000001003340f0
- 2 通過(guò)lldb查看根元類NSObject中的方法個(gè)數(shù)
- 3 根元類中沒(méi)有找到sayNB方法，繼續(xù)往上查找，在根元類的父類NSObject中繼續(xù)查找sayNB方法
- 4 根元類的父類中沒(méi)有找到sayNB方法，進(jìn)入類方法的動(dòng)態(tài)方法決議
- curClass = curClass->superclass,curClass的地址為0x0000000100334140，沒(méi)有找到進(jìn)入動(dòng)態(tài)方法決議return resolveMethod_locked(inst, sel, cls, behavior);此時(shí)cls傳入的是LGPerson的元類，會(huì)走入resolveClassMethod方法，能通過(guò)實(shí)現(xiàn)此方法，對(duì)方法進(jìn)行重新添加，先看一看沒(méi)有實(shí)現(xiàn)此方法的情況下，流程接下來(lái)往哪里走？
resolveClassMethod(inst, sel, cls);
if (!lookUpImpOrNil(inst, sel, cls)) {
resolveInstanceMethod(inst, sel, cls);
}
沒(méi)有實(shí)現(xiàn)resolveClassMethod:類方法，此時(shí)lookUpImpOrNil(inst, @selector(resolveClassMethod:), cls)一層一層的往上找，LGPerson的元類0x0000000100002270中無(wú)法找到，繼續(xù)往上一層LGPerson的根元類(NSObject)0x00000001003340f0中繼續(xù)查找，LGPerson的根元類是NSObject的元類，存放了NSObject的類方法，正好resolveClassMethod:也是NSObject的類方法，所以下面的return語(yǔ)句永遠(yuǎn)都不會(huì)走。
前面如果沒(méi)有實(shí)現(xiàn)，后面在NSObject的元類中也就是LGPerson的根元類中一定能找到系統(tǒng)NSObject的類方法resolveClassMethod:的實(shí)現(xiàn)，下面return永遠(yuǎn)不會(huì)走。
if (!lookUpImpOrNil(inst, @selector(resolveClassMethod:), cls)) {
// Resolver not implemented.
return;
}
流程繼續(xù)往下bool resolved = msg(nonmeta, @selector(resolveClassMethod:), sel);返回false，因?yàn)閞esolveClassMethod:方法并沒(méi)有在LGPerson中實(shí)現(xiàn)，sayNB方法更沒(méi)有添加。往下執(zhí)行IMP imp = lookUpImpOrNil(inst, sel, cls);查找流程，仍然找不到sayNB方法。
- 進(jìn)入
resolveInstanceMethod(inst, sel, cls);,查看根元類cls->ISA()中是否有實(shí)例方法resolveInstanceMethod:存在，是有的，根元類是NSObject的元類，NSObject的類方法resolveInstanceMethod:在NSObjct的元類中以實(shí)例方法存在，能找到，不會(huì)走return。 但bool resolved = msg(cls, resolve_sel, sel);為false，因?yàn)長(zhǎng)GPerson的元類中并不存在resolveInstanceMethod:和sayNB。
若實(shí)現(xiàn)了resolveInstanceMethod:方法，添加了sayNB方法還會(huì)報(bào)錯(cuò)嗎？？？等到后面分析
- IMP imp = lookUpImpOrNil(inst, sel, cls);查找sayNB方法，找不到返回imp為nil，此時(shí)，動(dòng)態(tài)方法決議結(jié)束，再次查找一遍sayNB方法，確認(rèn)有沒(méi)有添加。
return lookUpImpOrForward(inst, sel, cls, behavior | LOOKUP_CACHE);,未找到sayNB,返回(IMP) imp = 0x00000001002c262c (libobjc.A.dylib`_objc_msgForward_impcache),報(bào)錯(cuò)unrecognized selector sent to instance 0x10102c040
第一次動(dòng)態(tài)方法決議結(jié)束
- 后面的流程往哪里走呢？？？后面再探索，下面先看下常規(guī)操作，類方法sayNB找不到，防止報(bào)錯(cuò)的動(dòng)態(tài)方法決議的處理
查詢LGPerson的對(duì)象方法傳入的cls是類LGPerson
(lldb) p cls
(Class) $11 = LGPerson
(lldb) p/x cls
(Class) $12 = 0x00000001000032f0 LGPerson
查詢LGPerson的類方法傳入的cls是元類LGPerson
類方法的動(dòng)態(tài)方法決議
1.重寫(xiě)resolveClassMethod:方法
sayNB方法找不到，根據(jù)前文分析會(huì)進(jìn)入resolveClassMethod(inst, sel, cls);,此時(shí)的cls為L(zhǎng)GPerson的元類LGPerson,進(jìn)入resolveClassMethod(inst, sel, cls);,查詢LGPerson有沒(méi)有實(shí)現(xiàn)resolveClassMethod:方法，雖然目前LGPerson中沒(méi)有實(shí)現(xiàn)resolveClassMethod:類方法，但LGPerson元類的父類，也就是根元類NSObject中，存在resolveClassMethod:方法，為什么呢？
因?yàn)橄到y(tǒng)類NSObject的類方法resolveClassMethod:存在NSObject的元類中以實(shí)例方法形式存在，即根元類NSObject中。
- 1.如果啥也不做，必定會(huì)報(bào)錯(cuò)，最熟悉的陌生人
- 2.動(dòng)態(tài)方法決議重寫(xiě)resolveClassMethod:方法,但不增加sayNB的Imp,動(dòng)態(tài)方法決議中能迅速找到方法resolveClassMethod(inst, sel, cls);
沒(méi)有添加sayNB的imp,bool resolved = msg(nonmeta, @selector(resolveClassMethod:), sel);仍然為false
添加sayNB的imp之后，看resolved的值bool resolved = msg(nonmeta, @selector(resolveClassMethod:),此時(shí)為true
此時(shí)能找到LGPerson的類方法sayNB:，為什么能找到呢？？？
先看編譯時(shí)的，sayNB方法添加過(guò)程
+ (BOOL)resolveClassMethod:(SEL)sel{
NSLog(@"%@ 來(lái)了",NSStringFromSelector(sel));
if (sel == @selector(sayNB)) {
IMP imp = class_getMethodImplementation(objc_getMetaClass("LGPerson"), @selector(lgClassMethod));
Method sayMMethod = class_getInstanceMethod(objc_getMetaClass("LGPerson"), @selector(lgClassMethod));
const char *type = method_getTypeEncoding(sayMMethod);
return class_addMethod(objc_getMetaClass("LGPerson"), sel, imp, type);
}
return [super resolveClassMethod:sel];
}
往元類中添加方法class_addMethod(objc_getMetaClass("LGPerson"), sel, imp, type);
走入m = getMethodNoSuper_nolock(cls, name)，發(fā)現(xiàn)和方法的慢速查找過(guò)程中是用一個(gè)方法，傳入的cls也都是元類，
BOOL
class_addMethod(Class cls, SEL name, IMP imp, const char *types)
{
if (!cls) return NO;
mutex_locker_t lock(runtimeLock);
return ! addMethod(cls, name, imp, types ?: "", NO);
}
static IMP
addMethod(Class cls, SEL name, IMP imp, const char *types, bool replace)
{
IMP result = nil;
runtimeLock.assertLocked();
checkIsKnownClass(cls);
ASSERT(types);
ASSERT(cls->isRealized());
method_t *m;
if ((m = getMethodNoSuper_nolock(cls, name))) {//表示在LGPerson的元類中已經(jīng)存在name
// already exists
if (!replace) {//不用傳入的imp進(jìn)行替換
result = m->imp;
} else {//用傳入的imp進(jìn)行替換
result = _method_setImplementation(cls, m, imp);
}
} else {
auto rwe = cls->data()->extAllocIfNeeded();
// fixme optimize
method_list_t *newlist;
newlist = (method_list_t *)calloc(sizeof(*newlist), 1);
newlist->entsizeAndFlags =
(uint32_t)sizeof(method_t) | fixed_up_method_list;
newlist->count = 1;
newlist->first.name = name;
newlist->first.types = strdupIfMutable(types);
newlist->first.imp = imp;
prepareMethodLists(cls, &newlist, 1, NO, NO);
rwe->methods.attachLists(&newlist, 1);
flushCaches(cls);
result = nil;
}
return result;
}
傳入cls在LGPerson的元類中進(jìn)行查找，若查找到，是否替換，替換用傳入的imp替換，
result = _method_setImplementation(cls, m, imp); 不替換返回原來(lái)的m->imp,
若沒(méi)找到則在LGPerson的元類cls的data()中進(jìn)行增加內(nèi)存空間，重新添加auto rwe = cls->data()->extAllocIfNeeded();rwe->methods.attachLists(&newlist, 1);實(shí)時(shí)更新類的信息flushCaches(cls);方便下次查找，所以能找到。不會(huì)再報(bào)unrecognized selector sent to instance 0x10102c040找不到方法的錯(cuò)了。
以上是通過(guò)重寫(xiě)resolveClassMethod:方法，添加Imp的方式對(duì)類方法進(jìn)行動(dòng)態(tài)方法決議，類方法還能通過(guò)重寫(xiě)+ (BOOL)resolveInstanceMethod:(SEL)sel的方式進(jìn)行動(dòng)態(tài)方法決議嗎？？？
2.重寫(xiě)+ (BOOL)resolveInstanceMethod:(SEL)sel
理所當(dāng)然的會(huì)想到重寫(xiě)+ (BOOL)resolveInstanceMethod:(SEL)sel方法，將上面添加元類方法的Imp寫(xiě)入 (BOOL)resolveInstanceMethod:(SEL)sel中
發(fā)現(xiàn)添加的方法沒(méi)有生效，依然報(bào)錯(cuò),為什么會(huì)報(bào)錯(cuò)呢？已經(jīng)往元類中添加過(guò)方法了，為什么沒(méi)有找到呢？
2020-11-13 18:10:21.604474+0800 KCObjc[50067:1891886] +[LGPerson sayNB]: unrecognized selector sent to class 0x1000032d8
2020-11-13 18:10:21.607479+0800 KCObjc[50067:1891886] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[LGPerson sayNB]: unrecognized selector sent to class 0x1000032d8'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff374a8b57 __exceptionPreprocess + 250
1 libobjc.A.dylib 0x00000001001318fa objc_exception_throw + 42
2 CoreFoundation 0x00007fff37527b37 __CFExceptionProem + 0
3 CoreFoundation 0x00007fff3740d3bb ___forwarding___ + 1427
4 CoreFoundation 0x00007fff3740cd98 _CF_forwarding_prep_0 + 120
5 KCObjc 0x0000000100001a53 main + 67
6 libdyld.dylib 0x00007fff71497cc9 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
通過(guò)斷點(diǎn)調(diào)試，查看進(jìn)入resolveInstanceMethod方法中的cls為L(zhǎng)GPerson的元類，通過(guò)lldb查看LGPerson的元類中存在lgClassMethod和resolveInstanceMethod:兩個(gè)方法，并不存在sayNB方法
這句代碼為falsebool resolved = msg(cls, resolve_sel, sel);
為什么LGPerson的類方法resolveInstanceMethod:中添加的元類方法沒(méi)有生效呢？
因?yàn)長(zhǎng)GPerson的元類是一個(gè)虛擬的類，在代碼中并不存在，所以在LGPerson的.m文件中增加resolveInstanceMethod:方法,程序并不會(huì)真正進(jìn)入，就不會(huì)執(zhí)行，所以sayNB方法就沒(méi)有添加進(jìn)去，從而報(bào)錯(cuò)，此時(shí)沒(méi)有生效的話，可以根據(jù)繼承鏈的關(guān)系LPerson元類->LGPerson根元類->NSObject->nil,NSObject不是一個(gè)虛擬的類，是一個(gè)實(shí)實(shí)在在的的類，可以新建類別NSObject+LG，將方法寫(xiě)入到NSObject+LG中，增加resolveInstanceMethod:，斷點(diǎn)調(diào)試看是否能生效。
NSObject中本身存在resolveInstanceMethod:方法，重寫(xiě)此方法，返回值保持一致。return NO。
說(shuō)明NSObject+LG中的resolveInstanceMethod:方法生效，已經(jīng)將sayNB的替代方法lgClassMethod添加到LGPerson的元類中，不會(huì)再報(bào)錯(cuò)。
結(jié)論:
NSObject+LG是系統(tǒng)的分類，可能會(huì)多一些系統(tǒng)的方法會(huì)受影響
可以通過(guò)過(guò)濾特定命名規(guī)則的代碼找不到的情況，做上傳服務(wù)器操作或跳轉(zhuǎn)到首頁(yè)或特定的頁(yè)面,防止程序崩潰
AOP封裝成SDK,一般在這一層不作處理，而進(jìn)行消息轉(zhuǎn)發(fā)
消息轉(zhuǎn)發(fā)
1.快速轉(zhuǎn)發(fā)流程
instrumentObjcMessageSends輔助分析
在消息慢速轉(zhuǎn)發(fā)流程中IMP lookUpImpOrForward(id inst, SEL sel, Class cls, int behavior),若找到了則進(jìn)入log_and_fill_cache，滿足條件slowpath(objcMsgLogEnabled && implementer)進(jìn)入logMessageSend，對(duì)方法進(jìn)行打印記錄，詳細(xì)記錄到文件路徑下/tmp/msgSends
通過(guò)instrumentObjcMessageSends改變objcMsgLogEnabled的值為true,從而記錄調(diào)用流程，在外部使用內(nèi)部的方法需要添加關(guān)鍵字extern。extern void instrumentObjcMessageSends(BOOL flag);
在LGPerson中添加一個(gè)沒(méi)有實(shí)現(xiàn)的對(duì)象方法sayHello,查看方法調(diào)用情況，在/tmp/msgSends路徑下會(huì)生成一個(gè)名為msgSends-41550的文件,查看文件中的內(nèi)容即為方法的調(diào)用流程,發(fā)現(xiàn)調(diào)用了- LGPerson NSObject forwardingTargetForSelector:方法
此時(shí)可以在LGPerson中重寫(xiě)forwardingTargetForSelector:方法，程序崩潰之前打印了sayHello方法說(shuō)明可以在此方法內(nèi)將有sayHello方法實(shí)現(xiàn)的類返回或在此方法內(nèi)添加sayHello的Imp。
- 1.forwardingTargetForSelector:方法中將有sayHello方法實(shí)現(xiàn)的類返回
// 1: 快速轉(zhuǎn)發(fā)
- (id)forwardingTargetForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
// runtime + aSelector + addMethod + imp
//return [super forwardingTargetForSelector:aSelector];
return [LGStudent alloc];
}
- 2.forwardingTargetForSelector:方法中動(dòng)態(tài)添加sayHello的Imp,結(jié)果程序崩潰，為什么呢？？？
2.慢速轉(zhuǎn)發(fā)流程
在msgSends-41550的文件中發(fā)現(xiàn)在forwardingTargetForSelector:方法之后，還調(diào)用了- LGPerson NSObject methodSignatureForSelector:方法
查閱官方文檔- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector和- (void)forwardInvocation:(NSInvocation *)anInvocation要搭配使用，有兩種方式，一種是重寫(xiě)方法，但是不做處理，另一種是進(jìn)行事務(wù)的重新賦值
- 1.重寫(xiě)- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector和- (void)forwardInvocation:(NSInvocation *)anInvocation方法，不做處理，僅僅防止奔潰
- 2.事務(wù)重新賦值
anInvocation.target = [LGStudent alloc];[anInvocation invoke];對(duì)事物進(jìn)行revoke。
大膽做個(gè)假設(shè)可以將事務(wù)進(jìn)行本類方法指定嗎，是可以的
消息轉(zhuǎn)發(fā)流程圖如下
以上是以上帝視角探索消息轉(zhuǎn)發(fā)流程，有沒(méi)有更好的辦法呢？
反匯編探索消息轉(zhuǎn)發(fā)流程
程序崩潰后通過(guò)bt查看堆棧信息,在程序崩潰之前調(diào)用了CoreFoundation中的forwarding_prep_0和forwarding，尋找CoreFoundation的源碼,在官網(wǎng)源碼查找并下載CF-1151.16.tar，在源碼中查找forwarding_prep_0，發(fā)現(xiàn)無(wú)法找到。
- 讀取CorFoundation鏡像文件，路徑為/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation,找到CoreFoundation的可執(zhí)行文件
- 通過(guò)工具Hopper.Demo.dmg查看編譯后的代碼，付費(fèi)軟件使用試用版try the demo
- 全局搜索
__forwarding_prep_0___,點(diǎn)擊跳轉(zhuǎn)到函數(shù)入口
- 進(jìn)入
__forwarding__流程圖如下，和前面探索的消息轉(zhuǎn)發(fā)流程不謀而合。
