ios method swizzling - 快车库

背景

最近在整理项目逻辑的时候，发现一个问题：就是打点统计，经常和代码业务逻辑混在了一起，耦合性很强，并且经常容易出错。于是就在思考怎样对这一块进行优化。

其实，对这方面的讨论一直也比较多，比如继承基类，但是这样很容易使代码变得臃肿。另一个比较好的办法就是利用 method swizzling， hook 住需要打点的方法，将打点统计从业务逻辑中分离出来，而且额外工作量不大。最后就想从这方面去尝试，当然并没有自己造轮子，而是借用了 github 上的一个开源库，Aspects。这个库的代码量比较小，总共就一个类文件，使用起来也比较方便，比如你想统计某个 controller 的 viewwillappear 的调用次数，你只需要引入 Aspect.h 头文件，然后在合适的地方初始化如下代码即可。

 #pragma mark - addKvLogAspect
    - (void)addKvLogAspect {
        //想法tab打开
        [self aspect_hookSelector:@selector(viewWillAppear:) withOptions:AspectPositionAfter usingBlock:^(id<AspectInfo> aspectInfo) {
           //统计打点
            NSLog(@"");
        }error:NULL];
    }

oc的动态性及函数的调用

看到上面这段代码大家应该有所感觉了，没错，它基本上就是基于 method swizzling 实现的。本篇文章暂时并不打算对 aspects 的代码进行解析（以后，可能会写一篇这样的文字），在这里就简单的记录一下我个人对于 method swizzling 的理解。

ios 开发人员都知道, oc 是一门动态语言。这个动态性怎么理解呢，知乎上有网友这么总结过：

类和对象都是 id , 在给你一个 id 的前提下无法直观的知道这个对象是类对象还是类本身. 简单的可以简化成 runtime 管理的都是 id ( id 的本质其实是 objc_object , objc_class 头部其实就是 id, 也就是 isa ).
Class 在 objc 中是动态创建的, selector、method、 imp、protocol 等都是随后绑定上去的(即所谓的运行时绑定).
通过 runtime 能够查出当前运行时环境中所有的类, 每个类中的方法, 每个类消息的绑定, 每个类的实现的协议, 每个协议的定义, 每个类当前的消息缓存等一切你想知道的东西.
类的方法(消息)调用是间接的.

动态性比较常用的地方就是你可以在运行时动态的改变函数调用的执行，可以给对象动态的添加函数，甚至动态生成一个全新的类。method swizzling 就是利用这个动态性，在运行时改变了函数调用的指向，从而使函数最终调用到自己定义的方法中去，那么，这个过程是怎样实现的呢？

了解 method swizzling 之前有必要先了解一下 oc 函数的调用过程，这里先简单介绍几个概念：

1) oc 的类是由 Class 类型来表示的，定义如下：

typedef struct objc_class *Class;

它其实是一个指向 objc_class 的指针，结构体如下：

struct objc_class {

    Class isa  OBJC_ISA_AVAILABILITY;

#if !__OBJC2__

    Class super_class                       OBJC2_UNAVAILABLE;  // 父类

    const char *name                        OBJC2_UNAVAILABLE;  // 类名

    long version                            OBJC2_UNAVAILABLE;  // 类的版本信息，默认为0

    long info                               OBJC2_UNAVAILABLE;  // 类信息，供运行期使用的一些位标识

    long instance_size                      OBJC2_UNAVAILABLE;  // 该类的实例变量大小

    struct objc_ivar_list *ivars            OBJC2_UNAVAILABLE;  // 该类的成员变量链表

    struct objc_method_list **methodLists   OBJC2_UNAVAILABLE;  // 方法定义的链表

    struct objc_cache *cache                OBJC2_UNAVAILABLE;  // 方法缓存

    struct objc_protocol_list *protocols    OBJC2_UNAVAILABLE;  // 协议链表

#endif

} OBJC2_UNAVAILABLE;

2）类的实例也是一个结构体 objc_object

struct objc_object {

    Class isa  OBJC_ISA_AVAILABILITY;

};

typedef struct objc_object *id;

这里也就是我们说的 id 对象，oc 里面所有的对象都能用 id 表示。

这里的字段含义暂时不做过多的解释，有兴趣的同学可以去网上找找。这里介绍两个属性值：

isa:在 oc 中，类本身也被当成一个对象来处理。对于一个实例对象而言，isa 指针指向了这个对象的类（上面的 objc_class ），而类的 isa 指针指向了它的元类 ( metaclass 元类其实也是一种 objc_class ).，关于metaclass可以参考这里的分析。
methodLists:方法列表，记录了所有的方法。（这里只是实例方法，类方法需要通过isa去元类中寻找）

