iOS 之 Method Swizzling

相信有一些开发经验的同学，都用到过 runtime 的 Method Swizzle，它的应用场景也有很多，其中比较典型的一个场景就是进行一些非侵入性的能力注入。 Method Swizzling 是一把双刃剑，使用得当可以让我们非常轻松地实现复杂的功能，而如果一旦误用，它也很可能会给我们的程序带来毁灭性的伤害。关于 Method Swizzling 这个东西，已经有很多高人写了详细的文章来介绍，我就不再班门弄斧，往深了说了。

本文旨在帮助不熟悉这项技术的人，开始在实际开发过程中，尝试使用它。
个人认为 Method Swizzling 是 Objective-C 动态性的最好诠释，深入地去学习并理解其特性，将有助于我们在业务量不断增大的同时还能保持代码的低耦合度，降低维护的工作量和难度。

实现原理

我们先来了解下 Objective-C 中方法 Method 的数据结构：

typedef struct method_t *Method;
struct method_t {
    SEL name;
    const char *types;
    IMP imp;

    struct SortBySELAddress :
        public std::binary_function<const method_t&,
                                    const method_t&, bool>
    {
        bool operator() (const method_t& lhs,
                         const method_t& rhs)
        { return lhs.name < rhs.name; }
    };
};

本质上，它就是 struct method_t 类型的指针，在结构体 method_t 中定义了三个成员变量和一个成员函数：

1. name 表示的是方法的名称，用于唯一标识某个方法，如 @selector(viewWillAppear:)
2. types 表示的是方法的返回值和参数类型
3. imp 是一个函数指针，指向方法的实现
4. SortBySELAddress 顾名思义，是一个根据 name 的地址对方法进行排序的函数

由此可见，Objective-C 中的方法名是不包括参数类型的，也就是说下面两个方法在 runtime 看来就是同一个方法：

- (void)viewWillAppear:(BOOL)animated;
- (void)viewWillAppear:(NSString *)string;

原则上，方法的名称 name 和方法的实现 imp 是一一对应的，而 Method Swizzling 的原理就是动态地改变它们的对应关系，以达到替换方法实现的目的。

示例

因为 Objective-C 的 runtime 机制， Method Swizzling 这个黑魔法解决了我们实际开发中诸多常规手段所无法解决的问题。我们首先看看常规的 Method Swizzling 是怎样用的, NSHipster 有一篇介绍基本用法的文章 Method Swizzling，我们就先以这篇文章中的示例开始说起吧：

#import <objc/runtime.h>

@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];

        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

简要说明一下以上代码的几个重点:

• 通过在 Category 的 + (void)load 方法中添加 Method Swizzling 的代码，在类初始加载时自动被调用，load 方法按照父类到子类，类自身到 Category 的顺序被调用；
• 在 dispatch_once 中执行 Method Swizzling 是一种防护措施，以保证代码块只会被执行一次并且线程安全，不过此处并不需要，因为当前 Category 中的 load 方法并不会被多次调用；
• 尝试先调用 class_addMethod 方法，以保证即便 originalSelector 只在父类中实现，也能达到 Method Swizzling 的目的；
• xxx_viewWillAppear: 方法中 [self xxx_viewWillAppear:animated]; 代码并不会造成死循环，因为 Method Swizzling 之后，调用 xxx_viewWillAppear: 实际执行的代码已经是原来 viewWillAppear 中的代码了。

其实以上的代码也可以简写为以下形式:

+ (void)load {
    Class class = [self class];    
    SEL originalSelector = @selector(viewWillAppear:);
    SEL swizzledSelector = @selector(xxx_viewWillAppear:);
    Method originalMethod = class_getInstanceMethod(class, originalSelector);
    Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
    if (!originalMethod || !swizzledMethod) {
        return;
    }
    
    IMP originalIMP = method_getImplementation(originalMethod);
    IMP swizzledIMP = method_getImplementation(swizzledMethod);
    const char *originalType = method_getTypeEncoding(originalMethod);
    const char *swizzledType = method_getTypeEncoding(swizzledMethod);
    
    // 这儿的先后顺序是有讲究的,如果先执行后一句,那么在执行完瞬间方法被调用容易引发死循环
    class_replaceMethod(class,swizzledSelector, originalIMP, originalType);
    class_replaceMethod(class,originalSelector, swizzledIMP, swizzledType);
}

这是因为 class_replaceMethod 方法其实能够覆盖到 class_addMethod 和 method_setImplementation 两种场景，对于第一个 class_replaceMethod 来说，如果 viewWillAppear: 实现在父类， 则执行 class_addMethod，否则就执行 method_setImplementation 将原方法的 IMP 指定新的代码块；而第二个 class_replaceMethod 完成的工作便只是将新方法的 IMP 指向原来的代码。

使用

说了这么多，原理一大堆，不知道该如何使用还是白搭，看百遍不如练一遍。举个应用场景的例子：

