OC方法交换swizzle详细介绍——不再有盲点

原文链接：//www.greatytc.com/p/e95ca2e14731

如果对方法交换已经比较熟悉，可以跳过整体介绍，直接看常见问题部分

整体介绍

方法交换是runtime的重要体现，也是"消息语言"的核心。OC给开发者开放了很多接口，让开发者也能全程参与这一过程。

原理

oc的方法调用，比如[self test]会转换为objc_msgSend(self,@selfector(test))。objc_msgsend会以@selector(test)作为标识，在方法接收者(self)所属类(以及所属类继承层次)方法列表找到Method，然后拿到imp函数入口地址，完成方法调用。

typedef struct objc_method *Method;

// oc2.0已废弃，可以作为参考
struct objc_method {
    SEL _Nonnull method_name;
    char * _Nullable method_types;
    IMP _Nonnull method_imp;
}

基于以上铺垫，那么有两种办法可以完成交换：

  • 一种是改变@selfector(test)，不太现实，因为我们一般都是hook系统方法，我们拿不到系统源码，不能修改。即便是我们自己代码拿到源码修改那也是编译期的事情，并非运行时（跑题了。。。）
  • 所以我们一般修改imp函数指针。改变sel与imp的映射关系；
系统为我们提供的接口

typedef struct objc_method *Method;Method是一个不透明指针，我们不能够通过结构体指针的方式来访问它的成员，只能通过暴露的接口来操作。

接口如下，很简单，一目了然：

#import <objc/runtime.h>

/// 根据cls和sel获取实例Method
Method _Nonnull * _Nullable class_getInstanceMethod(Class _Nullable cls, SEL _Nonnull name);

/// 给cls新增方法，需要提供结构体的三个成员，如果已经存在则返回NO，不存在则新增并返回成功
BOOL class_addMethod(Class _Nullable cls, SEL _Nonnull name, IMP _Nonnull imp, 
                const char * _Nullable types)

/// method->imp
IMP _Nonnull method_getImplementation(Method _Nonnull m);

/// 替换
IMP _Nullable class_replaceMethod(Class _Nullable cls, SEL _Nonnull name, IMP _Nonnull imp, 
                    const char * _Nullable types)

/// 跟定两个method，交换它们的imp：这个好像就是我们想要的
method_exchangeImplementations(Method _Nonnull m1, Method _Nonnull m2);
简单使用

假设交换UIViewController的viewDidLoad方法

/// UIViewController 某个分类

+ (void)swizzleInstanceMethod:(Class)target original:(SEL)originalSelector swizzled:(SEL)swizzledSelector {
    Method originMethod = class_getInstanceMethod(target, originalSelector);
    Method swizzledMethod = class_getInstanceMethod(target, swizzledSelector);
    method_exchangeImplementations(originMethod, swizzledMethod);
}

+ (void)load {
    [self swizzleInstanceMethod:[UIViewController class] original:@selector(viewDidLoad) swizzled:@selector(swizzle_viewDidLoad)];
}
/// hook
- (void)swizzle_viewDidLoad {
    [self swizzle_viewDidLoad];
}

交换本身简单：原理简单，接口方法也少而且好理解，因为结构体定义也就三个成员变量，也难不到哪里去！

但是，具体到使用场景，叠加上其它外部的不稳定因素，想要稳定的写出通用或者半通用交换方法，上面的"简单使用"远远不够的。

下面就详细介绍下几种常见坑，也是为啥网上已有很多文章介绍方法交换，为什么还要再写一篇的原因：不再有盲点

常见问题一、被多次调用（多次交换）

"简单使用"中的代码用于hook viewDidload一般是没问题的，+load 方法一般也执行一次。但是如果一些程序员写法不规范时，会造成多次调用。

比如写了UIViewController的子类，在子类里面实现+load方法，又习惯性的调用了super方法

+ (void)load {
    // 这里会引起UIViewController父类load方法多次调用
    [super load];
}

又或者更不规范的调用，直接调用load，类似[UIViewController load]

