Method Swizzling是改變一個selector的實際實現(xiàn)的技術。通過這一技術屉栓，我們可以在運行時通過修改類的分發(fā)表中selector對應的函數(shù)妖泄，來修改方法的實現(xiàn)平挑。
例如骗灶，我們想跟蹤在程序中每一個view controller展示給用戶的次數(shù)：當然惨恭，我們可以在每個view controller的viewDidAppear中添加跟蹤代碼；但是這太過麻煩耙旦，需要在每個view controller中寫重復的代碼脱羡。創(chuàng)建一個子類可能是一種實現(xiàn)方式，但需要同時創(chuàng)建UIViewController, UITableViewController, UINavigationController及其它UIKit中view controller的子類母廷，這同樣會產(chǎn)生許多重復的代碼轻黑。
這種情況下，我們就可以使用Method Swizzling琴昆，如在代碼所示：
#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);
}
/**
解析:
dispatch_once這里不是“單例”氓鄙，是保證方法替換只執(zhí)行一次.
說明:
run:被替換方法eat:替換方法
class_addMethod:如果發(fā)現(xiàn)方法已經(jīng)存在，會失敗返回业舍，也可以用來做檢查用,我們這里是為了避免源方法沒有實現(xiàn)的情況;如果方法沒有存在,我們則先嘗試添加被替換的方法的實現(xiàn)
1.如果返回成功:則說明被替換方法沒有存在.也就是被替換的方法沒有被實現(xiàn),我們需要先把這個方法實現(xiàn),然后再執(zhí)行我們想要的效果,用我們自定義的方法去替換被替換的方法. 這里使用到的是class_replaceMethod這個方法. class_replaceMethod本身會嘗試調(diào)用class_addMethod和method_setImplementation抖拦，所以直接調(diào)用class_replaceMethod就可以了)
2.如果返回失敗:則說明被替換方法已經(jīng)存在.直接將兩個方法的實現(xiàn)交換即
另外:
我們可以利用 method_exchangeImplementations 來交換2個方法中的IMP
我們可以利用 class_replaceMethod 來修改類
我們可以利用 method_setImplementation 來直接設置某個方法的IMP
*/
@end
在這里，我們通過method swizzling修改了UIViewController的@selector(viewWillAppear:)對應的函數(shù)指針舷暮，使其實現(xiàn)指向了我們自定義的xxx_viewWillAppear的實現(xiàn)态罪。這樣，當UIViewController及其子類的對象調(diào)用viewWillAppear時下面，都會打印一條日志信息复颈。
上面的例子很好地展示了使用method swizzling來一個類中注入一些我們新的操作。當然沥割，還有許多場景可以使用method swizzling耗啦，在此不多舉例。在此我們說說使用method swizzling需要注意的一些問題：
Swizzling應該總是在+load中執(zhí)行
在Objective-C中机杜，運行時會自動調(diào)用每個類的兩個方法帜讲。+load會在類初始加載時調(diào)用，+initialize會在第一次調(diào)用類的類方法或?qū)嵗椒ㄖ氨徽{(diào)用椒拗。這兩個方法是可選的似将，且只有在實現(xiàn)了它們時才會被調(diào)用。由于method swizzling會影響到類的全局狀態(tài)蚀苛，因此要盡量避免在并發(fā)處理中出現(xiàn)競爭的情況在验。+load能保證在類的初始化過程中被加載，并保證這種改變應用級別的行為的一致性枉阵。相比之下译红，+initialize在其執(zhí)行時不提供這種保證–事實上，如果在應用中沒為給這個類發(fā)送消息兴溜，則它可能永遠不會被調(diào)用侦厚。
Swizzling應該總是在dispatch_once中執(zhí)行
與上面相同，因為swizzling會改變?nèi)譅顟B(tài)拙徽，所以我們需要在運行時采取一些預防措施刨沦。原子性就是這樣一種措施，它確保代碼只被執(zhí)行一次膘怕，不管有多少個線程想诅。GCD的dispatch_once可以確保這種行為，我們應該將其作為method swizzling的最佳實踐岛心。
選擇器来破、方法與實現(xiàn)
在Objective-C中，選擇器(selector)忘古、方法(method)和實現(xiàn)(implementation)是運行時中一個特殊點徘禁，雖然在一般情況下，這些術語更多的是用在消息發(fā)送的過程描述中髓堪。
以下是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, ...))：這是一個指針類型争群，指向方法實現(xiàn)函數(shù)的開始位置回怜。這個函數(shù)使用為當前CPU架構實現(xiàn)的標準C調(diào)用規(guī)范。每一個參數(shù)是指向?qū)ο笞陨淼闹羔?self)换薄，第二個參數(shù)是方法選擇器玉雾。然后是方法的實際參數(shù)。
理解這幾個術語之間的關系最好的方式是：一個類維護一個運行時可接收的消息分發(fā)表专控；分發(fā)表中的每個入口是一個方法(Method)抹凳，其中key是一個特定名稱，即選擇器(SEL)伦腐，其對應一個實現(xiàn)(IMP)赢底，即指向底層C函數(shù)的指針。
為了swizzle一個方法柏蘑，我們可以在分發(fā)表中將一個方法的現(xiàn)有的選擇器映射到不同的實現(xiàn)幸冻，而將該選擇器對應的原始實現(xiàn)關聯(lián)到一個新的選擇器中。
調(diào)用
我們回過頭來看看前面新的方法的實現(xiàn)代碼：
(void)xxx_viewWillAppear:(BOOL)animated {
[self xxx_viewWillAppear:animated];
NSLog(@"viewWillAppear: %@", NSStringFromClass([self class]));
}
咋看上去是會導致無限循環(huán)的咳焚。但令人驚奇的是洽损，并沒有出現(xiàn)這種情況。在swizzling的過程中革半，方法中的[self xxx_viewWillAppear:animated]已經(jīng)被重新指定到UIViewController類的-viewWillAppear:中碑定。在這種情況下流码，不會產(chǎn)生無限循環(huán)。不過如果我們調(diào)用的是[self viewWillAppear:animated]延刘，則會產(chǎn)生無限循環(huán)漫试，因為這個方法的實現(xiàn)在運行時已經(jīng)被重新指定為xxx_viewWillAppear:了。
注意事項
Swizzling通常被稱作是一種黑魔法碘赖，容易產(chǎn)生不可預知的行為和無法預見的后果驾荣。雖然它不是最安全的，但如果遵從以下幾點預防措施的話普泡，還是比較安全的：
- 總是調(diào)用方法的原始實現(xiàn)(除非有更好的理由不這么做)：API提供了一個輸入與輸出約定播掷，但其內(nèi)部實現(xiàn)是一個黑盒。Swizzle一個方法而不調(diào)用原始實現(xiàn)可能會打破私有狀態(tài)底層操作撼班，從而影響到程序的其它部分歧匈。
- 避免沖突：給自定義的分類方法加前綴，從而使其與所依賴的代碼庫不會存在命名沖突权烧。
- 明白是怎么回事：簡單地拷貝粘貼swizzle代碼而不理解它是如何工作的眯亦，不僅危險，而且會浪費學習Objective-C運行時的機會般码。閱讀
Objective-C Runtime Reference和查看<objc/runtime.h>頭文件以了解事件是如何發(fā)生的妻率。 - 小心操作：無論我們對Foundation, UIKit或其它內(nèi)建框架執(zhí)行Swizzle操作抱有多大信心，需要知道在下一版本中許多事可能會不一樣板祝。