用过友盟统计的同学应该知道，要实现 页面的统计 功能，我们需要在每个页面的 viewController 中添加如下代码：

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    [MobClick beginLogPageView:@"PageOne"];//("PageOne"为页面名称，可自定义)
}

- (void)viewWillDisappear:(BOOL)animated {
    [super viewWillDisappear:animated];
    [MobClick endLogPageView:@"PageOne"];
}

要达到这个目的，我们有两种比较常规的实现方式：

• 直接修改每个页面的 viewController 代码，简单粗暴；
• 子类化 viewController ，并让我们的 viewController 都继承这些子类。

第 1 种方式的缺点是不言而喻的，这样做不仅会产生大量重复的代码，而且还很容易遗漏某些页面，非常难维护。

第 2 种方式稍微好一点，但是也同样需要我们子类化 UIViewController、UITableViewController 和 UITabBarController 等不同类型的 viewController。

也许你跟我一样陷入了思考，难道就没有一种简单优雅的解决方案吗？答案是肯定的，Method Swizzling 就是解决此类问题的最佳方式。

@interface UIViewController (UMAnalytics)

@end

@implementation UIViewController (UMAnalytics)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];

        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(um_viewWillAppear:);

        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);

        BOOL success = class_addMethod(class, originalSelector, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod));
        if (success) {
            class_replaceMethod(class, swizzledSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod));
        } else {
            method_exchangeImplementations(originalMethod, swizzledMethod);
        }
    });
}

#pragma mark - Method Swizzling
- (void)um_viewWillAppear:(BOOL)animated {
    [self um_viewWillAppear:animated];
    [MobClick beginLogPageView:NSStringFromClass([self class])];
}

@end

在上面的代码中有三个关键点需要引起我们的注意：

• 为什么是在 + (void)load 方法中实现 Method Swizzling 的逻辑，而不是其他的什么方法，比如 + (void)initialize 等；
• 为什么 Method Swizzling 的逻辑需要用 dispatch_once 来进行调度；
• 为什么需要调用 class_addMethod 方法，并且以它的结果为依据分别处理两种不同的情况。

第一：+ (void)load 和 + (void)initialize 是 Objective-C runtime 会自动调用的两个类方法。但是它们被调用的时机却是有差别的，+ (void)load 方法是在类被加载的时候调用的，而 + (void)initialize 方法是在类或它的子类收到第一条消息之前被调用的，这里所指的消息包括实例方法和类方法的调用。也就是说 + (void)initialize 方法是以懒加载的方式被调用的，如果程序一直没有给某个类或它的子类发送消息，那么这个类的 + (void)initialize 方法是永远不会被调用的。此外 + (void)load 方法还有一个非常重要的特性，那就是子类、父类和分类中的 + (void)load 方法的实现是被区别对待的。换句话说在 Objective-C 中 runtime 自动调用 + (void)load 方法时，分类中的 + (void)load 方法并不会对主类中的 + (void)load 方法造成覆盖。综上所述，+ (void)load 方法是实现 Method Swizzling 逻辑的最佳 “场所”。

**第二：**我们上面提到，+ (void)load 方法在类加载的时候会被 runtime 自动调用一次，但是它并没有限制程序员对 + (void)load 方法的手动调用，而我们所能够做的就是尽可能地保证程序能够在各种情况下正常运行。

**第三： **我们使用 Method Swizzling 的目的通常都是为了给程序增加功能，而不是完全地替换某个功能，所以我们一般都需要在自定义的实现中调用原始的实现。所以这里就会有两种情况需要我们分别进行处理：

第1种情况：主类本身有实现需要替换的方法，也就是 class_addMethod 方法返回 NO 。这种情况的处理比较简单，直接交换两个方法的实现就可以了。

- (void)viewWillAppear:(BOOL)animated {
    /// 先调用原始实现，由于主类本身有实现该方法，所以这里实际调用的是主类的实现
    [self um_viewWillAppear:animated];
    /// 我们增加的功能
    [MobClick beginLogPageView:NSStringFromClass([self class])];
}

- (void)um_viewWillAppear:(BOOL)animated {
    /// 主类的实现
}

第2种情况：主类本身没有实现需要替换的方法，而是继承了父类的实现，即 class_addMethod 方法返回 YES 。这时使用 class_getInstanceMethod 函数获取到的 originalSelector 指向的就是父类的方法，我们再通过执行：

class_replaceMethod(class, swizzledSelector);
method_getImplementation(originalMethod);
method_getTypeEncoding(originalMethod);

将父类的实现替换到我们自定义的 um_viewWillAppear 方法中。这样就达到了在 um_viewWillAppear 方法的实现中调用父类实现的目的。

- (void)viewWillAppear:(BOOL)animated {
    /// 先调用原始实现，由于主类本身并没有实现该方法，所以这里实际调用的是父类的实现
    [self um_viewWillAppear:animated];
    /// 我们增加的功能
    [MobClick beginLogPageView:NSStringFromClass([self class])];
}

- (void)um_viewWillAppear:(BOOL)animated {
    /// 父类的实现
}