为了没盲点，我们扩展下load的调用：
  • load方法的调用时机在dyld映射image时期，这也符合逻辑，加载完调用load。
  • 类与类之间的调用顺序与编译顺序有关，先编译的优先调用，继承层次上的调用顺序则是先父类再子类；
  • 类与分类的调用顺序是，优先调用类，然后是分类；
  • 分类之间的顺序，与编译顺序有关，优先编译的先调用；
  • 系统的调用是直接拿到imp调用，没有走消息机制；

手动的[super load]或者[UIViewController load]则走的是消息机制，分类的会优先调用，如果你运气好，另外一个程序员也实现了UIViewController的分类，且实现+load方法，还后编译，则你的load方法也只执行一次；（分类同名方法后编译的会“覆盖”之前的）

为了保险起见，还是：

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        [self swizzleInstanceMethod:[UIViewController class] original:@selector(viewDidLoad) swizzled:@selector(swizzle_viewDidLoad)];
    });
}
继续扩展：多次调用的副作用是什么呢？
  • 根据原理，如果是偶数次

结果就是方法交换不生效，但是有遗留问题，这时手动调用

- (void)swizzle_viewDidLoad {
    [self swizzle_viewDidLoad];
}

会引起死循环。

其实，方法交换后，任何时候都不要尝试手动调用，特别是交换的系统方法。实际开发中，也没人会手动调用，这里我们只讨论这种场景的技术及后果，帮助理解

  • 奇数次调用

奇数次之后一切正常。但是，奇数次之前，它会先经历偶数次。

比如，第一次交换，正常，第二次交换，那么相当于没有交换，如果你手动调用了swizzle_viewDidLoad，很明显死循环了，然后你又在其它线程进行第三次交换，又不死循环了。哈哈，好玩，但你要保重，别玩失火了玩到线上了！！！

这种情况还是有可能发生的，比如交换没有放在load方法，又没有dispatch_once，而是自己写了个类似start的开始方法，被自己或者他人误调用。

最后：为了防止多次交换始终加上dispatch_once，除非你清楚你自己在干啥。

再次扩展：常见的多次交换

这里说的多次交换，和上面说的不一样，交换方法不一样，比如我们开发中经常遇到的。

我们自己交换了viewDidLoad，然后第三方库也交换了viewDidLoad，那么交换前(箭头代表映射关系)：

sysSel -> sysImp
ourSel -> ourImp
thirdSel -> thirdImp

第一步，我们与系统交换：

sysSel -> ourImp
ourSel -> sysImp
thirdSel -> thirdImp

第二步，第三方与系统交换：

sysSel -> thirdImp
ourSel -> sysImp
thirdSel -> ourImp

假设，push了一个VC，首先是系统的sysSel，那么调用顺序：

thirdImp、ourImp、sysImp

没毛病！

多次交换这种场景是真实存在的，比如我们监控viewDidload/viewWillappear，在程序退到后台时，想停止监控，则再进行一次(偶数)交换也是一种取消监控的方式。当再次进入前台时，则再次(奇数)交换，实现监控。（通过标志位实现用的更多，更简单）

问题二、被交换的类没有实现该方法

我们还是在分类里面添加方法来交换

情况一：父类实现了被交换方法

我们本意交换的是子类方法，但是子类没有实现，父类实现了class_getInstanceMethod(target, swizzledSelector);执行的结果返回父类的Method，那么后续交换就相当于和父类的方法实现了交换。

一般情况下也不会出问题，可是埋下了一系列隐患。如果其它程序员也继承了这个父类。举例代码如下

/// 父类
@interface SuperClassTest : NSObject
- (void)printObj;
@end
@implementation SuperClassTest
- (void)printObj {
    NSLog(@"SuperClassTest");
}
@end

/// 子类1
@interface SubclassTest1 : SuperClassTest
@end
@implementation SubclassTest1
- (void)swiprintObj {
    NSLog(@"printObj");
}
@end

