本文轉載自:http://southpeak.github.io/2014/11/03/objective-c-runtime-3/
前面我們討論了Runtime中對類和對象的處理，及對成員變量與屬性的處理。這一章，我們就要開始討論Runtime中最有意思的一部分：消息處理機制。我們將詳細討論消息的發送及消息的轉發。不過在討論消息之前，我們先來了解一下與方法相關的一些內容。
SEL又叫選擇器，是表示一個方法的selector的指針，其定義如下：
typedef struct objc_selector *SEL;
objc_selector結構體的詳細定義沒有在頭文件中找到。方法的selector用于表示運行時方法的名字。Objective-C在編譯時，會依據每一個方法的名字、參數序列，生成一個唯一的整型標識(Int類型的地址)，這個標識就是SEL。如下代碼所示：
SEL sel1 =@selector(method1);
NSLog(@"sel : %p", sel1);
上面的輸出為：
2014-10-3018:40:07.518RuntimeTest[52734:466626] sel :0x100002d72
兩個類之間，不管它們是父類與子類的關系，還是之間沒有這種關系，只要方法名相同，那么方法的SEL就是一樣的。每一個方法都對應著一個SEL。所以在Objective-C同一個類(及類的繼承體系)中，不能存在2個同名的方法，即使參數類型不同也不行。相同的方法只能對應一個SEL。這也就導致Objective-C在處理相同方法名且參數個數相同但類型不同的方法方面的能力很差。如在某個類中定義以下兩個方法：
- (void)setWidth:(int)width;
- (void)setWidth:(double)width;
這樣的定義被認為是一種編譯錯誤，所以我們不能像C++, C#那樣。而是需要像下面這樣來聲明：
-(void)setWidthIntValue:(int)width;
-(void)setWidthDoubleValue:(double)width;
當然，不同的類可以擁有相同的selector，這個沒有問題。不同類的實例對象執行相同的selector時，會在各自的方法列表中去根據selector去尋找自己對應的IMP。
工程中的所有的SEL組成一個Set集合，Set的特點就是唯一，因此SEL是唯一的。因此，如果我們想到這個方法集合中查找某個方法時，只需要去找到這個方法對應的SEL就行了，SEL實際上就是根據方法名hash化了的一個字符串，而對于字符串的比較僅僅需要比較他們的地址就可以了，可以說速度上無語倫比！！但是，有一個問題，就是數量增多會增大hash沖突而導致的性能下降（或是沒有沖突，因為也可能用的是perfect hash）。但是不管使用什么樣的方法加速，如果能夠將總量減少（多個方法可能對應同一個SEL），那將是最犀利的方法。那么，我們就不難理解，為什么SEL僅僅是函數名了。
本質上，SEL只是一個指向方法的指針（準確的說，只是一個根據方法名hash化了的KEY值，能唯一代表一個方法），它的存在只是為了加快方法的查詢速度。這個查找過程我們將在下面討論。
我們可以在運行時添加新的selector，也可以在運行時獲取已存在的selector，我們可以通過下面三種方法來獲取SEL:
sel_registerName函數
Objective-C編譯器提供的@selector()
NSSelectorFromString()方法
IMP實際上是一個函數指針，指向方法實現的首地址。其定義如下：
id(*IMP)(id, SEL, ...)
這個函數使用當前CPU架構實現的標準的C調用約定。第一個參數是指向self的指針(如果是實例方法，則是類實例的內存地址；如果是類方法，則是指向元類的指針)，第二個參數是方法選擇器(selector)，接下來是方法的實際參數列表。
前面介紹過的SEL就是為了查找方法的最終實現IMP的。由于每個方法對應唯一的SEL，因此我們可以通過SEL方便快速準確地獲得它所對應的IMP，查找過程將在下面討論。取得IMP后，我們就獲得了執行這個方法代碼的入口點，此時，我們就可以像調用普通的C語言函數一樣來使用這個函數指針了。
通過取得IMP，我們可以跳過Runtime的消息傳遞機制，直接執行IMP指向的函數實現，這樣省去了Runtime消息傳遞過程中所做的一系列查找操作，會比直接向對象發送消息高效一些。
介紹完SEL和IMP，我們就可以來講講Method了。Method用于表示類定義中的方法，則定義如下：
typedef struct objc_method *Method;
structobjc_method {
SEL method_name? ? ? ? ? ? ? ? OBJC2_UNAVAILABLE;// 方法名
char*method_types? ? ? ? ? ? ? ? OBJC2_UNAVAILABLE;
IMP method_imp? ? ? ? ? ? OBJC2_UNAVAILABLE;// 方法實現
}
我們可以看到該結構體中包含一個SEL和IMP，實際上相當于在SEL和IMP之間作了一個映射。有了SEL，我們便可以找到對應的IMP，從而調用方法的實現代碼。具體操作流程我們將在下面討論。
objc_method_description定義了一個Objective-C方法，其定義如下：
struct objc_method_description { SEL name;char*types; };
Runtime提供了一系列的方法來處理與方法相關的操作。包括方法本身及SEL。本節我們介紹一下這些函數。
方法操作相關函數包括下以：
// 調用指定方法的實現
id method_invoke (id receiver, Method m, ... );
// 調用返回一個數據結構的方法的實現
void method_invoke_stret (id receiver, Method m, ... );
// 獲取方法名
SEL method_getName ( Method m );
// 返回方法的實現
IMP method_getImplementation ( Method m );
// 獲取描述方法參數和返回值類型的字符串
const char* method_getTypeEncoding ( Method m );
// 獲取方法的返回值類型的字符串
char* method_copyReturnType ( Method m );
// 獲取方法的指定位置參數的類型字符串
char* method_copyArgumentType ( Method m,unsignedintindex );
// 通過引用返回方法的返回值類型字符串
void method_getReturnType ( Method m,char*dst, size_t dst_len );
// 返回方法的參數的個數
unsigned int method_getNumberOfArguments ( Method m );
// 通過引用返回方法指定位置參數的類型字符串
void method_getArgumentType ( Method m,unsigned int index,char*dst, size_t dst_len );
// 返回指定方法的方法描述結構體
struct objc_method_description * method_getDescription ( Method m );
// 設置方法的實現
IMP method_setImplementation ( Method m, IMP imp );
// 交換兩個方法的實現
void method_exchangeImplementations ( Method m1, Method m2 );
method_invoke函數，返回的是實際實現的返回值。參數receiver不能為空。這個方法的效率會比method_getImplementation和method_getName更快。
method_getName函數，返回的是一個SEL。如果想獲取方法名的C字符串，可以使用sel_getName(method_getName(method))。
method_getReturnType函數，類型字符串會被拷貝到dst中。
method_setImplementation函數，注意該函數返回值是方法之前的實現。
選擇器相關的操作函數包括：
// 返回給定選擇器指定的方法的名稱
constchar* sel_getName ( SEL sel );
// 在Objective-C Runtime系統中注冊一個方法，將方法名映射到一個選擇器，并返回這個選擇器
SEL sel_registerName (constchar*str );
// 在Objective-C Runtime系統中注冊一個方法
SEL sel_getUid (constchar*str );
// 比較兩個選擇器
BOOLsel_isEqual ( SEL lhs, SEL rhs );
sel_registerName函數：在我們將一個方法添加到類定義時，我們必須在Objective-C Runtime系統中注冊一個方法名以獲取方法的選擇器。
在Objective-C中，消息直到運行時才綁定到方法實現上。編譯器會將消息表達式[receiver message]轉化為一個消息函數的調用，即objc_msgSend。這個函數將消息接收者和方法名作為其基礎參數，如以下所示：
objc_msgSend(receiver, selector)
如果消息中還有其它參數，則該方法的形式如下所示：
objc_msgSend(receiver, selector, arg1, arg2, ...)
這個函數完成了動態綁定的所有事情：
首先它找到selector對應的方法實現。因為同一個方法可能在不同的類中有不同的實現，所以我們需要依賴于接收者的類來找到的確切的實現。
它調用方法實現，并將接收者對象及方法的所有參數傳給它。
最后，它將實現返回的值作為它自己的返回值。
消息的關鍵在于我們前面章節討論過的結構體objc_class，這個結構體有兩個字段是我們在分發消息的關注的：
指向父類的指針
一個類的方法分發表，即methodLists。
當我們創建一個新對象時，先為其分配內存，并初始化其成員變量。其中isa指針也會被初始化，讓對象可以訪問類及類的繼承體系。
下圖演示了這樣一個消息的基本框架：
當消息發送給一個對象時，objc_msgSend通過對象的isa指針獲取到類的結構體，然后在方法分發表里面查找方法的selector。如果沒有找到selector，則通過objc_msgSend結構體中的指向父類的指針找到其父類，并在父類的分發表里面查找方法的selector。依此，會一直沿著類的繼承體系到達NSObject類。一旦定位到selector，函數會就獲取到了實現的入口點，并傳入相應的參數來執行方法的具體實現。如果最后沒有定位到selector，則會走消息轉發流程，這個我們在后面討論。
為了加速消息的處理，運行時系統緩存使用過的selector及對應的方法的地址。這點我們在前面討論過，不再重復。
objc_msgSend有兩個隱藏參數：
消息接收對象
方法的selector
這兩個參數為方法的實現提供了調用者的信息。之所以說是隱藏的，是因為它們在定義方法的源代碼中沒有聲明。它們是在編譯期被插入實現代碼的。
雖然這些參數沒有顯示聲明，但在代碼中仍然可以引用它們。我們可以使用self來引用接收者對象，使用_cmd來引用選擇器。如下代碼所示：
- strange
{
idtarget = getTheReceiver();
SEL method = getTheMethod();
if( target ==self|| method == _cmd )
returnnil;
return[target performSelector:method];
}
當然，這兩個參數我們用得比較多的是self，_cmd在實際中用得比較少。
Runtime中方法的動態綁定讓我們寫代碼時更具靈活性，如我們可以把消息轉發給我們想要的對象，或者隨意交換一個方法的實現等。不過靈活性的提升也帶來了性能上的一些損耗。畢竟我們需要去查找方法的實現，而不像函數調用來得那么直接。當然，方法的緩存一定程度上解決了這一問題。
我們上面提到過，如果想要避開這種動態綁定方式，我們可以獲取方法實現的地址，然后像調用函數一樣來直接調用它。特別是當我們需要在一個循環內頻繁地調用一個特定的方法時，通過這種方式可以提高程序的性能。
NSObject類提供了methodForSelector:方法，讓我們可以獲取到方法的指針，然后通過這個指針來調用實現代碼。我們需要將methodForSelector:返回的指針轉換為合適的函數類型，函數參數和返回值都需要匹配上。
我們通過以下代碼來看看methodForSelector:的使用：
void(*setter)(id, SEL,BOOL);
int i;
setter= (void(*)(id, SEL,BOOL))[target methodForSelector:@selector(setFilled:)];
for(i =0; i <1000; i++)
setter(targetList[i],@selector(setFilled:),YES);
這里需要注意的就是函數指針的前兩個參數必須是id和SEL。
當然這種方式只適合于在類似于for循環這種情況下頻繁調用同一方法，以提高性能的情況。另外，methodForSelector:是由Cocoa運行時提供的；它不是Objective-C語言的特性。
當一個對象能接收一個消息時，就會走正常的方法調用流程。但如果一個對象無法接收指定消息時，又會發生什么事呢？默認情況下，如果是以[object message]的方式調用方法，如果object無法響應message消息時，編譯器會報錯。但如果是以perform...的形式來調用，則需要等到運行時才能確定object是否能接收message消息。如果不能，則程序崩潰。
通常，當我們不能確定一個對象是否能接收某個消息時，會先調用respondsToSelector:來判斷一下。如下代碼所示：
if([self respondsToSelector:@selector(method)]) {
[self performSelector:@selector(method)];
}
不過，我們這邊想討論下不使用respondsToSelector:判斷的情況。這才是我們這一節的重點。
當一個對象無法接收某一消息時，就會啟動所謂”消息轉發(message forwarding)“機制，通過這一機制，我們可以告訴對象如何處理未知的消息。默認情況下，對象接收到未知的消息，會導致程序崩潰，通過控制臺，我們可以看到以下異常信息：
-[SUTRuntimeMethod method]: unrecognized selector sent to instance 0x100111940
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[SUTRuntimeMethod method]: unrecognized selector sent to instance 0x100111940'
這段異常信息實際上是由NSObject的”doesNotRecognizeSelector“方法拋出的。不過，我們可以采取一些措施，讓我們的程序執行特定的邏輯，而避免程序的崩潰。
消息轉發機制基本上分為三個步驟：
動態方法解析
備用接收者
完整轉發
下面我們詳細討論一下這三個步驟。
對象在接收到未知的消息時，首先會調用所屬類的類方法+resolveInstanceMethod:(實例方法)或者+resolveClassMethod:(類方法)。在這個方法中，我們有機會為該未知消息新增一個”處理方法””。不過使用該方法的前提是我們已經實現了該”處理方法”，只需要在運行時通過class_addMethod函數動態添加到類里面就可以了。如下代碼所示：
void functionForMethod1(id self, SEL _cmd) {
NSLog(@"%@, %p",self, _cmd);
}
+ (BOOL)resolveInstanceMethod:(SEL)sel {
NSString*selectorString =NSStringFromSelector(sel);
if([selectorString isEqualToString:@"method1"]) {
class_addMethod(self.class,@selector(method1), (IMP)functionForMethod1,"@:");
}
return[superresolveInstanceMethod:sel];
}
不過這種方案更多的是為了實現@dynamic屬性。
如果在上一步無法處理消息，則Runtime會繼續調以下方法：
- (id)forwardingTargetForSelector:(SEL)aSelector
如果一個對象實現了這個方法，并返回一個非nil的結果，則這個對象會作為消息的新接收者，且消息會被分發到這個對象。當然這個對象不能是self自身，否則就是出現無限循環。當然，如果我們沒有指定相應的對象來處理aSelector，則應該調用父類的實現來返回結果。
使用這個方法通常是在對象內部，可能還有一系列其它對象能處理該消息，我們便可借這些對象來處理消息并返回，這樣在對象外部看來，還是由該對象親自處理了這一消息。如下代碼所示：
@interface SUTRuntimeMethodHelper:NSObject
- (void)method2;
@end
@implementation SUTRuntimeMethodHelper
- (void)method2 {
NSLog(@"%@, %p",self, _cmd);
}
@end
#pragma mark -
@interfaceSUTRuntimeMethod(){
SUTRuntimeMethodHelper *_helper;
}
@end
@implementationSUTRuntimeMethod
+ (instancetype)object {
return[[selfalloc] init];
}
- (instancetype)init {
self= [superinit];
if(self!=nil) {
_helper = [[SUTRuntimeMethodHelper alloc] init];
}
returnself;
}
- (void)test {
[selfperformSelector:@selector(method2)];
}
- (id)forwardingTargetForSelector:(SEL)aSelector {
NSLog(@"forwardingTargetForSelector");
NSString*selectorString =NSStringFromSelector(aSelector);
// 將消息轉發給_helper來處理
if([selectorString isEqualToString:@"method2"]) {
return_helper;
}
return[superforwardingTargetForSelector:aSelector];
}
@end
這一步合適于我們只想將消息轉發到另一個能處理該消息的對象上。但這一步無法對消息進行處理，如操作消息的參數和返回值。
如果在上一步還不能處理未知消息，則唯一能做的就是啟用完整的消息轉發機制了。此時會調用以下方法：
- (void)forwardInvocation:(NSInvocation*)anInvocation
運行時系統會在這一步給消息接收者最后一次機會將消息轉發給其它對象。對象會創建一個表示消息的NSInvocation對象，把與尚未處理的消息有關的全部細節都封裝在anInvocation中，包括selector，目標(target)和參數。我們可以在forwardInvocation方法中選擇將消息轉發給其它對象。
forwardInvocation:方法的實現有兩個任務：
定位可以響應封裝在anInvocation中的消息的對象。這個對象不需要能處理所有未知消息。
使用anInvocation作為參數，將消息發送到選中的對象。anInvocation將會保留調用結果，運行時系統會提取這一結果并將其發送到消息的原始發送者。
不過，在這個方法中我們可以實現一些更復雜的功能，我們可以對消息的內容進行修改，比如追回一個參數等，然后再去觸發消息。另外，若發現某個消息不應由本類處理，則應調用父類的同名方法，以便繼承體系中的每個類都有機會處理此調用請求。
還有一個很重要的問題，我們必須重寫以下方法：
- (NSMethodSignature*)methodSignatureForSelector:(SEL)aSelector
消息轉發機制使用從這個方法中獲取的信息來創建NSInvocation對象。因此我們必須重寫這個方法，為給定的selector提供一個合適的方法簽名。
完整的示例如下所示：
- (NSMethodSignature*)methodSignatureForSelector:(SEL)aSelector {
NSMethodSignature*signature = [supermethodSignatureForSelector:aSelector];
if(!signature) {
if([SUTRuntimeMethodHelper instancesRespondToSelector:aSelector]) {
signature = [SUTRuntimeMethodHelper instanceMethodSignatureForSelector:aSelector];
}
}
returnsignature;
}
- (void)forwardInvocation:(NSInvocation*)anInvocation {
if([SUTRuntimeMethodHelper instancesRespondToSelector:anInvocation.selector]) {
[anInvocation invokeWithTarget:_helper];
}
}
NSObject的forwardInvocation:方法實現只是簡單調用了doesNotRecognizeSelector:方法，它不會轉發任何消息。這樣，如果不在以上所述的三個步驟中處理未知消息，則會引發一個異常。
從某種意義上來講，forwardInvocation:就像一個未知消息的分發中心，將這些未知的消息轉發給其它對象。或者也可以像一個運輸站一樣將所有未知消息都發送給同一個接收對象。這取決于具體的實現。
回過頭來看第二和第三步，通過這兩個方法我們可以允許一個對象與其它對象建立關系，以處理某些未知消息，而表面上看仍然是該對象在處理消息。通過這種關系，我們可以模擬“多重繼承”的某些特性，讓對象可以“繼承”其它對象的特性來處理一些事情。不過，這兩者間有一個重要的區別：多重繼承將不同的功能集成到一個對象中，它會讓對象變得過大，涉及的東西過多；而消息轉發將功能分解到獨立的小的對象中，并通過某種方式將這些對象連接起來，并做相應的消息轉發。
不過消息轉發雖然類似于繼承，但NSObject的一些方法還是能區分兩者。如respondsToSelector:和isKindOfClass:只能用于繼承體系，而不能用于轉發鏈。便如果我們想讓這種消息轉發看起來像是繼承，則可以重寫這些方法，如以下代碼所示：
- (BOOL)respondsToSelector:(SEL)aSelector
{
if( [superrespondsToSelector:aSelector])
returnYES;
else{
/* Here, test whether the aSelector message can? ? *
* be forwarded to another object and whether that? *
* object can respond to it. Return YES if it can.? */
}
returnNO;
}
在此，我們已經了解了Runtime中消息發送和轉發的基本機制。這也是Runtime的強大之處，通過它，我們可以為程序增加很多動態的行為，雖然我們在實際開發中很少直接使用這些機制(如直接調用objc_msgSend)，但了解它們有助于我們更多地去了解底層的實現。其實在實際的編碼過程中，我們也可以靈活地使用這些機制，去實現一些特殊的功能，如hook操作等。
