標籤:
前面我們討論了Runtime中對類和對象的處理,及對成員變數與屬性的處理。這一章,我們就要開始討論Runtime中最有意思的一部分:訊息處理機制。我們將詳細討論訊息的發送及訊息的轉寄。不過在討論訊息之前,我們先來瞭解一下與方法相關的一些內容。
基礎資料類型SEL
SEL又叫選取器,是表示一個方法的selector的指標,其定義如下:
typedef struct objc_selector *SEL;
objc_selector結構體的詳細定義沒有在<objc/runtime.h>標頭檔中找到。方法的selector用於表示運行時方法的名字。Objective-C在編譯時間,會依據每一個方法的名字、參數序列,產生一個唯一的整型標識(Int類型的地址),這個標識就是SEL。如下代碼所示:
SEL sel1 = @selector(method1);NSLog(@"sel : %p", sel1);
上面的輸出為:
2014-10-30 18:40:07.518 RuntimeTest[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
IMP實際上是一個函數指標,指向方法實現的首地址。其定義如下:
id (*IMP)(id, SEL, ...)
這個函數使用當前CPU架構實現的標準的C呼叫慣例。第一個參數是指向self的指標(如果是執行個體方法,則是類執行個體的記憶體位址;如果是類方法,則是指向元類的指標),第二個參數是方法選取器(selector),接下來是方法的實際參數列表。
前面介紹過的SEL就是為了尋找方法的最終實現IMP的。由於每個方法對應唯一的SEL,因此我們可以通過SEL方便快速準確地獲得它所對應的IMP,尋找過程將在下面討論。取得IMP後,我們就獲得了執行這個方法代碼的進入點,此時,我們就可以像調用普通的C語言函數一樣來使用這個函數指標了。
通過取得IMP,我們可以跳過Runtime的訊息傳遞機制,直接執行IMP指向的函數實現,這樣省去了Runtime訊息傳遞過程中所做的一系列尋找操作,會比直接向對象發送訊息高效一些。
Method
介紹完SEL和IMP,我們就可以來講講Method了。Method用於表示類定義中的方法,則定義如下:
typedef struct objc_method *Method;struct objc_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
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, unsigned int index );// 通過引用返回方法的傳回值類型字串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函數,注意該函數傳回值是方法之前的實現。
方法選取器
選取器相關的操作函數包括:
// 返回給定選取器指定的方法的名稱const char * sel_getName ( SEL sel );// 在Objective-C Runtime系統中註冊一個方法,將方法名映射到一個選取器,並返回這個選取器SEL sel_registerName ( const char *str );// 在Objective-C Runtime系統中註冊一個方法SEL sel_getUid ( const char *str );// 比較兩個選取器BOOL sel_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{ id target = getTheReceiver(); SEL method = getTheMethod(); if ( target == self || method == _cmd ) return nil; 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 [super resolveInstanceMethod: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 -@interface SUTRuntimeMethod () { SUTRuntimeMethodHelper *_helper;}@end@implementation SUTRuntimeMethod+ (instancetype)object { return [[self alloc] init];}- (instancetype)init { self = [super init]; if (self != nil) { _helper = [[SUTRuntimeMethodHelper alloc] init]; } return self;}- (void)test { [self performSelector:@selector(method2)];}- (id)forwardingTargetForSelector:(SEL)aSelector { NSLog(@"forwardingTargetForSelector"); NSString *selectorString = NSStringFromSelector(aSelector); // 將訊息轉寄給_helper來處理 if ([selectorString isEqualToString:@"method2"]) { return _helper; } return [super forwardingTargetForSelector: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 = [super methodSignatureForSelector:aSelector]; if (!signature) { if ([SUTRuntimeMethodHelper instancesRespondToSelector:aSelector]) { signature = [SUTRuntimeMethodHelper instanceMethodSignatureForSelector:aSelector]; } } return signature;}- (void)forwardInvocation:(NSInvocation *)anInvocation { if ([SUTRuntimeMethodHelper instancesRespondToSelector:anInvocation.selector]) { [anInvocation invokeWithTarget:_helper]; }}
NSObject的forwardInvocation:方法實現只是簡單調用了doesNotRecognizeSelector:方法,它不會轉寄任何訊息。這樣,如果不在以上所述的三個步驟中處理未知訊息,則會引發一個異常。
從某種意義上來講,forwardInvocation:就像一個未知訊息的分發中心,將這些未知的訊息轉寄給其它對象。或者也可以像一個運輸站一樣將所有未知訊息都發送給同一個接收對象。這取決於具體的實現。
訊息轉寄與多重繼承
回過頭來看第二和第三步,通過這兩個方法我們可以允許一個對象與其它對象建立關係,以處理某些未知訊息,而表面上看仍然是該對象在處理訊息。通過這種關係,我們可以類比“多重繼承”的某些特性,讓對象可以“繼承”其它對象的特性來處理一些事情。不過,這兩者間有一個重要的區別:多重繼承將不同的功能整合到一個對象中,它會讓對象變得過大,涉及的東西過多;而訊息轉寄將功能分解到獨立的小的對象中,並通過某種方式將這些對象串連起來,並做相應的訊息轉寄。
不過訊息轉寄雖然類似於繼承,但NSObject的一些方法還是能區分兩者。如respondsToSelector:和isKindOfClass:只能用於繼承體系,而不能用於轉寄鏈。便如果我們想讓這種訊息轉寄看起來像是繼承,則可以重寫這些方法,如以下代碼所示:
- (BOOL)respondsToSelector:(SEL)aSelector{ if ( [super respondsToSelector:aSelector]) return YES; 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. */ } return NO; }
小結
在此,我們已經瞭解了Runtime中訊息發送和轉寄的基本機制。這也是Runtime的強大之處,通過它,我們可以為程式增加很多動態行為,雖然我們在實際開發中很少直接使用這些機制(如直接調用objc_msgSend),但瞭解它們有助於我們更多地去瞭解底層的實現。其實在實際的編碼過程中,我們也可以靈活地使用這些機制,去實現一些特殊的功能,如hook操作等。
註:如有不對之處,還請指正,歡迎加QQ好友:1318202110(南峰子)
參考
- Objective-C Runtime Reference
- Objective-C Runtime Programming Guide
- Objective-C runtime之訊息(二)
- 深入淺出Cocoa之訊息
http://southpeak.github.io/blog/2014/11/03/objective-c-runtime-yun-xing-shi-zhi-san-:fang-fa-yu-xiao-xi-zhuan-fa/
Objective-C Runtime 運行時之三:方法與訊息