另外oc中一个方法的调用有如下几个关键的部分：

sel又叫选择器，它代表了一个方法的selector的指针。selector用于表达运行时的方法的名字。

SEL sel = @selector(method);

sel在一个类中是唯一的，而且是完全依赖方法名，也就是说下面两个函数

 - (void)setDimension:(NSInteger)dimension {
}
 - (void)setDimension:(float)dimension {
}

会提示Duplicate declaration错误，因为尽管它们有不同的参数类型，但是由于方法名完全相同会导致sel相同，违背了sel唯一性的原则，这也是oc语法和其他语法的不同。

IMP:一个函数指针，指向了方法实现的首地址
Method:它是类定义中表示方法的一个结构体，如下

struct objc_method {
    SEL method_name                                          OBJC2_UNAVAILABLE;
    char *method_types                                       OBJC2_UNAVAILABLE;
    IMP method_imp                                           OBJC2_UNAVAILABLE;
}

有了上面的铺垫，就能更好的说明函数调用的整个过程了，在 oc 中函数的调用形式是[ target * ],可以理解为[ receiver message ],也就是向 receiver 发送消息的过程。这个会被解析成如下形式 objc_msgSend(receiver,selector,arg1,...) ,也就是告诉 receiver ，我要发消息给你 selector 对应的方法， arg1 表示要传递给方法的参数。 receiver 收到这个通知后，会根据 objc_object 的(这里先以实例方法为例) isa 指针找到对象对应的 class 结构体，然后遍历 methodlist 找到 method ,最后通过 method 找到对应的 imp 指针,然后根据 imp 指针找到最终的函数实现。当然具体细节要比这复杂的多，(比如为了提高效率，会对 method 进行缓存等等)。

swizzling method 实现

基于上面的一些基本了解之后，我们设想一下，如果要在运行时动态的改变函数的调用，改怎么做呢？

上面我们说过，调用函数时，会动态的根据 sel 寻找响应的 imp 指针，这就给了我们启发，试想一下，如果我们改变了 sel 和 imp 的对应关系，那么是不是也就意味着我们改变了函数的调用关系？接下来我们可以用代码来验证。

还是以 hook uiviewcontroller 的 viewwillappear 为例,实现如下：

- (void)viewDidLoad {
    [super viewDidLoad];
    
    Class class = [self class];
    SEL originalSelector = @selector(viewWillAppear:);
    SEL swizzledSelector = @selector(swizzling_viewWillAppear:);
    
    //get method
    Method originalMethod = class_getInstanceMethod(class, originalSelector);
    Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
    
    /**
     * 这里其实是在加了一个保护，如果class_addMethod返回no，说明originalSelector已经有存在的实现了，这个时候，我们将
     originalMethod，swizzledMethod直接替换掉就号了，如果还没有对应的实现，那么直接添加进去，并更改原来swizzledSelector对应的实现
     */
    //exchange imp
    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);
    }
}

// 我们自己实现的方法，也就是和self的viewDidLoad方法进行交换的方法。
- (void)swizzling_viewWillAppear:(BOOL)animated {
    // 我们在这里加一个判断，将系统的UIViewController的对象剔除掉
    NSLog(@"swizzling_viewWillAppear");
    [self swizzling_viewWillAppear:animated];
}

- (void)viewWillAppear:(BOOL)animated {
    NSLog(@"viewWillAppear");
    [super viewWillAppear:animated];
}

运行结果如下

2016-06-30 13:56:31.186 Test[50266:6677359] swizzling_viewWillAppear
2016-06-30 13:56:31.187 Test[50266:6677359] viewWillAppear

和上面所说的函数的调用过程对比就会发现其实是一样的。本质上就是在运行时，就是在运行时更改 sel 对应的 imp 的指向而已。不过这里有几点需要说明：

这个swizzling只更改本对象的方法的调用，并不会影响起父类，子类的调用情况。也就是在子类controller调用viewWillAppear还是正常的调用viewWillAppear,但是，当调用[super viewWillAppear:animated]的时候，会调用到上面的 [self swizzling_viewwillAppear:animated].
细心的朋友或许会发现，上面swizzling_viewwillAppear的实现又调用了[self swizzling_viewwillAppear:animated] , 这样会不会形成循环调用了？其实不会，因为已经更改了@seletor(swizzling_viewwillAppear:)对应的imp，调用[self swizzling_viewwillAppear:animated]，实际上相当于调用了[self viewWillAppear:animated],并不会形成循环调用。