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;
看起来没问题，但是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大家在日常开发中使用较少，其实就是一个代理中间人，可以代理其他的类/对象，用在这里很合适。先贴一张示意图：
完美解决强引用循环问题。下面是部分代码：
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上。