Objective-C Method Swizzling 的最佳实践
2015-06-15 11:49
591 查看
Objective-C 中的 Method Swizzling 是一项异常强大的技术,它可以允许我们动态地替换方法的实现,实现
Method Swizzling 是一把双刃剑,使用得当可以让我们非常轻松地实现复杂的功能,而如果一旦误用,它也很可能会给我们的程序带来毁灭性的伤害。但是我们大可不必惊慌,在了解了它的实现原理后,我们就可以“信手拈来”了。
我们先来了解下 Objective-C 中方法
本质上,它就是
Encodings);
由此,我们也可以发现 Objective-C 中的方法名是不包括参数类型的,也就是说下面两个方法在 runtime 看来就是同一个方法:
而下面两个方法却是可以共存的:
因为实例方法和类方法是分别保存在类对象和元类对象中的,更多详情可以查看我前面的文章《Objective-C 对象模型》。
原则上,方法的名称
Method Swizzling 的原理就是动态地改变它们的对应关系,以达到替换方法实现的目的。
说了这么多,到底 Method Swizzling 有什么用呢?表猴急哈,我们接下来看个例子就明白了。用过友盟统计的同学应该知道,要实现页面的统计功能,我们需要在每个页面的
要达到这个目的,我们有两种比较常规的实现方式:
直接修改每个页面的
子类化
第 1 种方式的缺点是不言而喻的,这样做不仅会产生大量重复的代码,而且还很容易遗漏某些页面,非常难维护;第 2 种方式稍微好一点,但是也同样需要我们子类化
也许你跟我一样陷入了思考,难道就没有一种简单优雅的解决方案吗?答案是肯定的,Method Swizzling 就是解决此类问题的最佳方式。
下面我们就以替换
Method Swizzling 的最佳实践,话不多说,直接上代码:
解析:在上面的代码中有三个关键点需要引起我们的注意:
为什么是在
Method Swizzling 的逻辑,而不是其他的什么方法,比如
为什么 Method Swizzling 的逻辑需要用 dispatch_once 来进行调度;
为什么需要调用
下面我们就一起来分析下这三个为什么到底是为了什么?
第 1 个为什么:看过我前面文章《Objective-C
+load vs +initialize》 的同学应该知道,
Objective-C runtime 会自动调用的两个类方法。但是它们被调用的时机却是有差别的,
Objective-C runtime 自动调用
Method Swizzling 逻辑的最佳“场所”。
第 2 个为什么:我们上面提到,
runtime 自动调用一次,但是它并没有限制程序员对
第 3 个为什么:我们使用 Method Swizzling 的目的通常都是为了给程序增加功能,而不是完全地替换某个功能,所以我们一般都需要在自定义的实现中调用原始的实现。所以这里就会有两种情况需要我们分别进行处理:
第 1 种情况:主类本身有实现需要替换的方法,也就是
第 2 种情况:主类本身没有实现需要替换的方法,而是继承了父类的实现,即
看到这里,相信你对 Method Swizzling 已经有了一定的了解,那么接下来就请你自己亲自试一试吧,you should give it a try yourself 。
Method Swizzling 是一种黑魔法,我们在使用它时需要加倍小心,而遵循本文的最佳实践可以让你事半功倍。
http://nshipster.com/method-swizzling/
https://www.mikeash.com/pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html
Posted by 雷纯锋 Jun 14th, 2015 12:03
pm
原文链接:http://blog.leichunfeng.com/blog/2015/06/14/objective-c-method-swizzling-best-practice/
Hook功能,是一种比子类化更加灵活的“重写”方法的方式。
Method Swizzling 的原理
Method Swizzling 是一把双刃剑,使用得当可以让我们非常轻松地实现复杂的功能,而如果一旦误用,它也很可能会给我们的程序带来毁灭性的伤害。但是我们大可不必惊慌,在了解了它的实现原理后,我们就可以“信手拈来”了。我们先来了解下 Objective-C 中方法
Method的数据结构:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | typedef struct method_t *Method; struct method_t { SEL name; const char *types; IMP imp; struct SortBySELAddress : public std::binary_function<const method_t&, const method_t&, bool> { bool operator() (const method_t& lhs, const method_t& rhs) { return lhs.name < rhs.name; } }; }; |
struct method_t类型的指针,所以我们重点看下结构体
method_t的定义。在结构体
method_t中定义了三个成员变量和一个成员函数:
name表示的是方法的名称,用于唯一标识某个方法,比如
@selector(viewWillAppear:);
types表示的是方法的返回值和参数类型(详细信息可以查阅苹果官方文档中的 Type
Encodings);
imp是一个函数指针,指向方法的实现;
SortBySELAddress顾名思义,是一个根据
name的地址对方法进行排序的函数。
由此,我们也可以发现 Objective-C 中的方法名是不包括参数类型的,也就是说下面两个方法在 runtime 看来就是同一个方法:
1 2 | - (void)viewWillAppear:(BOOL)animated; - (void)viewWillAppear:(NSString *)string; |
1 2 | - (void)viewWillAppear:(BOOL)animated; + (void)viewWillAppear:(BOOL)animated; |
原则上,方法的名称
name和方法的实现
imp是一一对应的,而
Method Swizzling 的原理就是动态地改变它们的对应关系,以达到替换方法实现的目的。
Method Swizzling 有什么用
说了这么多,到底 Method Swizzling 有什么用呢?表猴急哈,我们接下来看个例子就明白了。用过友盟统计的同学应该知道,要实现页面的统计功能,我们需要在每个页面的 view controller中添加如下代码:
1 23 | - (void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; [MobClick beginLogPageView:@"PageOne"]; } - (void)viewWillDisappear:(BOOL)animated { [super viewWillDisappear:animated]; [MobClick endLogPageView:@"PageOne"]; } |
直接修改每个页面的
view controller代码,简单粗暴;
子类化
view controller,并让我们的
view controller都继承这些子类。
第 1 种方式的缺点是不言而喻的,这样做不仅会产生大量重复的代码,而且还很容易遗漏某些页面,非常难维护;第 2 种方式稍微好一点,但是也同样需要我们子类化
UIViewController、
UITableViewController和
UITabBarController等不同类型的
view controller。
也许你跟我一样陷入了思考,难道就没有一种简单优雅的解决方案吗?答案是肯定的,Method Swizzling 就是解决此类问题的最佳方式。
Method Swizzling 的最佳实践
下面我们就以替换 viewWillAppear方法为例谈谈
Method Swizzling 的最佳实践,话不多说,直接上代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 1516 | @interface UIViewController (MRCUMAnalytics) @end @implementation UIViewController (MRCUMAnalytics) + (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ Class class = [self class]; SEL originalSelector = @selector(viewWillAppear:); SEL swizzledSelector = @selector(mrc_viewWillAppear:); Method originalMethod = class_getInstanceMethod(class, originalSelector); Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector); BOOL success = class_addMethod(class, originalSelector, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod)); if (success) { class_replaceMethod(class, swizzledSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod)); } else { method_exchangeImplementations(originalMethod, swizzledMethod); } }); } #pragma mark - Method Swizzling - (void)mrc_viewWillAppear:(BOOL)animated { [self mrc_viewWillAppear:animated]; [MobClick beginLogPageView:NSStringFromClass([self class])]; } @end |
为什么是在
+load方法中实现
Method Swizzling 的逻辑,而不是其他的什么方法,比如
+initialize等;
为什么 Method Swizzling 的逻辑需要用 dispatch_once 来进行调度;
为什么需要调用
class_addMethod方法,并且以它的结果为依据分别处理两种不同的情况。
下面我们就一起来分析下这三个为什么到底是为了什么?
第 1 个为什么:看过我前面文章《Objective-C
+load vs +initialize》 的同学应该知道,
+load和
+initialize是
Objective-C runtime 会自动调用的两个类方法。但是它们被调用的时机却是有差别的,
+load方法是在类被加载的时候调用的,而
+initialize方法是在类或它的子类收到第一条消息之前被调用的,这里所指的消息包括实例方法和类方法的调用。也就是说
+initialize方法是以懒加载的方式被调用的,如果程序一直没有给某个类或它的子类发送消息,那么这个类的
+initialize方法是永远不会被调用的。此外
+load方法还有一个非常重要的特性,那就是子类、父类和分类中的
+load方法的实现是被区别对待的。换句话说在
Objective-C runtime 自动调用
+load方法时,分类中的
+load方法并不会对主类中的
+load方法造成覆盖。综上所述,
+load方法是实现
Method Swizzling 逻辑的最佳“场所”。
第 2 个为什么:我们上面提到,
+load方法在类加载的时候会被
runtime 自动调用一次,但是它并没有限制程序员对
+load方法的手动调用。什么?你说不会有程序员这么干?那可说不定,我还见过手动调用
viewDidLoad方法的程序员,就是介么任性。而我们所能够做的就是尽可能地保证程序能够在各种情况下正常运行。
第 3 个为什么:我们使用 Method Swizzling 的目的通常都是为了给程序增加功能,而不是完全地替换某个功能,所以我们一般都需要在自定义的实现中调用原始的实现。所以这里就会有两种情况需要我们分别进行处理:
第 1 种情况:主类本身有实现需要替换的方法,也就是
class_addMethod方法返回
NO。这种情况的处理比较简单,直接交换两个方法的实现就可以了:
1 23 | - (void)viewWillAppear:(BOOL)animated { /// 先调用原始实现,由于主类本身有实现该方法,所以这里实际调用的是主类的实现 [self mrc_viewWillAppear:animated]; /// 我们增加的功能 [MobClick beginLogPageView:NSStringFromClass([self class])]; } - (void)mrc_viewWillAppear:(BOOL)animated { /// 主类的实现 } |
class_addMethod方法返回
YES。这时使用
class_getInstanceMethod函数获取到的
originalSelector指向的就是父类的方法,我们再通过执行
class_replaceMethod(class, swizzledSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod));将父类的实现替换到我们自定义的
mrc_viewWillAppear方法中。这样就达到了在
mrc_viewWillAppear方法的实现中调用父类实现的目的。
1 23 | - (void)viewWillAppear:(BOOL)animated { /// 先调用原始实现,由于主类本身并没有实现该方法,所以这里实际调用的是父类的实现 [self mrc_viewWillAppear:animated]; /// 我们增加的功能 [MobClick beginLogPageView:NSStringFromClass([self class])]; } - (void)mrc_viewWillAppear:(BOOL)animated { /// 父类的实现 } |
总结
Method Swizzling 是一种黑魔法,我们在使用它时需要加倍小心,而遵循本文的最佳实践可以让你事半功倍。
参考链接
http://nshipster.com/method-swizzling/ https://www.mikeash.com/pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html
Posted by 雷纯锋 Jun 14th, 2015 12:03
pm
原文链接:http://blog.leichunfeng.com/blog/2015/06/14/objective-c-method-swizzling-best-practice/
相关文章推荐
- JSONObject与JSONArray的使用
- objective c 类目 延展 协议
- Objective-C类成员变量深度剖析
- Objective-C Method Swizzling 的最佳实践
- 学习笔记(objective-c)-类别(category)
- 学习笔记(objective-c)-重写isEqual方法
- objective-c 键值监听
- iOS开发--Objective-C之KVC
- Objective-C 知识点总结
- Objective-C面试题2
- Objective-C面试题
- [Objective-C] 006_Protocol(协议)
- Object-c-数组的使用
- 关于等待多长时间会引发ORA-04021: timeout occurred while waiting to lock object错误的猜测
- objective-c中线程编程一例
- objective-c中线程编程一例
- objective-c中线程编程一例
- Object-C中需要注意的小细节
- 使用Object#tap使代码更优雅
- 学习笔记(objective-c)-重写description方法