/// 子类1 分类实现交换
@interface SubclassTest1(swiTest)
@end
@implementation SubclassTest1(swiTest)
+ (void)swizzleInstanceMethod:(Class)target original:(SEL)originalSelector swizzled:(SEL)swizzledSelector {
    Method originMethod = class_getInstanceMethod(target, originalSelector);
    Method swizzledMethod = class_getInstanceMethod(target, swizzledSelector);
    method_exchangeImplementations(originMethod, swizzledMethod);
}
+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        [self swizzleInstanceMethod:[SubclassTest1 class] original:@selector(printObj) swizzled:@selector(swiprintObj)];
    });
}

- (void)swiprintObj {
    NSLog(@"swi1:%@",self);
    [self swiprintObj];
}
@end

/// 子类2
@interface SubclassTest2 : SuperClassTest
@end
@implementation SubclassTest2
/// 有没有重写此方法，会呈现不同的结果
//- (void)printObj {
//    // 有没有调用super  也是不同的结果
//    [super printObj];
//    NSLog(@"printObj");
//}
@end

示例代码，实现了printObj与 swiprintObj的交换。

  • 问题1：父类的实例对象调用selector(printObj)，也会造成imp(swiprintObj)优先调用，但是父类并没有实现swiprintObj，因此会造成找不到方法崩溃；
  • 问题2：假设sub2(子类2)没有实现printObj，但它的实例对象也调用了selector(printObj)，正常应该是能够调用父类的imp(printObj)方法，但是由于被交换，会尝试调用[sub2 swiprintObj]，因为 swiprintObj的实现里面有[self swiprintObj]，这里的self是sub2，sub2和super都没有实现swiprintObj的，所以方法找不到崩溃。
  • 问题3：sub2子类重写了printObj，一切正常，sub2实例对象调用正常，但是如果在sub2的imp(printObj)里面调用super方法还是会崩溃，原因是selector(printObj)会尝试调用imp(swiprintObj)，但是sub2 和 super都没有实现该方法

那么如何避免这种情况呢？

使用class_addMethod方法来避免。再次优化后的结果：

+ (void)swizzleInstanceMethod:(Class)target original:(SEL)originalSelector swizzled:(SEL)swizzledSelector {
    Method originMethod = class_getInstanceMethod(target, originalSelector);
    Method swizzledMethod = class_getInstanceMethod(target, swizzledSelector);
    if (class_addMethod(target, originalSelector, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod))) {
        class_replaceMethod(target, swizzledSelector, method_getImplementation(originMethod), method_getTypeEncoding(originMethod));
    }
    else {
        method_exchangeImplementations(originMethod, swizzledMethod);
    }
}

分步骤详细解析如下：

  • class_addMethod 执行前

superSel -> superImp
sub1SwiSel -> sub1SwiImp

  • class_addMethod 执行后，给子类增加了sel，但是对应的imp实现还是swizzledMethod的imp即交换方法的imp

superSel -> superImp
sub1Sel -> sub1SwiImp
sub1SwiSel -> sub1SwiImp

被交换的方法sub1Sel已经指向了交换方法的imp实现，下一步将交换方法的sel 指向被交换方法的imp即可。被交换方法不是没有实现吗？？？ 有的，OC继承关系，父类的实现就是它的实现superImp

  • class_replaceMethod，将sub1SwiSel的实现替换为superImp

superSel -> superImp
sub1Sel -> sub1SwiImp
sub1SwiSel -> superImp

系统在给对象发送sel消息时，执行sub1SwiImp，sub1SwiImp里面发送sub1SwiSel，执行superImp，完成hook。

我们说的给子类新增method，其实并不是一个全新的，而是会共享imp，函数实现没有新增。这样的好处是superSel对应的imp没有改变，它自己的以及它的其它子类不受影响，完美解决此问题；但是继续往下看其它问题

情况2：父类也没有实现

尴尬了，都没有实现方法，那还交换个锤子？？？

先说结果吧，交换函数执行后，方法不会被交换，但是手动调用下面这些，同样会死循环。

- (void)swiprintObj {
    NSLog(@"swi1:%@",self);
    [self swiprintObj];
}

所以我们要加判断，然后返回给方法调用者一个bool值，或者更直接一点，抛出异常。

