理解Objective-C Runtime（四）Method Swizzling

Objective-C对象收到消息之后，究竟会调用何种方法需要在运行期间才能解析出来。那你也许会问：与给定的选择子名称相应的方法是不是也可以在runtime改变呢？没错，就是这样。若能善用此特性，则可发挥出巨大优势，因为我们既不需要源代码，也不需要通过继承子类来覆写方法就能改变这个类本身的功能。这样一来，新功能将在本类的所有实例中生效，而不仅限于覆写了相关方法的那些子类实例。此方案就是大名鼎鼎的「method swizzling」，中文常称之为『方法调配』或『方法调和』或『方法混合』。

Method Swizzling

类的方法列表会把选择子的名称映射到相关的方法实现之上，使得「动态消息派发系统」（dynamic message-dispatch system）能够据此找到应该调和的方法。这些方法均以函数指针的形式来表示，这种指针叫IMP（IMP在《理解Objective-C Runtime（一）预备知识》已有说明）。

举个栗子，NSString类可以响应lowercaseString、uppercaseString、capitalizedString等选择子。这张映射表（selector table，也常称为「选择器表」）中的每个选择子都映射到不同的IMP之上，如下图所示：

举个栗子，NSString类可以响应lowercaseString、uppercaseString、capitalizedString等选择子。这张映射表（selector table，也常称为「选择器表」）中的每个选择子都映射到不同的IMP之上，如下图所示：

Objective-C runtime系统提供的几个方法都能够用来操作这张表。开发者可以向其中新增selector，也可以改变某个selector所对应的方法实现，还可以交换两个selector所映射到的指针。经过几次操作之后，类的方法就会变成如下图所示：

在新的映射表中，多了一个名为newSelector的选择子，lowercaseString和uppercaseString的实现则互换了。上述修改均无需编写子类，只要修改『方法表』的布局即可，就会反映到程序中所有的NSString实例之上。

交换两个方法的实现

现在通过示例代码演绎『调换NSString的lowercaseString和uppercaseString的方法实现』，具体实现操作是这样的：

- (void)viewDidLoad {

    [super viewDidLoad];

    NSString *aString = @"AbcDEfg";

    // lowercaseString和uppercaseString交换前：
    NSLog(@"lowercaseString和uppercaseString交换前：");
    NSLog(@"lowercase of the string : %@", [aString lowercaseString]);
    NSLog(@"uppercase of the string : %@", [aString uppercaseString]);

    // class_getInstanceMethod方法得到Method类型
    Method originalMethod = class_getInstanceMethod([NSString class], @selector(lowercaseString));
    Method swappedMethod = class_getInstanceMethod([NSString class], @selector(uppercaseString));

    // method_exchangeImplementations交换映射指针
    method_exchangeImplementations(originalMethod, swappedMethod);

    // lowercaseString和uppercaseString交换后：
    NSLog(@"lowercaseString和uppercaseString交换后：");
    NSLog(@"lowercase of the string : %@", [aString lowercaseString]);
    NSLog(@"uppercase of the string : %@", [aString uppercaseString]);
}

/* 输出结果：
lowercaseString和uppercaseString交换前：
lowercase of the string : abcdefg
uppercase of the string : ABCDEFG
lowercaseString和uppercaseString交换后：
lowercase of the string : ABCDEFG
uppercase of the string : abcdefg
*/

这演示了如何交换两个方法的实现，然而在实际应用中，像这样直接交换两个方法实现，其意义不大，除非闲得蛋疼。但是，可以通过这一手段来为既有的方法实现增添新功能。

修改既有方法的行为

介绍一个技巧，最好的方式就是提出具体的需求，然后用它跟其他的解决方法做比较。

所以，先来看看我们的需求：对 App 的用户行为进行追踪和分析。简单说，就是当用户看到某个View或者点击某个Button的时候，就把这个事件记下来。

手动添加

@implementation MyViewController ()

- (void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];

    // Custom code 

    // Logging
    [Logging logWithEventName:@“my view did appear”];
}

- (void)myButtonClicked:(id)sender
{
    // Custom code 

    // Logging
    [Logging logWithEventName:@“my button clicked”];
}

这种方式的缺点也很明显：它破坏了代码的干净整洁。因为 Logging 的代码本身并不属于 ViewController 里的主要逻辑。随着项目扩大、代码量增加，你的 ViewController 里会到处散布着 Logging 的代码。这时，要找到一段事件记录的代码会变得困难，也很容易忘记添加事件记录的代码。

