iOS开发:MethodSwizzling-创新互联
iOS 开发之Method Swizzling
前言
如果你还不知道什么是Method Swizzling,你可以看看NSHipster 的文章 ,我简单介绍一下,method swizzling 可以看成劫持了一个方法。
目前创新互联已为近千家的企业提供了网站建设、域名、网页空间、网站运营、企业网站设计、淮阴网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。我们可以看看NSHipster 的文章中有以下代码:
- (void)xxx_viewWillAppear:(BOOL)animated {
[self xxx_viewWillAppear:animated];
NSLog(@"viewWillAppear: %@", self);
}
是不是觉得递归无限循环,事实上并不会,你可以这么理解,一个具体的SEL是个名字,一个具体的IMP是个函数指针,在类里面它们是靠一个表建立联系。
假设(纯属虚构) UIViewController 的 @selector(viewWillAppear:) 对应的内部实现为以下
void _UIKIT_Internal_UIViewController_viewWillAppear(id vc, SEL selector, BOOL animated) {
...// ^_^苹果私有代码
}
假设UIViewController 的 @selector(xxx_viewWillAppear:) 的实现为以下
void my_xxx_viewWillAppear(id vc, SEL selector, BOOL animated) {
[vc performSelector:@selector(xxx_viewWillAppear) withObject:@(animated)];
NSLog(@"viewWillAppear: %@", vc);
}
那么未替换方法前@selector(viewWillAppear:)对应的指针就是&_UIKIT_Internal_UIViewController_viewWillAppear
那么未替换方法前@selector(xxx_viewWillAppear:)对应的指针就是&my_xxx_viewWillAppear
一旦替换方法后,@selector(viewWillAppear:)对应的指针就是&my_xxx_viewWillAppear,
@selector(xxx_viewWillAppear:)对应的指针就是&_UIKIT_Internal_UIViewController_viewWillAppear
my_xxx_viewWillAppear 中的 [vc performSelector:@selector(xxx_viewWillAppear) withObject:@(animated)];
相当于什么,相当于 调用@selector(xxx_viewWillAppear:)所指的函数&_UIKIT_Internal_UIViewController_viewWillAppear, 也就是相当于调用原来的函数,所以这并不是递归。
存在的危险
- 有些NSObject类是类簇,替换方法要找到真正的类,如NSArray替换方法,通常用'_NSArrayM'或'_NSArrayI'
- 执行顺序问题,ViewController是自己写的类,ViewController的load方法和UIViewController的category里的load方法哪个先执行,如果是ViewController的先执行,那么UIViewController的swizzling就对ViewController无效,如果ViewController的后执行就一切正常,代码如下
@implementation UIViewController (Tracking)
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self replaceOriginalSelector:@selector(viewWillAppear:) withNewSelector:@selector(xxx_viewWillAppear:)];
});
}
- (void)xxx_viewWillAppear:(BOOL)animated {
[self xxx_viewWillAppear:animated];
NSLog(@"x_viewWillAppear: %@", self);
}
@end
@interface ViewController ()
@end
@implementation ViewController
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self replaceOriginalSelector:@selector(viewWillAppear:) withNewSelector:@selector(yyy_viewWillAppear:)];
});
}
- (void)yyy_viewWillAppear:(BOOL)animated {
[self yyy_viewWillAppear:animated];
NSLog(@"y_viewWillAppear: %@", self);
}
@end
3.也是顺序问题
以下,来自另一篇文章defagos.github.io
它是这么说的,NSObject 实现了 -awakeFromNib,但是它的子类UIView,孙类UILabel都没有在本类实现- awakeFromNib,那么替换时如果不写在category +(void) load方法里,那么顺序也是个问题
假设我们先替换了UILabel的- awakeFromNib方法,然后再替换了UIView的- awakeFromNib,那么UILabel的- awakeFromNib方法就不会执行UIView的- awakeFromNib方法,因为它们都是独立替换的是NSObject方法,这篇文章defagos.github.io 提供了一个解决方案,当本类没有实现方法(如 UILabel -awakeFromNib)时,首先先添加一个block方法 调用[super awakeFromNib];,我初次看到也是觉得这个方式很好,但是我发现两点不足,
在构建objc_super时,如果父类本身没有实现方法,.super_class = class_getSuperclass(clazz),这么写好像是没有用的,似乎super_class要填真正实现方法的祖先类,而不能一概的写class_getSuperclass
struct objc_super super = { .receiver = self, .super_class = class_getSuperclass(clazz) };
- va_list的使用
id (*objc_msgSendSuper_typed)(struct objc_super *, SEL, va_list) = (void *)&objc_msgSendSuper;
由于 va_list 变量最后是靠宏 va_arg(ap, type)
来获取的,type又是未知的,这个函数指针的强制转换转换可能会出现问题
结语
可见,Swizzling正确的顺序是十分重要的,(共同点:类本身没有真正实现方法)
- 如果你的Swizzling是静态的,那么就保证父类的Swizzling发生在子类的Swizzling前
- 如果你的Swizzling是动态的或者你管不好他们先后顺序,那么就要用defagos的方法动态的call objc_msgSendSuper,
- 或许你勤快一点还可以直接在category里面重写,
- (void)awakeFromNib { [super awakeFromNib]; }
另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
名称栏目:iOS开发:MethodSwizzling-创新互联
当前URL:http://azwzsj.com/article/csccjh.html