理解Method Swizzling是學習runtime機制的一個很好的機會。在此不多做整理，僅翻譯由Mattt Thompson發表於nshipster的Method Swizzling一文。
Method Swizzling是改變一個selector的實際實現的技術。通過這一技術，我們可以在執行時通過修改類的分發表中selector對應的函式，來修改方法的實現。
例如，我們想跟蹤在程式中每一個view controller展示給使用者的次數：當然，我們可以在每個view controller的viewDidAppear中新增跟蹤程式碼；但是這太過麻煩，需要在每個view controller中寫重複的程式碼。建立一個子類可能是一種實現方式，但需要同時建立UIViewController, UITableViewController, UINavigationController及其它UIKit中view controller的子類，這同樣會產生許多重複的程式碼。
這種情況下，我們就可以使用Method Swizzling，如在程式碼所示：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
#import <objc/runtime.h> @implementation UIViewController (Tracking) + (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ Class class = [self class]; // When swizzling a class method, use the following: // Class class = object_getClass((id)self); SEL originalSelector = @selector(viewWillAppear:); SEL swizzledSelector = @selector(xxx_viewWillAppear:); Method originalMethod = class_getInstanceMethod(class, originalSelector); Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector); BOOL didAddMethod = class_addMethod(class, originalSelector, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod)); if (didAddMethod) { class_replaceMethod(class, swizzledSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod)); } else { method_exchangeImplementations(originalMethod, swizzledMethod); } }); } #pragma mark - Method Swizzling - (void)xxx_viewWillAppear:(BOOL)animated { [self xxx_viewWillAppear:animated]; NSLog(@"viewWillAppear: %@", self); } @end |
在這裡，我們通過method swizzling修改了UIViewController的@selector(viewWillAppear:)對應的函式指標，使其實現指向了我們自定義的xxx_viewWillAppear的實現。這樣，當UIViewController及其子類的物件呼叫viewWillAppear時，都會列印一條日誌資訊。
上面的例子很好地展示了使用method swizzling來一個類中注入一些我們新的操作。當然，還有許多場景可以使用method swizzling，在此不多舉例。在此我們說說使用method swizzling需要注意的一些問題：
Swizzling應該總是在+load中執行
在Objective-C中，執行時會自動呼叫每個類的兩個方法。+load會在類初始載入時呼叫，+initialize會在第一次呼叫類的類方法或例項方法之前被呼叫。這兩個方法是可選的，且只有在實現了它們時才會被呼叫。由於method swizzling會影響到類的全域性狀態，因此要儘量避免在併發處理中出現競爭的情況。+load能保證在類的初始化過程中被載入，並保證這種改變應用級別的行為的一致性。相比之下，+initialize在其執行時不提供這種保證—事實上，如果在應用中沒為給這個類傳送訊息，則它可能永遠不會被呼叫。
Swizzling應該總是在dispatch_once中執行
與上面相同，因為swizzling會改變全域性狀態，所以我們需要在執行時採取一些預防措施。原子性就是這樣一種措施，它確保程式碼只被執行一次，不管有多少個執行緒。GCD的dispatch_once可以確保這種行為，我們應該將其作為method swizzling的最佳實踐。
選擇器、方法與實現
在Objective-C中，選擇器(selector)、方法(method)和實現(implementation)是執行時中一個特殊點，雖然在一般情況下，這些術語更多的是用在訊息傳送的過程描述中。
以下是Objective-C Runtime Reference中的對這幾個術語一些描述：
- Selector(typedef struct objc_selector *SEL)：用於在執行時中表示一個方法的名稱。一個方法選擇器是一個C字串，它是在Objective-C執行時被註冊的。選擇器由編譯器生成，並且在類被載入時由執行時自動做對映操作。
- Method(typedef struct objc_method *Method)：在類定義中表示方法的型別
- Implementation(typedef id (*IMP)(id, SEL, …))：這是一個指標型別，指向方法實現函式的開始位置。這個函式使用為當前CPU架構實現的標準C呼叫規範。每一個引數是指向物件自身的指標(self)，第二個引數是方法選擇器。然後是方法的實際引數。
理解這幾個術語之間的關係最好的方式是：一個類維護一個執行時可接收的訊息分發表；分發表中的每個入口是一個方法(Method)，其中key是一個特定名稱，即選擇器(SEL)，其對應一個實現(IMP)，即指向底層C函式的指標。
為了swizzle一個方法，我們可以在分發表中將一個方法的現有的選擇器對映到不同的實現，而將該選擇器對應的原始實現關聯到一個新的選擇器中。
呼叫_cmd
我們回過頭來看看前面新的方法的實現程式碼：
|
1 2 3 4 |
- (void)xxx_viewWillAppear:(BOOL)animated { [self xxx_viewWillAppear:animated]; NSLog(@"viewWillAppear: %@", NSStringFromClass([self class])); } |
咋看上去是會導致無限迴圈的。但令人驚奇的是，並沒有出現這種情況。在swizzling的過程中，方法中的[self xxx_viewWillAppear:animated]已經被重新指定到UIViewController類的-viewWillAppear:中。在這種情況下，不會產生無限迴圈。不過如果我們呼叫的是[self viewWillAppear:animated]，則會產生無限迴圈，因為這個方法的實現在執行時已經被重新指定為xxx_viewWillAppear:了。
注意事項
Swizzling通常被稱作是一種黑魔法，容易產生不可預知的行為和無法預見的後果。雖然它不是最安全的，但如果遵從以下幾點預防措施的話，還是比較安全的：
- 總是呼叫方法的原始實現(除非有更好的理由不這麼做)：API提供了一個輸入與輸出約定，但其內部實現是一個黑盒。Swizzle一個方法而不呼叫原始實現可能會打破私有狀態底層操作，從而影響到程式的其它部分。
- 避免衝突：給自定義的分類方法加字首，從而使其與所依賴的程式碼庫不會存在命名衝突。
- 明白是怎麼回事：簡單地拷貝貼上swizzle程式碼而不理解它是如何工作的，不僅危險，而且會浪費學習Objective-C執行時的機會。閱讀Objective-C Runtime Reference和檢視<objc/runtime.h>標頭檔案以瞭解事件是如何發生的。
- 小心操作：無論我們對Foundation, UIKit或其它內建框架執行Swizzle操作抱有多大信心，需要知道在下一版本中許多事可能會不一樣。