/// 交换类方法的注意获取meta class, object_getClass。class_getClassMethod
+ (void)swizzleInstanceMethod:(Class)target original:(SEL)originalSelector swizzled:(SEL)swizzledSelector {
    Method originMethod = class_getInstanceMethod(target, originalSelector);
    Method swizzledMethod = class_getInstanceMethod(target, swizzledSelector);
    if (originMethod && swizzledMethod) {
        if (class_addMethod(target, originalSelector, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod))) {
            class_replaceMethod(target, swizzledSelector, method_getImplementation(originMethod), method_getTypeEncoding(originMethod));
        }
        else {
            method_exchangeImplementations(originMethod, swizzledMethod);
        }
    }
    else {
        @throw @"originalSelector does not exit";
    }
}

再加上 dispatch_once 上面已经算是比较完美了，但是并没有完美，主要是场景不同，情况就不同。我们只有理解原理，不同场景不同对待。

新建类来交换系统方法

上面说的都是在分类里面实现交换方法，这里新建"私有类"来交换系统方法。

在写SDK时，分类有重名覆盖问题，编译选项还要加-ObjC。出问题编译阶段还查不出来。那么我们可以用新建一个私有类实现交换，类重名则直接编译报错。交换方法和上面的分类交换稍不一样

比如hook viewDidload，代码如下：

@interface SwizzleClassTest : NSObject
@end

@implementation SwizzleClassTest
+ (void)load {
    /// 私有类，可以不用dispatch_once
    Class target = [UIViewController class];
    Method swiMethod = class_getInstanceMethod(self, @selector(swi_viewDidLoad));
    Method oriMethod = class_getInstanceMethod(target, @selector(viewDidLoad));
    if (swiMethod && oriMethod) {
        if (class_addMethod(target, @selector(swi_viewDidLoad), method_getImplementation(swiMethod), method_getTypeEncoding(swiMethod))) {
            // 这里获取给UIViewController新增的method
            swiMethod = class_getInstanceMethod(target, @selector(swi_viewDidLoad));
            method_exchangeImplementations(oriMethod, swiMethod);
        }
    }
}

- (void)swi_viewDidLoad {
    // 不能调用，这里的self是UIViewController类或者子类的实例，调用test的话直接崩溃。或者做类型判断 [self isKindOfClass:[SwizzleClassTest class]]，然后再调用
    // [self test];
    [self swi_viewDidLoad];
}

- (void)test {
    NSLog(@"Do not do this");
}

@end

这里也用到class_addMethod，给UIViewController新增了一个swi_viewDidLoad sel及其imp实现，共享了SwizzleClassTest 的imp实现。

另外系统发送viewdidload消息进而调用swi_viewDidLoad方法，里面的self是UIViewController，所以不能再[self test]，否则崩溃。也不能在其它地方手动[self swi_viewDidLoad];会死循环，因为这时候self是SwizzleClassTest，而它的method是没有被交换的，好处是我们可以通过self的类型判断来避免。

可以比较下交换前后，

交换前：

SwizzleClassTest_swi_viewDidLoadSel -> SwizzleClassTest_swi_viewDidLoadImp

UIViewController_viewDidLoadSel -> UIViewController_viewDidLoadImp

交换后：

SwizzleClassTest_swi_viewDidLoadSel -> SwizzleClassTest_swi_viewDidLoadImp

UIViewController_swi_viewDidLoadSel -> UIViewController_viewDidLoadImp
UIViewController_viewDidLoadSel -> UIViewController_swi_viewDidLoadImp

可以看出 SwizzleClassTest 没有受影响，映射关系不变。

这种想取消的话，也很简单method_exchangeImplementations

最后补充一点：C函数 实现交换

这里讲的是用C函数交换系统类的方法。而不是fishhook的hook C的函数，目标不一样。原理也不一样

还以hook UIViewController的viewDidLoad为例

上面说到，oc方法调用会转换为objc_msgSend(self,_cmd,param)这种形式，这里再补充一点，objc_msgSend找到imp函数指针后，最终会是imp(self,_cmd,param)调用C函数,imp其实就是个C函数指针。

