理解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,如在代碼所示:
#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);
}
在這裏,我們通過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一個方法,我們可以在分發表中將一個方法的現有的選擇器映射到不同的實現,而將該選擇器對應的原始實現關聯到一個新的選擇器中。
注意事項
Swizzling通常被稱作是一種黑魔法,容易產生不可預知的行爲和無法預見的後果。雖然它不是最安全的,但如果遵從以下幾點預防措施的話,還是比較安全的:
總是調用方法的原始實現(除非有更好的理由不這麼做):API提供了一個輸入與輸出約定,但其內部實現是一個黑盒。Swizzle一個方法而不調用原始實現可能會打破私有狀態底層操作,從而影響到程序的其它部分。
避免衝突:給自定義的分類方法加前綴,從而使其與所依賴的代碼庫不會存在命名衝突。
明白是怎麼回事:簡單地拷貝粘貼swizzle代碼而不理解它是如何工作的,不僅危險,而且會浪費學習Objective-C運行時的機會。閱讀Objective-C Runtime Reference和查看<objc/runtime.h>頭文件以瞭解事件是如何發生的。
小心操作:無論我們對Foundation, UIKit或其它內建框架執行Swizzle操作抱有多大信心,需要知道在下一版本中許多事可能會不一樣。