大家也可以訪問我的個人博客喲！
- Method Swizzling說明
① 原理- 使用方式
① Swizzling應該放在+load中執行
② Swizzling應該放在dispatch_once中執行<br />- 注意事項
Method Swizzling說明
最開始從事iOS開發的時候，曾經被問及過“黑魔法”。當時一臉( ⊙ o ⊙ )這樣的表情，內心巨大的波動著：我的天吶！黑魔法！這是個什么東西！<br />
隨著學習的不斷深入，漸漸了解到Runtime中的Method Swizzling通常被稱作是一種黑魔法。Method Swizzling翻譯過來大概是方法混合，通過這一技術，我們可以在運行時通過修改類的分發表中selector對應的函數，來修改方法的實現。
原理
在OC中調用一個方法，其實是向一個對象發送一個消息。每一個類都有一個方法列表，存儲著selector的名字和方法實現的映射關系。利用OC的動態特性，可以在運行時偷換selector的方法實現。
通過 method_exchangeImplementations 可以交換兩個方法的IMP；<br />
通過 method_setImplementation 可以直接設置某個方法的IMP；<br />
如下圖所示：
例子
先看一個簡單的小例子，在VC中的viewDidLoad中寫入如下代碼：
/**
* 獲取對象方法信息 Method class_getInstanceMethod(Class cls, SEL name)
*
* @param cls 類
* @param aMethod 對象方法
*
* @return 對象方法信息 - Method類型
*/
Method methodA = class_getInstanceMethod([self class], @selector(aMethod));
Method methodB = class_getInstanceMethod([self class], @selector(bMethod));
// 交換兩個方法的實現
method_exchangeImplementations(methodA, methodB);
// 添加一個按鈕
UIButton *btn = [UIButton buttonWithType:UIButtonTypeCustom];
btn.frame = CGRectMake(70, 100, 170, 30);
[btn setTitle:@"點擊觸發A方法" forState:UIControlStateNormal];
[btn addTarget:self action:@selector(aMethod) forControlEvents:UIControlEventTouchUpInside];
[btn setBackgroundColor:[UIColor purpleColor]];
[self.view addSubview:btn];
并在VC中添加方法 aMethod 和 bMethod。
- (void)aMethod{
NSLog(@"a方法");
}
- (void)bMethod{
NSLog(@"b方法");
}
我們給按鈕添加一個點擊方法，觸發的是aMethod，理論上控制臺應該打印的是 “a方法”。但是我們在上面已經偷偷的將 aMethod 的實現和 bMethod 的實現。所以控制臺打印出的是 “b方法”。效果如下圖：
使用方式
Swizzling應該放在+load中執行
在Objective-C中，運行時會自動調用每個類的兩個方法。+load會在類初始加載時調用，+initialize會在第一次調用類的類方法或實例方法之前被調用。這兩個方法是可選的，且只有在實現了它們時才會被調用。由于method swizzling會影響到類的全局狀態，因此要盡量避免在并發處理中出現競爭的情況。+load能保證在類的初始化過程中被加載，并保證這種改變應用級別的行為的一致性。相比之下，+initialize在其執行時不提供這種保證–事實上，如果在應用中沒為給這個類發送消息，則它可能永遠不會被調用。
Swizzling應該放在dispatch_once中執行
與上面相同，因為swizzling會改變全局狀態，所以我們需要在運行時采取一些預防措施。原子性就是這樣一種措施，它確保代碼只被執行一次，不管有多少個線程。GCD的dispatch_once可以確保這種行為，我們應該將其作為method swizzling的最佳實踐。
例子
我們想跟蹤在程序中每一個view controller展示給用戶的次數：當然，我們可以在每個view controller的viewDidAppear中添加跟蹤代碼；但是這太過麻煩，需要在每個view controller中寫重復的代碼。創建一個子類可能是一種實現方式，但需要同時創建UIViewController, UITableViewController, UINavigationController及其它UIKit中view controller的子類，這同樣會產生許多重復的代碼。這種情況下，我們就可以使用Method Swizzling，如在代碼所示：
#import <objc/runtime.h>
@implementation UIViewController (MethodSwizzling)
+ (void)load{
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
Class class = [self class];
SEL originalSelector = @selector(viewWillAppear:);
SEL swizzleSelector = @selector(lt_viewWillAppear:);
Method originalMethod = class_getInstanceMethod(class, originalSelector);
Method swizzleMethod = class_getInstanceMethod(class, swizzleSelector);
BOOL addMethod = class_addMethod(class, originalSelector, method_getImplementation(swizzleMethod), method_getTypeEncoding(swizzleMethod));
if (addMethod) {
class_replaceMethod(class, swizzleSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod));
} else {
method_exchangeImplementations(originalMethod, swizzleMethod);
}
});
}
- (void)lt_viewWillAppear:(BOOL)animated{
[self lt_viewWillAppear:animated];
NSLog(@"viewWillAppear: %@", self);
}
在這里，我們通過method swizzling修改了UIViewController的@selector(viewWillAppear:)對應的函數指針，使其實現指向了我們自定義的lt_viewWillAppear的實現。這樣，當UIViewController及其子類的對象調用viewWillAppear時，都會打印一條日志信息。
上面的例子很好地展示了使用method swizzling來一個類中注入一些我們新的操作。當然，還有許多場景可以使用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
我們回過頭來看看前面新的方法的實現代碼：
- (void)lt_viewWillAppear:(BOOL)animated{
[self lt_viewWillAppear:animated];
NSLog(@"viewWillAppear: %@", self);
}
咋看上去是會導致無限循環的。但令人驚奇的是，并沒有出現這種情況。在swizzling的過程中，方法中的[self lt_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操作抱有多大信心，需要知道在下一版本中許多事可能會不一樣。
本文是基于南峰子的技術博客文章的整理，原文鏈接地址：?http://southpeak.github.io/2014/11/06/objective-c-runtime-4/
感謝原作者的貢獻！
