概述
今天我们主要讨论iOS runtime中的一种黑色技术，称为Method Swizzling。字面上理解Method Swizzling可能比较晦涩难懂，毕竟不是中文，不过你可以理解为“移花接木”或者“偷天换日”。
用途
介绍某种技术的用途，最简单的方式就是抛出一些应用场景来引出这种技术的必要性。因此，这里我举个例子如下。
假设工程中有很多ViewController，我需要你统计每个页面间跳转的次数。要求：对原工程的改动越少越好。
针对以上需求，你可能会立马想出以下两种方案：
方案一：
在每个ViewController的 viewWillAppear 或者 viewDidAppear 方法中对记录跳转次数的某个全局变量(设为 g_viewTransCount )进行计数自增，代码应该是这样的：
|
1
2
3
4
5
|
- (
void
)viewDidAppear:(
BOOL
)animated
{
[
super
viewDidAppear:animated];
g_viewTransCount++;
}
|
每个ViewController类中都需要做此操作，显然不合适。因为跳转次数统计这种业务与APP的主业务并没有强关联，上面的代码会造成耦合度过高。随着APP业务的不断扩大，代码中这样的杂质代码会越来越大，维护也越来越困难。而且该方案也违背了我们的要求：对原工程的改动越少越好。因此方案一是个很差的方法。于是我们有了方案二。
方案二：
有没有某种方法可以不用对每个ViewCotroller都修改呢？有！让每个ViewController都继承某个新的ViewController(设为BaseViewController)，然后将统计的代码放到BaseViewCotroller的 viewWillAppear或者viewDidAppear中。这种方案看似较合理，但有以下弊端：
- 继承自BaseViewCotroller的ViewController中仍旧需要显式调用 [super viewDidAppear:animated];
- 需要到所有ViewController的头文件中更改其superClass为BaseViewController
可见，方案二虽然相比方案一少一些看得到的“代码杂质”，但对工程的改动同样是巨大的，尤其当工程比较庞大时。
正因为以上方案的不完美，才引出本文的黑科技：Method Swizzling。
先概括一下在上述情景下使用Method Swizzling有哪些优势：
- 不需要改动现有工程的任何文件
- 本次统计的代码可复用给其他工程
实现
接下来就是激动人心的Coding Time了。让我们解开Method Swizzling的神秘面纱。直接上代码，有注释。在工程中新建一个UIViewController的category：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
#import "UIViewController+swizzling.h"
#import <objc/runtime.h>
@implementation
UIViewController (swizzling)
+ (
void
)load
{
SEL
origSel =
@selector
(viewDidAppear:);
SEL
swizSel =
@selector
(swiz_viewDidAppear:);
[UIViewController swizzleMethods:[
self
class
] originalSelector:origSel swizzledSelector:swizSel];
}
+ (
void
)swizzleMethods:(Class)
class
originalSelector:(
SEL
)origSel swizzledSelector:(
SEL
)swizSel
{
Method origMethod = class_getInstanceMethod(
class
, origSel);
Method swizMethod = class_getInstanceMethod(
class
, swizSel);
BOOL
didAddMethod = class_addMethod(
class
, origSel, method_getImplementation(swizMethod), method_getTypeEncoding(swizMethod));
if
(didAddMethod) {
class_replaceMethod(
class
, swizSel, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
}
else
{
method_exchangeImplementations(origMethod, swizMethod);
}
}
- (
void
)swiz_viewDidAppear:(
BOOL
)animated
{
NSLog
(@
"I am in - [swiz_viewDidAppear:]"
);
[
self
swiz_viewDidAppear:animated];
}
@end
|
上述代码做了这么一件事：在UIViewController的viewDidAppear:方法调用前插入了跳页计数处理，这一切都在运行时完成。对于上述代码有以下几处需要介绍的：
+ (void)load 方法是一个类方法，当某个类的代码被读到内存后，runtime会给每个类发送 + (void)load 消息。因此 + (void)load 方法是一个调用时机相当早的方法，而且不管父类还是子类，其 + (void)load 方法都会被调用到，很适合用来插入swizzling方法
最核心的代码要数 + (void)swizzleMethods:(Class)class originalSelector:(SEL)origSel swizzledSelector:(SEL)swizSel 了。从函数签名可以看出，该函数是为了交换两个方法内部实现。将目光移到Line23，交换两个方法的内部实现主要依靠两个runtime API:
|
1
2
|
class_replaceMethod(
class
, swizSel, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
method_exchangeImplementations(origMethod, swizMethod);
|
再看一下Line32， - (void)swiz_viewDidAppear:(BOOL)animated 函数看起来像死循环，实际上不会的。原因请看我在下图的注释：
![]()
此外，通过断点可以进一步判断出view controller的viewDidAppear实际方法体与category的swiz_viewDidAppear方法的执行先后顺序。为了更直观地说明二者的顺序，我们可以看一下我打出的Log：
![]()
通过Log所打印出的顺序足以验证我们的想法。
以上的method swizzling可以应用于iOS的任何类中对其进行代码注入，并且丝毫不影响现有工程的代码。例如，我再举个例子(没办法，我就是喜欢举例子，但我无非是想让你掌握的更多一些)。你想统计整个工程中所有按钮的点击事件的次数，也就是touchUpInside event发生的次数。刚开始你可能会觉得稍微有些没有头绪，因为注入代码的“切入点”相比于UIViewController的viewDidLoad等方法而言不是那么好找。这时候如果你能仔细考虑以下问题或许能找到思路：
- touchUpInside event发送给什么对象？
- 该对象本通过什么途径接受这个消息？
第一个问题很好回答，event是发送给UIButton实例，本质上是发送给UIControl实例；
第二个问题你不懂的话就去看看UIControl的头文件找找线索，于是在头文件中我们找到这样一个函数：
|
1
|
- (
void
)sendAction:(
SEL
)action to:(
id
)target forEvent:(UIEvent *)event;
|
看起来很靠近我们的需求， 事实上的确如此。这要从iOS的事件传递机制说起，当你在iOS设备上触摸一个点时这个触摸动作被包装成一个UIEvent按照UIApplication->UIWindow->UIView的顺序传递下去，当发现最后的接受者是UIControl时就会发送上述消息。因此，我们可以对sendAction:方法进行swizzling代码注入来达到统计按钮点击次数的目的。更深入一些，则需要针对不同的action、target、event的状态进行判断，以达到更精准的统计。关于这一部分内容我将在下一篇iOS动态性系列文章中详细探讨，敬请期待！
OK，文章就到这里，小伙伴们洗洗睡吧。哈哈，开个玩笑，俗话说，“好戏都在后头”，接下来的部分更好用。看来以上的method swizzling代码你是否觉得太复杂了？此外，当你尝试对多个类进行swizzle时会发现很多代码是冗余的，每个category文件的框架都长得差不多。那是否有进一步封装的可能性呢？那是必须的。庆幸的是有团队已经帮我们封装了，我们直接拿来用就可以。这就是有名的Aspect库。
AOP编程以及Aspect库
Aspect库是对面向切面编程(Aspect Oriented Programming)的实现，里面封装了Runtime的方法，也封装了上文的Method Swizzling方法。因此我们也可以看到，Method Swizzling也是AOP编程的一种。Aspect的用途很广泛，这里不具体展开，想了解更多的可以看一下官方github的介绍，已经够详细了。这里我们只介绍其基础应用。Aspect只提供了两个接口：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
+ (
id
<AspectToken>)aspect_hookSelector:(
SEL
)selector
withOptions:(AspectOptions)options
usingBlock:(
id
)block
error:(
NSError
**)error {
return
aspect_add((
id
)
self
, selector, options, block, error);
}
- (
id
<AspectToken>)aspect_hookSelector:(
SEL
)selector
withOptions:(AspectOptions)options
usingBlock:(
id
)block
error:(
NSError
**)error {
return
aspect_add(
self
, selector, options, block, error);
}
|
使用起来也非常方便，使用Aspect对本文最初提出的需求“统计每个页面间跳转的次数”进行改造，代码变成这样子：
|
1
2
3
4
5
6
7
|
[UIViewController aspect_hookSelector:
@selector
(viewDidLoad)
withOptions:AspectPositionBefore
usingBlock:^(
id
<AspectInfo> info){
g_viewTransCount++
NSLog
(@
"[ASPECT] inject in class instance:%@"
, [info instance]);
}
error:
NULL
];
|
将以上代码放到AppDelegate的 didFinishLaunchingWithOptions 函数最开始处即可，你可以参考我在文末贴出的代码，使用一个专门的管理类来管理这些AOP代码。
相比于上半部分的原始Method Swizzling代码，使用Aspect有以下好处：
- 原则上不需要新建任何文件。这点很好理解，原始Method Swizzling需要新建category文件，当代码注入的需要较多时会出现过多的文件以及冗余代码。
- 可以对类的实例进行代码注入，因为Aspect提供了实例方法以及类方法
写在最后
Method Swizzling以及Runtime的一些特性就是iOS里的黑科技，如果能灵活应用的话可以在保证解决问题的前提下降低模块之间的耦合度，提高代码的可复用性。至于Method Swizzling与Aspect库的选择因人而异，我个人建议在最初阶段先放下Aspect而只用Method Swizzling原始代码去实现代码注入。掌握本质总是不吃亏的。
本文转自编程小翁博客园博客，原文链接：http://www.cnblogs.com/wengzilin/p/4704996.html，如需转载请自行联系原作者
