Objective-C Runtime ：Method Swizzling - method_exchangeImplementations

http://southpeak.github.io/blog/2014/11/06/objective-c-runtime-yun-xing-shi-zhi-si-:method-swizzling/

了解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);
}

@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中的對這幾個術語一些描述：

1. Selector(typedef struct objc_selector *SEL)：用于在運作時中表示一個方法的名稱。一個方法選擇器是一個C字元串，它是在Objective-C運作時被注冊的。選擇器由編譯器生成，并且在類被加載時由運作時自動做映射操作。
2. Method(typedef struct objc_method *Method)：在類定義中表示方法的類型
3. Implementation(typedef id (*IMP)(id, SEL, …))：這是一個指針類型，指向方法實作函數的開始位置。這個函數使用為目前CPU架構實作的标準C調用規範。每一個參數是指向對象自身的指針(self)，第二個參數是方法選擇器。然後是方法的實際參數。

了解這幾個術語之間的關系最好的方式是：一個類維護一個運作時可接收的消息分發表；分發表中的每個入口是一個方法(Method)，其中key是一個特定名稱，即選擇器(SEL)，其對應一個實作(IMP)，即指向底層C函數的指針。

為了swizzle一個方法，我們可以在分發表中将一個方法的現有的選擇器映射到不同的實作，而将該選擇器對應的原始實作關聯到一個新的選擇器中。

調用_cmd

我們回過頭來看看前面新的方法的實作代碼：

- (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通常被稱作是一種黑魔法，容易産生不可預知的行為和無法預見的後果。雖然它不是最安全的，但如果遵從以下幾點預防措施的話，還是比較安全的：

1. 總是調用方法的原始實作(除非有更好的理由不這麼做)：API提供了一個輸入與輸出約定，但其内部實作是一個黑盒。Swizzle一個方法而不調用原始實作可能會打破私有狀态底層操作，進而影響到程式的其它部分。
2. 避免沖突：給自定義的分類方法加字首，進而使其與所依賴的代碼庫不會存在命名沖突。
3. 明白是怎麼回事：簡單地拷貝粘貼swizzle代碼而不了解它是如何工作的，不僅危險，而且會浪費學習Objective-C運作時的機會。閱讀Objective-C Runtime Reference和檢視<objc/runtime.h>頭檔案以了解事件是如何發生的。
4. 小心操作：無論我們對Foundation, UIKit或其它内建架構執行Swizzle操作抱有多大信心，需要知道在下一版本中許多事可能會不一樣。