OC运行时机制Runtime(四)：尝试使用黑魔法 Method Swizzling

Runtime最全总结

本系列详细讲解Runtime知识点，由于运行时的内容较多，所以将内容拆分成以下几个方面，可以自行选择想要查看的部分

• OC运行时机制Runtime(一)：从isa指针开始初步结识Runtime
• OC运行时机制Runtime(二)：探索Runtime的消息转发机制和分类Category
• OC运行时机制Runtime(三)：关联对象Associated Object和分类Category
• OC运行时机制Runtime(四)：尝试使用黑魔法 Method Swizzling

本文主要分析Runtime黑魔法——Method Swizzling，接前两篇文章详细分析一下一些细节内容。

Method Swizzling

通过前文分析Category，我们了解了OC在运行时可以动态添加方法，这种方式比起继承的方式要轻量级许多，但是这种方式更适合新增某个方法，如果我们希望在原有基础的方法上添加一定功能，那么继承和分类的方式还是不大适合，这里我们会使用一个新的方法Method Swizzling。

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

这是method结构体的内容，主要SEL类型的方法名称以及IMP类型的函数指针，也就是方法的具体实现。那么当我们修改IMP指针的指向时，就相当于修改了该方法的具体实现。

下面我们简单测试一下。

Person * person = [Person new];
Method method1 = class_getInstanceMethod([Person class], @selector(speakAction));
Method method2 = class_getInstanceMethod([Person class], @selector(runAction));

method_exchangeImplementations(method1, method2);
    
[person speakAction];
[person runAction];

首先我们获取两个方法，使用method_exchangeImplementations这个函数将两个方法的IMP指针的指向做交换，然后我们执行这两个方法，看一下方法内的打印结果。

2019-04-16 14:15:31.014450+0800 Run
2019-04-16 14:15:31.014705+0800 Speak

这里能看到runAction方法首先被log出来，说明了两个方法已经做到了交换，我们找到函数的具体实现来彻底印证这个猜想。

void method_exchangeImplementations(Method m1_gen, Method m2_gen)
{
    method_t *m1 = newmethod(m1_gen);
    method_t *m2 = newmethod(m2_gen);
    if (!m1  ||  !m2) return;

    rwlock_write(&runtimeLock);

    if (ignoreSelector(m1->name)  ||  ignoreSelector(m2->name)) {
        // Ignored methods stay ignored. Now they're both ignored.
        m1->imp = (IMP)&_objc_ignored_method;
        m2->imp = (IMP)&_objc_ignored_method;
        rwlock_unlock_write(&runtimeLock);
        return;
    }

    IMP m1_imp = m1->imp;
    m1->imp = m2->imp;
    m2->imp = m1_imp;

    if (vtable_containsSelector(m1->name)  ||  
        vtable_containsSelector(m2->name)) 
    {
        // Don't know the class - will be slow if vtables are affected
        // fixme build list of classes whose Methods are known externally?
        flushVtables(NULL);
    }

    // fixme catch NSObject changing to custom RR
    // cls->setCustomRR();

    // fixme update monomorphism if necessary

    rwlock_unlock_write(&runtimeLock);
}

忽略严格处理部分，可以看到m1的imp指针和m2的imp指针确实做到了交换，以此实现交换了方法的具体实现，下面用一个图来表示这个操作。

Method Swizzling具体实现

看得出Method Swizzling的原理并不很难理解，使用起来也很便利，我们来想一个简单的需求：项目中很多时候我们可能用到ImageView展示图片，如果图片展示不出我们不确定是否原因在于url字段问题，那我们可以在添加url方法加上一段log，判断字符串是否为空，demo中我们使用本地图片方式进行测试。

#import "UIImage+Detection.h"

@implementation UIImage (Detection)

+ (void)load {
    Method originalMethod = class_getClassMethod([UIImage class], @selector(imageNamed:));
    Method swappedMethod = class_getClassMethod([UIImage class], @selector(hy_imageNamed:));
    method_exchangeImplementations(originalMethod, swappedMethod);
}

+ (UIImage *)hy_imageNamed:(NSString *)nameString {
    if ([nameString isEqualToString:@""]) {
        NSLog(@"missing image name");
    }
    return [UIImage hy_imageNamed:nameString];
}
@end

我们为UIImage创建一个分类，创建一个 hy_imageNamed的方法，方法内对imageName字符串进行判断，如果字符串为空我们进行一个日志打印，load方法中我们把系统的imageNamed:方法与我们的方法进行交换，这样一来，外部调用imageNamed方法时，实际是调用了我们的hy_imageNamed:方法。
返回值虽然调用的是 hy_imageNamed 方法，但是由于有方法交换的原因所以这里是调用了原生 imageNamed 方法，并没有造成递归调用。

UIImage * image = [UIImage imageNamed:@""];

这样一来控制台会打印找不到图片的日志信息，满足了我们的简单需求，项目中我们可以自由发挥，不过也不能滥用，以防给后期代码维护造成困难。

总结

方法交换的实质就是通过交换IMP函数指针的指向，来交换方法的具体实现，我们可以将Method Swizzling这段代码写到任何一处，但是只有执行了这段代码之后才可以实现交换。

最后

Runtime相关还有很多知识点，例如kvo的原理，weak的实现等等，但是作者文笔有限，深层问题还在探索中，希望可以在源码角度解析而不是很浅层的分析，欢迎大家一起讨论，更欢迎大牛们给一些意见或建议，如果觉得本文对您有些作用，请在下方点个赞再走哈~