NSTimer
和CADisplayLink
使用不当会造成强引用循环的问题已经是老生常谈,但是一直也不放在心上(毕竟没有给我踩到过坑),最近在看ibreme大神的YYKit的过程中发现YYKit有专门来解决NSTimer
和CADisplayLink
强引用循环的方法。自己写了个Demo发现使用姿势不当的话,强引用循环的坑还是很容易踩到的,下面总结下几种解决这个问题的姿势。
问题根源
先上一段日常我们的使用姿势(本文以NSTimer为例,CADisplayLink同理):
Target.m
@property (nonatomic, strong) NSTimer *timer;
...
_timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(printNum:) userInfo:nil repeats:YES];
...
- (void)dealloc {
[_timer invalidate];
}
在使用诸如:
+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo;
+ (CADisplayLink *)displayLinkWithTarget:(id)target selector:(SEL)sel
这些API时,NSTimer
出于设计考虑会强引用target,同时NSRunLoop
又会持有持有NSTimer
,使用方同时又持有了NSTimer
,这就造成了强引用循环:
误区
那就把NSTimer
申明为weak吧 :)
Target.m
...
@property (nonatomic, weak) NSTimer *timer;
Retain_Cycle2.jpg
看起来没问题,但是Target的释放依赖了NSTimer的释放,然而NSTimer的释放操作在Target的-delloc中,这是一个鸡生蛋还是蛋生鸡的问题,依然会造成内存泄露。
- (void)dealloc {
[_timer invalidate];
}
那换个思路能不能让NSTimer弱引用Target,我们在防止Block的引用循环的措施中不是有这么一条么:
__typeof(&*self) __weak weakSelf = self;
那么能不能这么写:
__typeof(&*self) __weak weakSelf = self;
_timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target: weakSelf selector:@selector(printNum:) userInfo:nil repeats:YES];
Naive,这样子NSTimer仍然会强引用Target,NSTimer内部不出意外是声明一个__Strong的指针的,不管你在这个接口中传递什么类型指针,最终都会持有。
自定义Category用Block解决
网上有一些封装的比较好的block的解决方案,思路无外乎是封装一个NSTimer的Category,提供block形式的接口:
NSTimer+AZ_Helper.h
+ (NSTimer *)AZ_scheduledTimerWithTimeInterval:(NSTimeInterval)inTimeInterval block:(void (^)())inBlock repeats:(BOOL)inRepeats;
NSTimer+AZ_Helper.m
+ (NSTimer *)AZ_scheduledTimerWithTimeInterval:(NSTimeInterval)inTimeInterval block:(void (^)())inBlock repeats:(BOOL)inRepeats
{
void (^block)() = [inBlock copy];
NSTimer * timer = [self scheduledTimerWithTimeInterval:inTimeInterval target:self selector:@selector(__executeTimerBlock:) userInfo:block repeats:inRepeats];
return timer;
}
+ (void)__executeTimerBlock:(NSTimer *)inTimer;
{
if([inTimer userInfo])
{
void (^block)() = (void (^)())[inTimer userInfo];
block();
}
}
使用者只需注意block中避免强引用循环就好了,这种方案已经是比较简洁的解决方案。但是也不是没有缺点,使用者不用使用原生的API了,同时要为NSTimer何CADisplayLink分别引进一个Category。
GCD自己实现Timer
直接用GCD自己实现一个定时器,YYKit直接有一个现成的类YYTimer
这里不再赘述。
缺点:代价有点大,需要自己重新造一个定时器。
代理Proxy
NSProxy大家在日常开发中使用较少,其实就是一个代理中间人,可以代理其他的类/对象,用在这里很合适。先贴一张示意图:
Weak_Proxy.jpg完美解决强引用循环问题。下面是部分代码:
WeakProxy.h
...
@property (nullable, nonatomic, weak, readonly) id target;
...
WeakProxy.m
...
- (instancetype)initWithTarget:(id)target {
_target = target;
return self;
}
+ (instancetype)proxyWithTarget:(id)target {
return [[JYWeakProxy alloc] initWithTarget:target];
}
- (id)forwardingTargetForSelector:(SEL)selector {
return _target;
}
...
使用的时候只需要把self
替换成[WeakProxy proxyWithTarget:self]
_timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:[WeakProxy proxyWithTarget:self] selector:@selector(printNum:) userInfo:nil repeats:YES];
结语
笔者比较推荐WeakProxy的方式,代价很小,而且WeakProxy的功能只是一个纯的代理,没有和NSTimer
和CADisplayLink
耦合,还可以用在其他地方;使用上对原有代码的入侵也很小,原生的API依然正常使用。代码放在了GitHub上。
网友评论