引
先前一段时间,就职于国内某知名创业公司的HF在重构历史代码的时候向我吐槽到:NStimer这个东西真的有那么麻烦么?
我:what?
HF:历史遗留代码中很多NSTimer的错误,说白了就是大量的循环引用导致不进入dealloc
我:额..可能忘了吧,习惯不太好.
HF:要不咱们来想个办法,一来解决习惯不好/忘了等原因导致的循环引用.二来解决历史遗留问题更方便.
我:好
开始
HF很快撸好了一个自定义的timer,内部target做了weak引用.循环引用的问题解决.然后达到了我们的目的了么?似乎没有.
- 侵入性.这点在解决历史遗留问题显得比较严重,会大面积的修改
NSTimer为HFTimer.假设遇上一些类型检测,可能会导致未知的问题. - 往深入的想,既然timer不retain target,那么当target释放的时候,timer也就没办法执行action了,那么一旦因为各种原因忘了
inValidate,岂不是就crash了,似乎没那么安全.
于是我们期望有一个东西,最好是timer的某个属性,设置了以后,就可以不用retain target.并且是安全的,意味着当target释放后,timer能够感知并且自动的inValidate.
HFPrettyTimer
最终有HFPrettyTimer这个东西,看似黑魔法,实际上代码也就一点点.
首先它的直观感受是这样的:
@PrettyTimer(self)
self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(test) userInfo:nil repeats:YES];
是的,然后就没有然后了.只是一个宏定义而已.只要调用了这个宏,timer将不会retain target,并且会在target释放的时候自动的停止(inValidate).当然,手动调用停止也没问题.
并且,在一个方法的作作用域内,timer均有效,而非属性,每个实例都要设置一次.出了作用域,则无效.例如:
- (IBAction)startTimer:(id)sender {
@PrettyTimer(self)
self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(changeNumber) userInfo:nil repeats:YES];
self.timer1 = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(changeNumber1) userInfo:nil repeats:YES];
}
Swizzle
显而易见,没有继承timer,没有新的类,没有新的属性.那么分类/继承/重写是没办法做到的.那么只能通过交换来做到了.
在HFPrettyTimer中,交换了除了init以外的其余新建NSTimer实例的方法.
交换的目的在于,将传入的target weak化,虽然NSTimer必然会retain target,但是通过交换,我们有能力决定retain的target是哪一个target.
weak化是一个比较常见的技巧,YYKit里面也经常使用到.通过weak属性切断循环引用,通过方法转发进行消息传递:
@interface HFWeakensTarget : NSObject
@property (nonatomic, weak) id target;
+ (HFWeakensTarget *)weakensTarget:(id)target;
@end
@implementation HFWeakensTarget
+ (HFWeakensTarget *)weakensTarget:(id)target {
HFWeakensTarget *weakens = [HFWeakensTarget new];
weakens.target = target;
return weakens;
}
- (BOOL)respondsToSelector:(SEL)aSelector {
return [self.target respondsToSelector:aSelector];
}
- (id)forwardingTargetForSelector:(SEL)aSelector {
return self.target;
}
- (Class)class {
return [self.target class];
}
- (BOOL)isKindOfClass:(Class)aClass {
return [self.target isKindOfClass:aClass];
}
- (BOOL)isMemberOfClass:(Class)aClass {
return [self.target isMemberOfClass:aClass];
}
- (BOOL)conformsToProtocol:(Protocol *)aProtocol {
return [self.target conformsToProtocol:aProtocol];
}
- (NSString *)description {
return [self.target description];
}
@end
切断循环引用比较简单,那么就即将进入第二步:感知target的释放,在target释放的时候inValidate.
Dealloc通知
释放必然和dealloc打交道.所以对于这个问题,第一反应是,要不咱们把dealloc交换了?
额..这种NSObject的基础中的基础方法,危险性暂且不说.就为了做timer的这个需求,每个dealoc中都要进行判断,本身效率上也无法接受.
想了想,只能充分利用ARC的特性.当一个Object释放的时候,它身上的所有Object正常状态下都会释放.target我们无法控制,那能否让一个我们能控制的东西和target产生联系呢.
于是一个大家用烂了的东西出场:objc_setAssociatedObject
通过挂载一个自己的Object到target上,当target释放后,自己的Object也同样会释放,通过自己的Object的dealloc方法,就能知道target的释放了.
详见源码中:HFDeallocDetector文件.
交换标记
因为交换是针对于所有的NSTimer,这样势必会影响到iOS系统的使用和历史代码的使用,风险非常大.所以需要做个标记,当有这个标记的时候,才进行以上的逻辑.否则仍然是原声NSTimer的逻辑.
还是objc_setAssociatedObject出场,给target设置一个对象.当检测到这个对象的时候,则认为被标记,执行交换等操作,否则不执行.
对象的key只能尽量保证不冲突,但无法百分百保证.所以这里使用了一个MD5码.
char *const HFWeakenIdentifier = "57fb44e903ebfc31d01d568fbbb2006b"; //handsomeCharles :)
作用域
基本上成型了,最后考虑到一个问题.因为给一个target打上了标记,那么一定需要删除这个标记,在什么时候删除呢?是使用后(通过标记判断后)就删除吗?
可以,但是不太方便.假设有2个timer呢?所以希望是作用于完了之后删除.遇是想到了sunny大介绍的神器:__attribute__((cleanup()))
于是有了PrettyTimer这个宏(宏是真写的少,请原谅写的low):
#define PrettyTimer(x)\
autoreleasepool {}\
__strong NSObject *strongX __attribute__((cleanup(removeWeakenIdentifier))) = x;\
objc_setAssociatedObject(strongX, HFWeakenIdentifier, @"", OBJC_ASSOCIATION_COPY_NONATOMIC);\
至于autoreleasepool,纯粹想学RAC装一下...
完结
经过一番调试,然后就完结了.
可以查看HF的github,read me就别管了...本来说用我蹩脚的英文写一个,最近太忙.只能稍后了.