你可能会想到用继承或类别，在重写的方法里添加事件记录的代码。代码可以是长的这个样子：

- (void)myViewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];

    // Custom code 

    // Logging
    [Logging logWithEventName:NSStringFromClass([self class])];
}

- (void)myButtonClicked:(id)sender
{
    // Custom code 

    // Logging
    NSString *name = [NSString stringWithFormat:@“my button in %@ is clicked”, NSStringFromClass([self class])];
    [Logging logWithEventName:name];
}

Logging 的代码都很相似，通过继承或类别重写相关方法是可以把它从主要逻辑中剥离出来。但同时也带来新的问题：

1. 你需要继承UIViewController，UITableViewController，UICollectionViewController所有这些ViewController，或者给他们添加类别；
2. 每个ViewController里的ButtonClick方法命名不可能都一样；
3. 你不能控制别人如何去实例化你的子类；
4. 对于类别，你没办法调用到原来的方法实现，大多时候，我们重写一个方法只是为了添加一些代码，而不是完全取代它；
5. 如果有两个类别都实现了相同的方法，运行时没法保证哪一个类别的方法会给调用。

Method Swizzling的做法

Method Swizzling的做法是新增一个方法log_viewDidAppear:，在这个方法体中调用viewDidAppear:的方法体；然后将log_viewDidAppear:和viewDidAppear:进行调换。呃，有些绕，看图吧：

新增方法log_viewDidAppear:的实现代码可以这样写：

- (void)log_viewDidAppear:(BOOL)animated
{
    [self log_viewDidAppear:animated];

    // Logging
    [Logging logWithEventName:NSStringFromClass([self class])];
}

看起来，这段代码好像会陷入递归使用的死循环，不过要记住，此方法是准备和viewDidAppear:方法互换的。所以，在runtime，log_viewDidAppear:选择子对应的是原来viewDidAppear:方法的实现；同样，当向对象发送viewDidAppear:消息时，如上这段代码会被调用，而这段代码的第一句是[self log_viewDidAppear:animated];，这其实是调用原来viewDidAppear:方法的实现代码…

定义了log_viewDidAppear:的实现后，还得与viewDidAppear:进行交换：

// class_getInstanceMethod方法得到Method类型
Method originalMethod = class_getInstanceMethod([NSString class], @selector(viewDidAppear:));
Method swappedMethod = class_getInstanceMethod([NSString class], @selector(log_viewDidAppear:));

// method_exchangeImplementations交换映射指针
method_exchangeImplementations(originalMethod, swappedMethod);

如何安排method swizzling相关的代码？

一般来说，runtime相关的代码都会以category的形式组织，所以上述log_viewDidAppear:方法的实现会写在一个UIViewController category中，比如UIViewController(log)。而「交换方法」相关的代码会写在category的load中。因为load方法是在runtime之前就被执行的，只要category所在的头文件被引用，load方法就会被调用，并且同一个class在不同category之间允许有多个load方法，这些load方法都会被调用（唯一的问题是谁先谁后）。

通过method swizzling方案，开发者可以为那些『完全不知道具体实现的』（completely opaque，『完全不透明』）黑盒方法增加日志记录功能，这非常有助于程序调试，然而，此做法只在调试程序时有用。很少有人在调试程序之外的场合用上述『方法调配技术』来永久改变某个类的功能，因为如果使用不慎，它造成的破坏太大了，并且很难Debug。不能仅仅因为Objective-C语言里有这个特性就一定要用它。若是滥用，反而会令代码变得不易读懂且难于维护。

总之，Method Swizzling只一个挺有争议的技术，对此有很多分析的文章，底部的参考资料中有链接。

AOP(Aspect Oriented Programming)

在阅读博客《Method Swizzling和AOP实践》时了解到了一个新概念 — AOP。简单来说，在Objective-C世界中，AOP就是利用Runtime特性给指定的方法添加自定义代码，Method Swizzling是其中一种实现AOP的方式之一。

参考资料

1. 《Effective Objective-C 2.0》；
2. 《iOS开发进阶》；
3. 《Method Swizzling和AOP实践》；
4. 大神Mattt Thompson（AFNetworking作者）的《Method Swizzling》；
5. 《Objective-C的hook方案（一）: Method Swizzling》；
6. What are the Dangers of Method Swizzling in Objective C?；
7. 《Objective-C Runtime》