转：Cocoa Runtime系统知识整理
本文詳細整理了 Cocoa 的 Runtime 系統的知識，它使得 Objective-C 如虎添翼，具備了靈活的動態特性，使這門古老的語言煥發生機。主要內容如下：
引言
簡介
與Runtime交互
Runtime術語
消息
動態方法解析
消息轉發
健壯的實例變量(Non Fragile ivars)
Objective-C Associated Objects
總結
引言
曾經覺得Objc特別方便上手，面對著 Cocoa 中大量 API，只知道簡單的查文檔和調用。還記得初學 Objective-C 時把[receiver message]當成簡單的方法調用，而無視了“發送消息”這句話的深刻含義。于是[receiver message]會被編譯器轉化為：
objc_msgSend(receiver, selector)如果消息含有參數，則為：
objc_msgSend(receiver, selector, arg1, arg2, ...)如果消息的接收者能夠找到對應的selector，那么就相當于直接執行了接收者這個對象的特定方法；否則，消息要么被轉發，或是臨時向接收者動態添加這個selector對應的實現內容，要么就干脆玩完崩潰掉。
現在可以看出[receiver message]真的不是一個簡簡單單的方法調用。因為這只是在編譯階段確定了要向接收者發送message這條消息，而receive將要如何響應這條消息，那就要看運行時發生的情況來決定了。
Objective-C 的 Runtime 鑄就了它動態語言的特性，這些深層次的知識雖然平時寫代碼用的少一些，但是卻是每個 Objc 程序員需要了解的。
簡介
因為Objc是一門動態語言，所以它總是想辦法把一些決定工作從編譯連接推遲到運行時。也就是說只有編譯器是不夠的，還需要一個運行時系統 (runtime system) 來執行編譯后的代碼。這就是 Objective-C Runtime 系統存在的意義，它是整個Objc運行框架的一塊基石。
Runtime其實有兩個版本:“modern”和 “legacy”。我們現在用的 Objective-C 2.0 采用的是現行(Modern)版的Runtime系統，只能運行在 iOS 和 OS X 10.5 之后的64位程序中。而OS X較老的32位程序仍采用 Objective-C 1中的（早期）Legacy 版本的 Runtime 系統。這兩個版本最大的區別在于當你更改一個類的實例變量的布局時，在早期版本中你需要重新編譯它的子類，而現行版就不需要。
Runtime基本是用C和匯編寫的，可見蘋果為了動態系統的高效而作出的努力。你可以在這里下到蘋果維護的開源代碼。蘋果和GNU各自維護一個開源的runtime版本，這兩個版本之間都在努力的保持一致。
與Runtime交互
Objc 從三種不同的層級上與 Runtime 系統進行交互，分別是通過 Objective-C 源代碼，通過 Foundation 框架的NSObject類定義的方法，通過對 runtime 函數的直接調用。
Objective-C源代碼
大部分情況下你就只管寫你的Objc代碼就行，runtime 系統自動在幕后辛勤勞作著。
還記得引言中舉的例子吧，消息的執行會使用到一些編譯器為實現動態語言特性而創建的數據結構和函數，Objc中的類、方法和協議等在 runtime 中都由一些數據結構來定義，這些內容在后面會講到。（比如objc_msgSend函數及其參數列表中的id和SEL都是啥）
NSObject的方法
Cocoa 中大多數類都繼承于NSObject類，也就自然繼承了它的方法。最特殊的例外是NSProxy，它是個抽象超類，它實現了一些消息轉發有關的方法，可以通過繼承它來實現一個其他類的替身類或是虛擬出一個不存在的類，說白了就是領導把自己展現給大家風光無限，但是把活兒都交給幕后小弟去干。
有的NSObject中的方法起到了抽象接口的作用，比如description方法需要你重載它并為你定義的類提供描述內容。NSObject還有些方法能在運行時獲得類的信息，并檢查一些特性，比如class返回對象的類；isKindOfClass:和isMemberOfClass:則檢查對象是否在指定的類繼承體系中；respondsToSelector:檢查對象能否響應指定的消息；conformsToProtocol:檢查對象是否實現了指定協議類的方法；methodForSelector:則返回指定方法實現的地址。
Runtime的函數
Runtime 系統是一個由一系列函數和數據結構組成，具有公共接口的動態共享庫。頭文件存放于/usr/include/objc目錄下。許多函數允許你用純C代碼來重復實現 Objc 中同樣的功能。雖然有一些方法構成了NSObject類的基礎，但是你在寫 Objc 代碼時一般不會直接用到這些函數的，除非是寫一些 Objc 與其他語言的橋接或是底層的debug工作。在Objective-C Runtime Reference中有對 Runtime 函數的詳細文檔。
Runtime術語
還記得引言中的objc_msgSend:方法吧，它的真身是這樣的：
id objc_msgSend ( id self, SEL op, ... );
下面將會逐漸展開介紹一些術語，其實它們都對應著數據結構。
SEL
objc_msgSend函數第二個參數類型為SEL，它是selector在Objc中的表示類型（Swift中是Selector類）。selector是方法選擇器，可以理解為區分方法的 ID，而這個 ID 的數據結構是SEL:
typedef struct objc_selector *SEL;
其實它就是個映射到方法的C字符串，你可以用 Objc 編譯器命令@selector()或者 Runtime 系統的sel_registerName函數來獲得一個SEL類型的方法選擇器。
不同類中相同名字的方法所對應的方法選擇器是相同的，即使方法名字相同而變量類型不同也會導致它們具有相同的方法選擇器，于是 Objc 中方法命名有時會帶上參數類型(NSNumber一堆抽象工廠方法拿走不謝)，Cocoa 中有好多長長的方法哦。
id
objc_msgSend第一個參數類型為id，大家對它都不陌生，它是一個指向類實例的指針：
typedef struct objc_object *id;
那objc_object又是啥呢：
struct objc_object { Class isa; };
objc_object結構體包含一個isa指針，根據isa指針就可以順藤摸瓜找到對象所屬的類。
Class
之所以說isa是指針是因為Class其實是一個指向objc_class結構體的指針：
typedef struct objc_class *Class;
而objc_class就是我們摸到的那個瓜，里面的東西多著呢：
struct objc_class {Class isa OBJC_ISA_AVAILABILITY;#if !__OBJC2__Class super_class OBJC2_UNAVAILABLE;const char *name OBJC2_UNAVAILABLE;long version OBJC2_UNAVAILABLE;long info OBJC2_UNAVAILABLE;long instance_size OBJC2_UNAVAILABLE;struct objc_ivar_list *ivars OBJC2_UNAVAILABLE;struct objc_method_list **methodLists OBJC2_UNAVAILABLE;struct objc_cache *cache OBJC2_UNAVAILABLE;struct objc_protocol_list *protocols OBJC2_UNAVAILABLE; #endif} OBJC2_UNAVAILABLE;可以看到運行時一個類還關聯了它的超類指針，類名，成員變量，方法，緩存，還有附屬的協議。
其中objc_ivar_list和objc_method_list分別是成員變量列表和方法列表：
如果你C語言不是特別好，可以直接理解為objc_ivar_list結構體存儲著objc_ivar數組列表，而objc_ivar結構體存儲了類的單個成員變量的信息；同理objc_method_list結構體存儲著objc_method數組列表，而objc_method結構體存儲了類的某個方法的信息。
最后要提到的還有一個objc_cache，顧名思義它是緩存，它在objc_class的作用很重要，在后面會講到。
一個 ObjC 類同時也是一個對象，為了處理類和對象的關系，runtime 庫創建了一種叫做元類 (Meta Class) 的東西。當你發出一個類似[NSObject alloc]的消息時，你事實上是把這個消息發給了一個類對象 (Class Object) ，這個類對象必須是一個元類的實例，而這個元類同時也是一個根元類 (root meta class) 的實例。你會說 NSObject 的子類時，你的類就會指向 NSObject 做為其超類。但是所有的元類最終都指向根元類為其超類。所有的元類的方法列表都有能夠響應消息的類方法。所以當 [NSObject alloc] 這條消息發給類對象的時候，objc_msgSend()會去它的元類里面去查找能夠響應消息的方法，如果找到了，然后對這個類對象執行方法調用。
Method
Method是一種代表類中的某個方法的類型。
typedef struct objc_method *Method;
而objc_method在上面的方法列表中提到過，它存儲了方法名，方法類型和方法實現：
struct objc_method {SEL method_name OBJC2_UNAVAILABLE;char *method_types OBJC2_UNAVAILABLE;IMP method_imp OBJC2_UNAVAILABLE; }方法名類型為SEL，前面提到過相同名字的方法即使在不同類中定義，它們的方法選擇器也相同。
方法類型method_types是個char指針，其實存儲著方法的參數類型和返回值類型。
method_imp指向了方法的實現，本質上是一個函數指針，后面會詳細講到。
Ivar
Ivar是一種代表類中實例變量的類型。
typedef struct objc_ivar *Ivar;
而objc_ivar在上面的成員變量列表中也提到過：
struct objc_ivar {char *ivar_name OBJC2_UNAVAILABLE;char *ivar_type OBJC2_UNAVAILABLE;int ivar_offset OBJC2_UNAVAILABLE; #ifdef __LP64__int space OBJC2_UNAVAILABLE; #endif }PS:OBJC2_UNAVAILABLE之類的宏定義是蘋果在 Objc 中對系統運行版本進行約束的黑魔法，有興趣的可以查看源代碼。
IMP
IMP在objc.h中的定義是：
typedef id (*IMP)(id, SEL, ...);
它就是一個函數指針，這是由編譯器生成的。當你發起一個 ObjC 消息之后，最終它會執行的那段代碼，就是由這個函數指針指定的。而IMP這個函數指針就指向了這個方法的實現。既然得到了執行某個實例某個方法的入口，我們就可以繞開消息傳遞階段，直接執行方法，這在后面會提到。
你會發現IMP指向的方法與objc_msgSend函數類型相同，參數都包含id和SEL類型。每個方法名都對應一個SEL類型的方法選擇器，而每個實例對象中的SEL對應的方法實現肯定是唯一的，通過一組id和SEL參數就能確定唯一的方法實現地址；反之亦然。
Cache
在runtime.h中Cache的定義如下：
typedef struct objc_cache *Cache
還記得之前objcclass結構體中有一個struct objc_cache *cache吧，它到底是緩存啥的呢，先看看objccache的實現：
struct objc_cache {unsigned int mask /* total = mask + 1 */ OBJC2_UNAVAILABLE;unsigned int occupied OBJC2_UNAVAILABLE;Method buckets[1] OBJC2_UNAVAILABLE; };Cache為方法調用的性能進行優化，通俗地講，每當實例對象接收到一個消息時，它不會直接在isa指向的類的方法列表中遍歷查找能夠響應消息的方法，因為這樣效率太低了，而是優先在Cache中查找。Runtime 系統會把被調用的方法存到Cache中（理論上講一個方法如果被調用，那么它有可能今后還會被調用），下次查找的時候效率更高。這根計算機組成原理中學過的 CPU 繞過主存先訪問Cache的道理挺像，而我猜蘋果為提高Cache命中率應該也做了努力吧。
消息
前面做了這么多鋪墊，現在終于說到了消息了。Objc 中發送消息是用中括號（[]）把接收者和消息括起來，而直到運行時才會把消息與方法實現綁定。
objc_msgSend函數
在引言中已經對objc_msgSend進行了一點介紹，看起來像是objc_msgSend返回了數據，其實objc_msgSend從不返回數據而是你的方法被調用后返回了數據。下面詳細敘述下消息發送步驟：
檢測這個 selector 是不是要忽略的。比如 Mac OS X 開發，有了垃圾回收就不理會 retain,release 這些函數了。
檢測這個 target 是不是 nil 對象。ObjC 的特性是允許對一個 nil 對象執行任何一個方法不會 Crash，因為會被忽略掉。
如果上面兩個都過了，那就開始查找這個類的 IMP，先從 cache 里面找，完了找得到就跳到對應的函數去執行。
如果 cache 找不到就找一下方法分發表。
如果分發表找不到就到超類的分發表去找，一直找，直到找到NSObject類為止。
如果還找不到就要開始進入動態方法解析了，后面會提到。
PS:這里說的分發表其實就是Class中的方法列表，它將方法選擇器和方法實現地質聯系起來。
其實編譯器會根據情況在objc_msgSend, objc_msgSend_stret, objc_msgSendSuper, 或objc_msgSendSuper_stret四個方法中選擇一個來調用。如果消息是傳遞給超類，那么會調用名字帶有”Super”的函數；如果消息返回值是數據結構而不是簡單值時，那么會調用名字帶有”stret”的函數。排列組合正好四個方法。
方法中的隱藏參數
我們經常在方法中使用self關鍵字來引用實例本身，但從沒有想過為什么self就能取到調用當前方法的對象吧。其實self的內容是在方法運行時被偷偷的動態傳入的。
當objc_msgSend找到方法對應的實現時，它將直接調用該方法實現，并將消息中所有的參數都傳遞給方法實現,同時,它還將傳遞兩個隱藏的參數:
– 接收消息的對象（也就是self指向的內容） – 方法選擇器（_cmd指向的內容）
之所以說它們是隱藏的是因為在源代碼方法的定義中并沒有聲明這兩個參數。它們是在代碼被編譯時被插入實現中的。盡管這些參數沒有被明確聲明，在源代碼中我們仍然可以引用它們。在下面的例子中，self引用了接收者對象，而_cmd引用了方法本身的選擇器：
- strange {id target = getTheReceiver();SEL method = getTheMethod();if ( target == self || method == _cmd )return nil;return [target performSelector:method]; }在這兩個參數中，self 更有用。實際上,它是在方法實現中訪問消息接收者對象的實例變量的途徑。
而當方法中的super關鍵字接收到消息時，編譯器會創建一個objc_super結構體：
struct objc_super { id receiver; Class class; };
這個結構體指明了消息應該被傳遞給特定超類的定義。但receiver仍然是self本身，這點需要注意，因為當我們想通過[super class]獲取超類時，編譯器只是將指向self的id指針和class的SEL傳遞給了objc_msgSendSuper函數，因為只有在NSObject類找到class方法，然后class方法調用object_getClass()，接著調用objc_msgSend(objc_super->receiver, @selector(class))，傳入的第一個參數是指向self的id指針，與調用[self class]相同，所以我們得到的永遠都是self的類型。
獲取方法地址
在IMP那節提到過可以避開消息綁定而直接獲取方法的地址并調用方法。這種做法很少用，除非是需要持續大量重復調用某方法的極端情況，避開消息發送泛濫而直接調用該方法會更高效。
NSObject類中有個methodForSelector:實例方法，你可以用它來獲取某個方法選擇器對應的IMP，舉個栗子：
void (*setter)(id, SEL, BOOL); int i; setter = (void (*)(id, SEL, BOOL))[targetmethodForSelector:@selector(setFilled:)]; for ( i = 0 ; i < 1000 ; i++ )setter(targetList[i], @selector(setFilled:), YES);當方法被當做函數調用時，上節提到的兩個隱藏參數就需要我們明確給出了。上面的例子調用了1000次函數，你可以試試直接給target發送1000次setFilled:消息會花多久。
PS：methodForSelector:方法是由 Cocoa 的 Runtime 系統提供的，而不是 Objc 自身的特性。
動態方法解析
你可以動態地提供一個方法的實現。例如我們可以用@dynamic關鍵字在類的實現文件中修飾一個屬性：
@dynamic propertyName;
這表明我們會為這個屬性動態提供存取方法，也就是說編譯器不會再默認為我們生成setPropertyName:和propertyName:方法，而需要我們動態提供。我們可以通過分別重載resolveInstanceMethod:和resolveClassMethod:方法分別添加實例方法實現和類方法實現。因為當 Runtime 系統在Cache和方法分發表中（包括超類）找不到要執行的方法時，Runtime會調用resolveInstanceMethod:或resolveClassMethod:來給程序員一次動態添加方法實現的機會。我們需要用class_addMethod函數完成向特定類添加特定方法實現的操作：
void dynamicMethodIMP(id self, SEL _cmd) {// implementation .... } @implementation MyClass + (BOOL)resolveInstanceMethod:(SEL)aSEL {if (aSEL == @selector(resolveThisMethodDynamically)) {class_addMethod([self class], aSEL, (IMP) dynamicMethodIMP, "v@:");return YES;}return [super resolveInstanceMethod:aSEL]; } @end上面的例子為resolveThisMethodDynamically方法添加了實現內容，也就是dynamicMethodIMP方法中的代碼。其中 “v@:” 表示返回值和參數，這個符號涉及 Type Encoding
PS：動態方法解析會在消息轉發機制浸入前執行。如果 respondsToSelector: 或instancesRespondToSelector:方法被執行，動態方法解析器將會被首先給予一個提供該方法選擇器對應的IMP的機會。如果你想讓該方法選擇器被傳送到轉發機制，那么就讓resolveInstanceMethod:返回NO。
消息轉發
重定向
在消息轉發機制執行前，Runtime 系統會再給我們一次偷梁換柱的機會，即通過重載- (id)forwardingTargetForSelector:(SEL)aSelector方法替換消息的接受者為其他對象：
- (id)forwardingTargetForSelector:(SEL)aSelector {if(aSelector == @selector(mysteriousMethod:)){return alternateObject;}return [super forwardingTargetForSelector:aSelector]; }畢竟消息轉發要耗費更多時間，抓住這次機會將消息重定向給別人是個不錯的選擇，不過千萬別返回self，因為那樣會死循環。
轉發
當動態方法解析不作處理返回NO時，消息轉發機制會被觸發。在這時forwardInvocation:方法會被執行，我們可以重寫這個方法來定義我們的轉發邏輯：
- (void)forwardInvocation:(NSInvocation *)anInvocation {if ([someOtherObject respondsToSelector:[anInvocation selector]])[anInvocation invokeWithTarget:someOtherObject];else[super forwardInvocation:anInvocation]; }該消息的唯一參數是個NSInvocation類型的對象——該對象封裝了原始的消息和消息的參數。我們可以實現forwardInvocation:`方法來對不能處理的消息做一些默認的處理，也可以將消息轉發給其他對象來處理，而不拋出錯誤。
這里需要注意的是參數anInvocation是從哪的來的呢？其實在forwardInvocation:消息發送前，Runtime系統會向對象發送methodSignatureForSelector:消息，并取到返回的方法簽名用于生成NSInvocation對象。所以我們在重寫forwardInvocation:的同時也要重寫methodSignatureForSelector:方法，否則會拋異常。
當一個對象由于沒有相應的方法實現而無法響應某消息時，運行時系統將通過forwardInvocation:消息通知該對象。每個對象都從NSObject類中繼承了forwardInvocation:方法。然而，NSObject中的方法實現只是簡單地調用了doesNotRecognizeSelector:。通過實現我們自己的forwardInvocation:方法，我們可以在該方法實現中將消息轉發給其它對象。
forwardInvocation:方法就像一個不能識別的消息的分發中心，將這些消息轉發給不同接收對象。或者它也可以象一個運輸站將所有的消息都發送給同一個接收對象。它可以將一個消息翻譯成另外一個消息，或者簡單的”吃掉“某些消息，因此沒有響應也沒有錯誤。forwardInvocation:方法也可以對不同的消息提供同樣的響應，這一切都取決于方法的具體實現。該方法所提供是將不同的對象鏈接到消息鏈的能力。
注意： forwardInvocation:方法只有在消息接收對象中無法正常響應消息時才會被調用。 所以，如果我們希望一個對象將negotiate消息轉發給其它對象，則這個對象不能有negotiate方法。否則，forwardInvocation:將不可能會被調用。
轉發和多繼承
轉發和繼承相似，可以用于為Objc編程添加一些多繼承的效果。一個對象把消息轉發出去，就好似它把另一個對象中的方法借過來或是“繼承”過來一樣。
這使得不同繼承體系分支下的兩個類可以“繼承”對方的方法，
替代者對象(Surrogate Objects)
轉發不僅能模擬多繼承，也能使輕量級對象代表重量級對象。弱小的女人背后是強大的男人，畢竟女人遇到難題都把它們轉發給男人來做了。這里有一些適用案例，可以參看官方文檔。
轉發與繼承
盡管轉發很像繼承，但是NSObject類不會將兩者混淆。像respondsToSelector: 和 isKindOfClass:這類方法只會考慮繼承體系，不會考慮轉發鏈。
如果你為了某些意圖偏要“弄虛作假”讓別人以為Warrior繼承到了Diplomat的negotiate方法，你得重新實現 respondsToSelector: 和 isKindOfClass:來加入你的轉發算法：
除了respondsToSelector:和 isKindOfClass:之外，instancesRespondToSelector:中也應該寫一份轉發算法。如果使用了協議，conformsToProtocol:同樣也要加入到這一行列中。類似地，如果一個對象轉發它接受的任何遠程消息，它得給出一個methodSignatureForSelector:來返回準確的方法描述，這個方法會最終響應被轉發的消息。比如一個對象能給它的替代者對象轉發消息，它需要像下面這樣實現methodSignatureForSelector:：
- (NSMethodSignature*)methodSignatureForSelector:(SEL)selector {NSMethodSignature* signature = [super methodSignatureForSelector:selector];if (!signature) {signature = [surrogate methodSignatureForSelector:selector];}return signature; }健壯的實例變量(Non Fragile ivars)
在 Runtime 的現行版本中，最大的特點就是健壯的實例變量。當一個類被編譯時，實例變量的布局也就形成了，它表明訪問類的實例變量的位置。從對象頭部開始，實例變量依次根據自己所占空間而產生位移：
超類后面加上我們自己類的實例變量，看起來不錯。但試想如果那天蘋果更新了NSObject類，發布新版本的系統的話，那就悲劇了：
我們自定義的類被劃了兩道線，那是因為那塊區域跟超類重疊了。唯有蘋果將超類改為以前的布局才能拯救我們，但這樣也導致它們不能再拓展它們的框架了，因為成員變量布局被死死地固定了。在脆弱的實例變量(Fragile ivars) 環境下我們需要重新編譯繼承自 Apple 的類來恢復兼容性。那么在健壯的實例變量下回發生什么呢？
在健壯的實例變量下編譯器生成的實例變量布局跟以前一樣，但是當 runtime 系統檢測到與超類有部分重疊時它會調整你新添加的實例變量的位移，那樣你在子類中新添加的成員就被保護起來了。
需要注意的是在健壯的實例變量下，不要使用sizeof(SomeClass)，而是用class_getInstanceSize([SomeClass class])代替；也不要使用offsetof(SomeClass, SomeIvar)，而要用ivar_getOffset(class_getInstanceVariable([SomeClass class], "SomeIvar"))來代替。
Objective-C Associated Objects
在 OS X 10.6 之后，Runtime系統讓Objc支持向對象動態添加變量。涉及到的函數有以下三個：
void objcsetAssociatedObject ( id object, const void *key, id value, objcAssociationPolicy policy );
id objc_getAssociatedObject ( id object, const void *key );
void objc_removeAssociatedObjects ( id object );
這些方法以鍵值對的形式動態地向對象添加、獲取或刪除關聯值。其中關聯政策是一組枚舉常量：
enum { OBJC_ASSOCIATION_ASSIGN = 0, OBJC_ASSOCIATION_RETAIN_NONATOMIC = 1, OBJC_ASSOCIATION_COPY_NONATOMIC = 3, OBJC_ASSOCIATION_RETAIN = 01401, OBJC_ASSOCIATION_COPY = 01403 };這些常量對應著引用關聯值的政策，也就是 Objc 內存管理的引用計數機制。
總結
我們之所以讓自己的類繼承NSObject不僅僅因為蘋果幫我們完成了復雜的內存分配問題，更是因為這使得我們能夠用上 Runtime 系統帶來的便利。可能我們平時寫代碼時可能很少會考慮一句簡單的[receiver message]背后發生了什么，而只是當做方法或函數調用。深入理解 Runtime 系統的細節更有利于我們利用消息機制寫出功能更強大的代碼，比如 Method Swizzling 等。
原文出處： 楊蕭玉的博客
原文鏈接： http://yulingtianxia.com/blog/2014/11/05/objective-c-runtime/
總結
以上是生活随笔為你收集整理的转：Cocoa Runtime系统知识整理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 廖雪峰JS教程--条件判断
- 下一篇： rsync配置参考