那么我们可以定义一个C函数，让sel和我们新建的C函数(imp)形成映射。另外还需要记录之前的imp实现，可以定义一个函数指针来保存sel之前的imp实现；大概示意：

之前：
pOriImp = NULL
vcSel -> vcImp
Cfun(){if(pOriImp) pOriImp()}

之后：

pOriImp = vcImp;
vcSel -> cFun;// 函数名即为函数指针

详细如下：

/// 准备1. 定义一个函数指针，用于记录系统原本的IMP实现，并初始化为NULL
void (*origin_test_viewDidload)(id,SEL) = NULL;

/// 准备2. 定义要交换的函数，里面会调用系统的IMP
static void swizzle_test_viewDidload(id self, SEL _cmd)
{
    // 这里打印的self为UIViewController或者子类实例
    NSLog(@"%@",self);
    if (origin_test_viewDidload) {
        origin_test_viewDidload(self, _cmd);
    }
}

/// 开始交换。startHook可以是某个类的方法或实例方法或C函数都可以
+ (void)startHook {
   static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class target = [UIViewController class];
        SEL oriSel = @selector(viewDidLoad);
        // 要交换的函数
        IMP swiImp = (IMP)swizzle_test_viewDidload;
        Method origMethod = class_getInstanceMethod(target, oriSel);
        // 替换之前的先保留
        origin_test_viewDidload = (void *)method_getImplementation(origMethod);
        if (origin_test_viewDidload) {
            // 最后替换，这里用到了set
            method_setImplementation(origMethod, swiImp);
        }
    });
}

这种hook，没有给类的MethodList新增Method，只是替换了实现，对原类改动最小。

和其它hook方式一样，这种对第三方库 的hook，也是不影响。如果第三方库也交换了，均会得到调用

最后，如果你想取消hook，很简单，method_setImplementation为原来的IMP即可。记着把origin_test_viewDidload也置为NULL.

总结

  • 首先要知道方法交换的原理；
  • 熟悉它常用接口；
  • 被交换方法不存在引发的 父类、子类问题；
  • 以及oc中方法的继承、“覆盖”问题；
  • 可能引发重复交换的问题，以及后果；
  • 理解self只是个隐藏参数，并不一定是当前方法所在的类的实例对象

最后，大概三类hook，至于想用哪种，其实无所谓了，看具体场景。但是原理一定要清楚，每次hook时，都要认真推演一遍，计算下可能产生的影响。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 199,393评论 5赞 467
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 83,790评论 2赞 376
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 146,391评论 0赞 330
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 53,703评论 1赞 270
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 62,613评论 5赞 359
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,003评论 1赞 275
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,507评论 3赞 390
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,158评论 0赞 254
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,300评论 1赞 294
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,256评论 2赞 317
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,274评论 1赞 328
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,984评论 3赞 316
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,569评论 3赞 303
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,662评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,899评论 1赞 255
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,268评论 2赞 345
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 41,840评论 2赞 339

推荐阅读更多精彩内容

  • 面试题
    Swift1> Swift和OC的区别1.1> Swift没有地址/指针的概念1.2> 泛型1.3> 类型严谨 对...
    cosWriter阅读 11,076评论 1赞 32
  • iOS面试
    面向对象的三大特性：封装、继承、多态 OC内存管理 _strong 引用计数器来控制对象的生命周期。 _weak...
    运气不够技术凑阅读 1,078评论 0赞 10
  • Runtime梳理(五)
    继上Runtime梳理(四) 通过前面的学习，我们了解到Objective-C的动态特性：Objective-C不...
    小名一峰阅读 737评论 0赞 3
  • Objective-C Runtime
    本文详细整理了 Cocoa 的 Runtime 系统的知识，它使得 Objective-C 如虎添翼，具备了灵活的...
    lylaut阅读 789评论 0赞 4
  • Objective-C 的 Runtime
    我们常常会听说 Objective-C 是一门动态语言，那么这个「动态」表现在哪呢？我想最主要的表现就是 Obje...
    Ethan_Struggle阅读 2,161评论 0赞 7