Method Swizzling

Method Swizzling是Objective-C的一种黑科技，可以在在运行期，动态的用一份实现替换原有的方法实现。可以不修改源代码的情况下，改变类本身的功能。

Method Swizzling 的原理

下面直接摘抄了，别人写的非常好了。。。

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

typedef struct method_t *Method;  
struct method_t {
    SEL name;
    const charchar *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 objc_method 类型的指针，所以我们重点看下结构体 objc_method 的定义。在结构体 objc_method 中定义了三个成员变量和一个成员函数：
name：表示的是方法的名称，用于唯一标识某个方法，比如 @selector(viewWillAppear:)
types：表示的是方法的返回值和参数类型（详细信息可以查阅苹果官方文档中的 Type Encodings
imp：是一个函数指针，指向方法的实现
SortBySELAddress：顾名思义，是一个根据 name 的地址对方法进行排序的函数。


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

Method Swizzling 的实现

实现有比较固定的格式，下面给出一个模板

// UIViewController+DLMethodSwizzling.h
#import <UIKit/UIKit.h>
@interface UIViewController (DLMethodSwizzling)

@end

// UIViewController+DLMethodSwizzling.m
#import "UIViewController+DLMethodSwizzling.h"
#import <objc/runtime.h>

@implementation UIViewController (DLMethodSwizzling)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(dl_viewWillAppear:);

        [self dl_methodSwizzlingWithOriginalSelector:originalSelector bySwizzledSelector:swizzledSelector];
    });
}

// 此方法可以写到一个NSObject的category中方便Method Swizzling的时候调用
+ (void)dl_methodSwizzlingWithOriginalSelector:(SEL)originalSelector bySwizzledSelector:(SEL)swizzledSelector {
    Class class = [self class];

    Method originalMethod = class_getInstanceMethod(class, originalSelector);
    Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
    //先尝试給源SEL添加IMP，这里是为了避免源SEL没有实现IMP的情况
    BOOL didAddMethod = class_addMethod(class,originalSelector,
                                        method_getImplementation(swizzledMethod),
                                        method_getTypeEncoding(swizzledMethod));
    if (didAddMethod) {//添加成功：说明源SEL没有实现IMP，将源SEL的IMP替换到交换SEL的IMP
        class_replaceMethod(class,swizzledSelector,
                            method_getImplementation(originalMethod),
                            method_getTypeEncoding(originalMethod));
    } else {//添加失败：说明源SEL已经有IMP，直接将两个SEL的IMP交换即可
        method_exchangeImplementations(originalMethod, swizzledMethod);
    }
}

#pragma mark - Method Swizzling

- (void)dl_viewWillAppear:(BOOL)animated {
    [self dl_viewWillAppear:animated];
    NSLog(@"viewWillAppear: %@", self);
}

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

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

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

 第 2 个为什么：我们上面提到，+load 方法在类加载的时候会被 runtime 自动调用一次，但是它并没有限制程序员对 +load 方法的手动调用。什么？你说不会有程序员这么干？那可说不定，我还见过手动调用 viewDidLoad 方法的程序员，就是介么任性。而我们所能够做的就是尽可能地保证程序能够在各种情况下正常运行。

 第 3 个为什么：我们使用 Method Swizzling 的目的通常都是为了给程序增加功能，而不是完全地替换某个功能，所以我们一般都需要在自定义的实现中调用原始的实现。所以这里就会有两种情况需要我们分别进行处理：
 第 1 种情况：主类本身有实现需要替换的方法，也就是 class_addMethod 方法返回 NO 。这种情况的处理比较简单，直接交换两个方法的实现就可以了;
 第 2 种情况：主类本身没有实现需要替换的方法，而是继承了父类的实现，即 class_addMethod 方法返回 YES 。这时使用 class_getInstanceMethod 函数获取到的 originalSelector 指向的就是父类的方法，我们再通过执行 class_replaceMethod(class, swizzledSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod));  
 将父类的实现替换到我们自定义的 dl_viewWillAppear 方法中。这样就达到了在 dl_viewWillAppear 方法的实现中调用父类实现的目的。如果不做这一步的处理可能会crash，举个栗子：
 自定义类DLViewController，是UIViewController的子类。针对DLViewController做Method Swizzling，只做交换。
 

@implementation DLViewController (DLMethodSwizzling)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(dl_viewWillAppear:);

        Class class = [self class];
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
        method_exchangeImplementations(originalMethod, swizzledMethod);
    });  
}

- (void)dl_viewWillAppear:(BOOL)animated {
    [self dl_viewWillAppear:animated];
    NSLog(@"viewWillAppear: %@", self);
}

如果DLViewController中实现了viewWillAppear，万事大吉；但是如果没有实现，那么上面的代码就会将父类（UIViewController）的viewWillAppear给替换掉。相当于所有UIViewController派生的子类都会被动执行替换后的dl_viewWillAppear，然而他们并没有实现此方法，所以在展示页面的时候，crash就此产生。
unrecognized selector sent to instance

Method Swizzling的使用

1. 数据统计：比如统计按钮点击，统计页面打开和关闭
2. 全局更换UILabel的默认字体

另外：任何category（类别）一旦被编译（compiled），就会在app运行的期间生效。所以一定要给自己创建的category和内部的函数添加自己的前缀，从而避免和其他人命名相同。


文章大段摘抄此文，这个作者写的思路很清晰，不服不行：
http://blog.leichunfeng.com/blog/2015/06/14/objective-c-method-swizzling-best-practice/
当然还有mattt大神的文章：
http://nshipster.com/method-swizzling/
method_t那部分代码的出处：
https://opensource.apple.com/source/objc4/objc4-493.9/runtime/objc-runtime-new.h
category被编译后直接生效的出处：
http://stackoverflow.com/questions/7604813/objectivec-category-is-not-imported-but-still-running-code
另外一篇blog

http://blog.ximu.site/runtime-methodswizzling/

我只是知识的搬运工...