Objective-C 是一門動(dòng)態(tài)語(yǔ)言，它將很多靜態(tài)語(yǔ)言在編譯和鏈接時(shí)期做的事情，放到了運(yùn)行時(shí)來(lái)處理。之所以能具備這種特性，離不開(kāi) Runtime 這個(gè)庫(kù)。Runtime 很好的解決了如何在運(yùn)行時(shí)期找到調(diào)用方法這樣的問(wèn)題。
消息發(fā)送
在 Objective-C 中，方法調(diào)用稱為向?qū)ο蟀l(fā)送消息：
// MyClass 類
@interface MyClass: NSObject
- (void)printLog;
@end
@implementation MyClass
- (void)printLog {
NSLog(@"print log !");
}
@end
MyClass *myClass = [[MyClass alloc] init];
[myClass printLog];
// 輸出： print log !
上面代碼中的 [myClass printLog] 也可以這么寫(xiě)：
((void (*)(id, SEL))(void *) objc_msgSend)(myClass, @selector(printLog));
[myClass printLog] 經(jīng)過(guò)編譯后就是調(diào)用 objc_msgSend 方法。
我們看看這個(gè)方法的文檔定義：
id objc_msgSend(id self, SEL op, ...);
self：消息的接收者 op： 消息的方法名，C 字符串... ：參數(shù)列表
Runtime 是如何找到實(shí)例方法的具體實(shí)現(xiàn)的？
基礎(chǔ)概念
講之前，我們需要先明白一些基礎(chǔ)概念：Objective-C 是一門面向?qū)ο蟮恼Z(yǔ)言，對(duì)象又分為實(shí)例對(duì)象、類對(duì)象、元類對(duì)象以及根元類對(duì)象。它們是通過(guò)一個(gè)叫 isa 的指針來(lái)關(guān)聯(lián)起來(lái)，具體關(guān)系如下圖：
以我們上文的代碼為例：
MyClass *myClass = [[MyClass alloc] init];
整理下相互間的關(guān)系：
myClass 是實(shí)例對(duì)象
MyClass 是類對(duì)象
MyClass 的元類就是 NSObject 的元類
NSObject 就是 Root class (class)
NSObject 的 superclass 為 nil
NSObject 的元類就是它自己
NSObject 的元類的 superclass 就是 NSObject
接著，我們用代碼來(lái)驗(yàn)證下上文的關(guān)系：
MyClass *myClass = [[MyClass alloc] init];
Class class = [myClass class];
Class metaClass = object_getClass(class);
Class metaOfMetaClass = object_getClass(metaClass);
Class rootMetaClass = object_getClass(metaOfMetaClass);
Class superclass = class_getSuperclass(class);
Class superOfSuperclass = class_getSuperclass(superclass);
Class superOfMetaOfSuperclass = class_getSuperclass(object_getClass(superclass));
NSLog(@"MyClass 實(shí)例對(duì)象是：%p",myClass);
NSLog(@"MyClass 類對(duì)象是：%p",class);
NSLog(@"MyClass 元類對(duì)象是：%p",metaClass);
NSLog(@"MyClass 元類對(duì)象的元類對(duì)象是：%p",metaOfMetaClass);
NSLog(@"MyClass 根元類對(duì)象是：%p",rootMetaClass);
NSLog(@"MyClass 父類是：%@",class_getSuperclass(class));
NSLog(@"MyClass 父類的父類是：%@",superOfSuperclass);
NSLog(@"MyClass 父類的元類的父類是：%@",superOfMetaOfSuperclass);
NSLog(@"NSObject 元類對(duì)象是：%p",object_getClass([NSObject class]));
NSLog(@"NSObject 父類是：%@",[[NSObject class] superclass]);
NSLog(@"NSObject 元類對(duì)象的父類是：%@",[object_getClass([NSObject class]) superclass]);
//輸出：
MyClass 實(shí)例對(duì)象是：0x60c00000b8d0
MyClass 類對(duì)象是：0x109ae3fd0
MyClass 元類對(duì)象是：****0x109ae3fa8
MyClass 元類對(duì)象的元類對(duì)象是：****0x10ab02e58**
MyClass 根元類對(duì)象是：0x10ab02e58
MyClass 父類是：NSObject
MyClass 父類的父類是：(null)
MyClass 父類的元類的父類是：NSObject
NSObject 元類對(duì)象是：0x10ab02e58
NSObject 父類是：(null)
NSObject 元類對(duì)象的父類是：NSObject
可以發(fā)現(xiàn)，輸出結(jié)果是完全符合我們的結(jié)論的！
現(xiàn)在我們能知道各種對(duì)象之間的關(guān)系：
實(shí)例對(duì)象通過(guò) isa 指針，找到類對(duì)象 Class；類對(duì)象同樣通過(guò) isa 指針，找到元類對(duì)象；元類對(duì)象也是通過(guò) isa 指針，找到根元類對(duì)象；最后，根元類對(duì)象的 isa 指針，指向自己。可以發(fā)現(xiàn) NSObject 是整個(gè)消息機(jī)制的核心，絕大數(shù)對(duì)象都繼承自它。
尋找流程
上文提到了，一個(gè) Objective-C 方法會(huì)被編譯成 objc_msgSend，這個(gè)函數(shù)有兩個(gè)默認(rèn)參數(shù)，id 類型的 self, SEL 類型的 op。我們先看看 id 的定義：
typedef struct objc_object *id;
struct objc_object {
Class _Nonnull isa? OBJC_ISA_AVAILABILITY;
};
我們可以看到，在 objc_object 結(jié)構(gòu)體中，只有一個(gè)指向 Class 類型的 isa 指針。
我們?cè)倏纯?Class 的定義：
struct objc_class {
Class _Nonnull isa? OBJC_ISA_AVAILABILITY;
#if !__OBJC2__
Class _Nullable super_class? OBJC2_UNAVAILABLE;
const char * _Nonnull name OBJC2_UNAVAILABLE;
long version OBJC2_UNAVAILABLE;
long info? OBJC2_UNAVAILABLE;
long instance_size OBJC2_UNAVAILABLE;
struct objc_ivar_list * _Nullable ivars? OBJC2_UNAVAILABLE;
struct objc_method_list * _Nullable * _Nullable methodLists? OBJC2_UNAVAILABLE;
struct objc_cache * _Nonnull cache OBJC2_UNAVAILABLE;
struct objc_protocol_list * _Nullable protocols? OBJC2_UNAVAILABLE;
#endif
} OBJC2_UNAVAILABLE;
里面有很多參數(shù)，很顯眼的能看到這一行：
struct objc_method_list * _Nullable * _Nullable methodLists OBJC2_UNAVAILABLE;
看名字也容易理解，這個(gè) methodLists 就是用來(lái)存放方法列表的。我們?cè)倏纯?objc_method_list 這個(gè)結(jié)構(gòu)體：
struct objc_method_list {
struct objc_method_list * _Nullable obsolete OBJC2_UNAVAILABLE;
int method_count OBJC2_UNAVAILABLE;
#ifdef __LP64__
int space? OBJC2_UNAVAILABLE;
#endif
/* variable length structure */
struct objc_method method_list[1]? OBJC2_UNAVAILABLE;
}
里面的 objc_method ，也就是我們熟悉的 Method：
struct objc_method {
SEL _Nonnull method_name OBJC2_UNAVAILABLE;
char * _Nullable method_types? OBJC2_UNAVAILABLE;
IMP _Nonnull method_imp? OBJC2_UNAVAILABLE;
}
Method 里面保存了三個(gè)參數(shù)：
方法的名稱
方法的類型
方法的具體實(shí)現(xiàn)，由 IMP 指針指向
經(jīng)過(guò)層層挖掘，我們能明白實(shí)例對(duì)象調(diào)用方法的大致邏輯：
MyClass *myClass = [[MyClass alloc] init];
[myClass printLog];
先被編譯成? ((void (*)(id, SEL))(void *) objc_msgSend)(myClass, @selector(printLog));
沿著入?yún)?myClass 的 isa 指針，找到 myClass 的類對(duì)象（Class），也就是 MyClass
接著在 MyClass 的方法列表 methodLists 中，找到對(duì)應(yīng)的 Method
最后找到 Method 中的 IMP 指針，執(zhí)行具體實(shí)現(xiàn)
類對(duì)象的類方法又是怎么找到并執(zhí)行的？
由上文，我們已經(jīng)知道，實(shí)例對(duì)象是通過(guò) isa 指針，找到其類對(duì)象（Class）中保存的方法列表中的具體實(shí)現(xiàn)的。
比如：
MyClass *myClass = [[MyClass alloc] init];
[myClass printLog];
可以理解為：printLog 方法就是保存在 MyClass 中的。
那么如果是個(gè)類方法，又是保存在什么地方的呢？
我們回顧下 Class? 的定義：
struct objc_class {
Class _Nonnull isa? OBJC_ISA_AVAILABILITY;
#if !__OBJC2__
Class _Nullable super_class? OBJC2_UNAVAILABLE;
const char * _Nonnull name OBJC2_UNAVAILABLE;
long version OBJC2_UNAVAILABLE;
long info? OBJC2_UNAVAILABLE;
long instance_size OBJC2_UNAVAILABLE;
struct objc_ivar_list * _Nullable ivars? OBJC2_UNAVAILABLE;
struct objc_method_list * _Nullable * _Nullable methodLists? OBJC2_UNAVAILABLE;
struct objc_cache * _Nonnull cache OBJC2_UNAVAILABLE;
struct objc_protocol_list * _Nullable protocols? OBJC2_UNAVAILABLE;
#endif
} OBJC2_UNAVAILABLE;
可以發(fā)現(xiàn)到這一行：
Class _Nonnull isa OBJC_ISA_AVAILABILITY;
這里的 isa 同樣是指向一個(gè) Class 的指針。上文中，我們也知道了類對(duì)象的 isa 指針是指向元類對(duì)象的。那么不難得出：
類對(duì)象的類方法，是保存在元類對(duì)象中的！
類對(duì)象和元類對(duì)象都是? Class 類型，僅僅服務(wù)的對(duì)象不同罷了。找到了元類對(duì)象，自然就找到了元類對(duì)象中的 methodLists，接下來(lái)就和實(shí)例對(duì)象的方法尋找調(diào)用一樣的流程了。
如何提高方法查找的效率？
上文中，我們大概知道，方法是通過(guò) isa 指針，查找 Class 中的 methodLists 的。如果子類沒(méi)實(shí)現(xiàn)對(duì)應(yīng)的方法實(shí)現(xiàn)，還會(huì)沿著父類去查找。整個(gè)工程，可能有成萬(wàn)上億個(gè)方法，是如何解決性能問(wèn)題的呢？
例如：
for (int i = 0; i < 100000; ++i) {
? ? MyClass *myObject = myObjects[i];
? ? [myObject methodA];
}
這種高頻次的調(diào)用 methodA，如果每調(diào)用一次都需要遍歷，性能是非常差的。所以引入了 Class Cache 機(jī)制：
Class Cache 認(rèn)為，當(dāng)一個(gè)方法被調(diào)用，那么它之后被調(diào)用的可能性就越大。
查找方法時(shí)，會(huì)先從緩存中查找，找到直接返回 ；找不到，再去 Class 的方法列表中找。
在上文中 Class 的定義中，我們可以發(fā)現(xiàn)? cache：
struct objc_cache * _Nonnull cache OBJC2_UNAVAILABLE;
說(shuō)明了緩存是存在類中的，每個(gè)類都有一份方法緩存，而不是每個(gè)類的 object 都保存了一份。
關(guān)于父類（superclass）
在 Objective-C 中，子類調(diào)用一個(gè)方法，如果沒(méi)有子類沒(méi)有實(shí)現(xiàn)，父類實(shí)現(xiàn)了，會(huì)去調(diào)用父類的實(shí)現(xiàn)。上文中，找到 methodLists 后，尋找 Method 的大致過(guò)程如下：
ps: 其實(shí)這里的尋找過(guò)程遠(yuǎn)沒(méi)有這么簡(jiǎn)單，可能會(huì)遍歷很多遍，因?yàn)槲覀兛赡軙?huì)在運(yùn)行時(shí)動(dòng)態(tài)的添加方法（比如 category）。遍歷的過(guò)程中同樣不時(shí)的去查詢緩存表。
消息轉(zhuǎn)發(fā)
如果方法列表（methodLists）沒(méi)找到對(duì)應(yīng)的 selector 呢？
// ViewController.m 中 （未實(shí)現(xiàn) myTestPrint 方法）
[self performSelector:@selector(myTestPrint:) withObject:@"，你好 ！"];
系統(tǒng)會(huì)提供三次補(bǔ)救的機(jī)會(huì)。
第一次
+ (BOOL)resolveInstanceMethod:(SEL)sel {} (實(shí)例方法)
+ (BOOL)resolveClassMethod:(SEL)sel {}? (類方法)
這兩個(gè)方法，一個(gè)針對(duì)實(shí)例方法；一個(gè)針對(duì)類方法。返回值都是 Bool。
使用示例：
// ViewController.m 中
void myMethod(id self, SEL _cmd,NSString *nub) {
NSLog(@"ifelseboyxx%@",nub);
}
+ (BOOL)resolveInstanceMethod:(SEL)sel {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundeclared-selector"
? ? if (sel == @selector(myTestPrint:)) {
#pragma clang diagnostic pop
? ? ? ? class_addMethod([self class],sel,(IMP)myMethod,"v@:@");
? ? ? ? return YES;
? ? }else {
? ? ? ? return [super resolveInstanceMethod:sel];
? ? }
}
我們只需要在 resolveInstanceMethod: 方法中，利用 class_addMethod 方法，將未實(shí)現(xiàn)的 myTestPrint: 綁定到 myMethod 上就能完成轉(zhuǎn)發(fā)，最后返回 YES。
第二次
- (id)forwardingTargetForSelector:(SEL)aSelector {}
這個(gè)方法要求返回一個(gè) id。使用場(chǎng)景一般是將 A 類的某個(gè)方法，轉(zhuǎn)發(fā)到 B 類的實(shí)現(xiàn)中去。
使用示例：
想轉(zhuǎn)發(fā)到 Person 類中的 -myTestPrint: 方法中：
@interface Person : NSObject
@end
@implementation Person
- (void)myTestPrint:(NSString *)str {
NSLog(@"ifelseboyxx%@",str);
}
@end
// ViewController.m 中
- (id)forwardingTargetForSelector:(SEL)aSelector {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundeclared-selector"
? ? if (aSelector == @selector(myTestPrint:)) {
#pragma clang diagnostic pop
? ? ? ? return [Person new];
? ? }else{
? ? ? ? return [super forwardingTargetForSelector:aSelector];
? ? }
}
第三次
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {}
- (void)forwardInvocation:(NSInvocation *)anInvocation {}
第一個(gè)要求返回一個(gè)方法簽名，第二個(gè)方法轉(zhuǎn)發(fā)具體的實(shí)現(xiàn)。二者相互依賴，只有返回了正確的方法簽名，才會(huì)執(zhí)行第二個(gè)方法。
這次的轉(zhuǎn)發(fā)作用和第二次的比較類似，都是將 A 類的某個(gè)方法，轉(zhuǎn)發(fā)到 B 類的實(shí)現(xiàn)中去。不同的是，第三次的轉(zhuǎn)發(fā)相對(duì)于第二次更加靈活，forwardingTargetForSelector: 只能固定的轉(zhuǎn)發(fā)到一個(gè)對(duì)象；forwardInvocation:?可以讓我們轉(zhuǎn)發(fā)到多個(gè)對(duì)象中去。
使用實(shí)例：
想轉(zhuǎn)發(fā)到 Person 類以及 Animal 類中的 -myTestPrint: 方法中：
@interface Person : NSObject
@end
@implementation Person
- (void)myTestPrint:(NSString *)str {
NSLog(@"ifelseboyxx%@",str);
}
@end
@interface Animal : NSObject
@end
@implementation Animal
- (void)myTestPrint:(NSString *)str {
NSLog(@"tiger%@",str);
}
@end
// ViewController.m 中
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundeclared-selector"
if (aSelector == @selector(myTestPrint:)) {
#pragma clang diagnostic pop
return [NSMethodSignature? signatureWithObjCTypes:"v@:@"];
}
return [super methodSignatureForSelector:aSelector];
}
- (void)forwardInvocation:(NSInvocation *)anInvocation {
Person *person = [Person new];
Animal *animal = [Animal new];
if ([person respondsToSelector:anInvocation.selector]) {
[anInvocation invokeWithTarget:person];
}
if ([animal respondsToSelector:anInvocation.selector]) {
[anInvocation invokeWithTarget:animal];
}
}
如果到了第三次機(jī)會(huì)，還沒(méi)找到對(duì)應(yīng)的實(shí)現(xiàn)，就會(huì) crash：
unrecognized selector sent to instance 0x7f9f817072b0
