Crash拦截器 - NSTimer无法释放和内存泄漏之解除
前言
在iOS开发中，我们使用定时器(timer)的几率很高，系统中最常用的方式有GCD中提供的timer接口和我们今天要讨论的NSTimer。关于GCD相关的接口，我们今天不讨论，我们接下来看看NSTimer.
对于NSTimer，我们都知道这家伙最让人深恶痛绝的，肯定就是它容易引起循环引用，造成内存泄漏，甚至在执行定时任务的时候导致crash。
我们接下将会分析NSTimer是如何引起循环引用，并给出几种方案来破开这种循环引用状态。
NSTimer造成内存泄漏的原因
我们查看scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:和timerWithTimeInterval:target:selector:userInfo:repeats:的接口文档，可以看到对target的有这样的一句解释：
The timer maintains a strong reference to target until it (the timer) is invalidated.
哦豁！NSTimer会对target进行强持有，如果这个时候作为target的对象(例如我们最常见的情况：UIViewController)强持有NSTimer，这就引起了循环引用。
既然引起了循环引用，那么在破开这个引用环之前，NSTimer和target都无法被释放，这就很合理了。
既然这样，我们就破开引用环。我们在必要的时候在target中将NSTimer置为nil。这样是否就可以释放NSTimer了呢？答案是：不行。有兴趣的同学可以试试，在NSTimer的selector中加一条打印，我们会发现这该死的打印根本不会自己停，直到你因为再也不想看到它而关掉调试为止。
在我们心态爆炸，一脸懵逼的时候，我们再看看官方文档对NSTimer的一段介绍：
Timers work in conjunction with run loops. Run loops maintain strong references to their timers, so you don’t have to maintain your own strong reference to a timer after you have added it to a run loop.
这段话提到了一个关键点：在我们将NSTimer加入到RunLoop中之后，RunLoop就会维持对NSTimer的强引用。这也是不管我们是否在控制器中对NSTimer进行强引用，在我们没有将NSTimer进行invalidate之前，NSTimer都无法被释放的原因了。
说到invalidate，我们看看官方文档对这个方法的介绍：
Stops the timer from ever firing again and requests its removal from its run loop.
我们可以看到invalidate方法做了两个事情：1.停止了NSTimer的定时事件。2.将NSTimer从RunLoop中移除。
看到这里是否是恍然大悟，原来NSTimer得已被释放，最大的功臣是invalidate方法，如果没有它，我们想从RunLoop中移除NSTimer可就是个麻烦的事了。
所以如果要释放NSTimer，我么必须做到两件事：1.打破NSTimer和target的引用环。2.将NSTimer从RunLoop中移除，即调用NSTimer的invalidate方法。
NSTimer循环引用的解决方案
对于调用NSTimer的invalidate方法的必要性，默默告诫自己要加强注意之后，我们暂且不多做讨论了。我们回到循环引用的问题，下面给出几个解决方案：
- 手动释放
NSTimer - 调用苹果系统API(iOS10以后支持)
- 使用
block解决循环引用 - 使用中间件
NSProxy解决循环引用
瞅准时机手动释放NSTimer
以UIViewController持有NSTimer为例，这里不管是强持有还是弱持有，都有RunLoop强持有NSTimer，NSTimer强持有UIViewController，这会导致UIViewController不能自己释放。所以我们必须瞅准机会手动调用invalidate方法，将NSTimer释放掉。而这个时机嘛，具体的业务代码具体处理吧（手动阴险）。
下面给出一种最傻瓜式的处理方式：
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTimer) userInfo:nil repeats:YES];
}
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.timer invalidate];
self.timer = nil;
}
我想，嗯，这种方式真的很难满足我们各种复杂的业务场景，只能在最基本的情况下使用。这里列举出来，只是给出一种打破引用的方式（而已）。
调用苹果系统API(iOS10以后支持)
也许是苹果公司对NSTimer的这种无法释放的问题再也看不过眼了，也许是某个苹果工程师在写代码的时候，是在是不想忍受这种心惊胆战的编码模式了。总之，在iOS10.0以后，NSTimer类多了如下的两个接口：
+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block;
+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block;
我们可以看到，这两个接口不用传target和selector。这不就意味着NSTimer不会强持有target，这循环引用的问题不就在还没开始就被扼杀了嘛！
不过可惜的是，到iOS10才支持，目前我所处的项目都要支持到iOS9，这真是一个悲伤的故事(手动哭唧唧)。
类对象持有 -> 使用block解决循环引用
我们创建一个分类，代码如下：
@interface NSTimer (NoRetainCycleWithBlock)
+ (NSTimer *)nrc_timerWithTimeInterval:(NSTimeInterval)ti repeats:(BOOL)repeats block:(dispatch_block_t)block;
+ (NSTimer *)nrc_scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(dispatch_block_t)block;
@end
@implementation NSTimer (NoRetainCycleWithBlock)
+ (NSTimer *)nrc_timerWithTimeInterval:(NSTimeInterval)ti repeats:(BOOL)repeats block:(dispatch_block_t)block {
return [self timerWithTimeInterval:ti target:self selector:@selector(nrc_blockHandler:) userInfo:[block copy] repeats:repeats];
}
+ (NSTimer *)nrc_scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(dispatch_block_t)block {
return [self scheduledTimerWithTimeInterval:interval
target:self
selector:@selector(nrc_blockHandler:)
userInfo:[block copy]
repeats:repeats];
}
+ (void)nrc_blockHandler:(NSTimer *)timer {
dispatch_block_t block = timer.userInfo;
if (block) {
block();
}
}
@end
我们为NSTimer添加了两个方法，以供开发者来创建NSTimer。通过这两个方法创建NSTimer的关键点如下：
-
NSTimer的定时任务会以block的形式进行回调。 -
NSTimer的target传入self，这里的上下文环境是在类方法中，所以这里的self是NSTimer的类对象。即NSTimer会持有NSTimer的类对象(也就是NSTimer.class)。 -
NSTimer的userInfo传入了block的copy，保证block存在堆中。并且由于被NSTimer持有，所以不会被释放。 -
NSTimer的selector传入了方法nrc_blockHandler:，该方法中获取了timer.userInfo，然后执行block回调定时任务。
上面的代码获得了什么成果呢？
NSTimer的target换成了NSTimer的类对象，而类对象一直存在于内存中，所以即便是循环引用了，造成的影响也不是很大。
但是我们需要注意一点是，当UIViewController(即创建timer的地方)被释放而NSTimer未被释放时，定时任务执行block，此时有可能会造成访问野指针引起的崩溃问题。
所以，敲黑板啦！在UIViewController的dealloc中一定要记得调用invalidate方法释放NSTimer，以避免我们最最不想看到的崩溃！！！
消息转发 -> 使用中间件NSProxy
同样的，我们可以使用一个中间件，使NSTimer强引用中间件，而中间件弱引用UIViewController，从而打破引用环。
对于中间件，我们选用比NSObject更为轻量级的NSProxy。
中间件的实现代码如下：
@interface ORCWeakProxy : NSProxy
@property (nonatomic, readonly, weak) id target;
- (instancetype)initWithTarget:(id)target;
+ (instancetype)proxyWithTarget:(id)target;
@end
@implementation ORCWeakProxy
- (instancetype)initWithTarget:(id)target {
_target = target;
return self;
}
+ (instancetype)proxyWithTarget:(id)target {
return [[self.class alloc] initWithTarget:target];
}
- (BOOL)respondsToSelector:(SEL)aSelector {
return [self.target respondsToSelector:aSelector];
}
// 转发目标选择器
- (id)forwardingTargetForSelector:(SEL)selector {
return self.target;
}
// 函数执行器
- (void)forwardInvocation:(NSInvocation *)invocation {
void *null = NULL;
[invocation setReturnValue:&null];
}
// 方法签名的选择器
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
return [NSObject instanceMethodSignatureForSelector:@selector(init)];
}
@end
使用时的代码如下：
ORCWeakProxy *proxy = [ORCWeakProxy proxyWithTarget:aTarget];
self.timer = [NSTimer scheduledTimerWithTimeInterval:ti
target:proxy
selector:aSelector
userInfo:nil
repeats:YES];
中间件的加入，使得NSTimer的target成为中间件，而中间件对UIViewController是弱引用，所以UIViewController可以被释放。
因为NSTimer的target成为中间件，所以NSTimer在执行定时任务时，会调用中间件的selector方法，然而中间件肯定是没有这个selector方法的，所以我们需要在中间件中进行方法的转发。我们使用forwardingTargetForSelector:使得响应selector方法的对象转移为self.target，即UIViewController。
既然方法已经被转发了，后续的消息转发接口就不会被执行了，那么我们还有必要重写methodSignatureForSelector:和forwardInvocation:吗？
答案是：很有必要！。因为，当UIViewController被释放之后，就会出现在target上找不到selector，如果不重写，那么恭喜你，崩溃等着你(手动坏笑)！不过这两个方法只要实现，随便写写就行，只要有，其它都不要求。
不过使用这种方式，有以下几点需要注意：
-
NSProxy是一个虚类，所以我们无法直接使用，而是创建一个该类的子类。 - 重要的事情又来了，在
UIViewController的dealloc方法中，记得加上[self.timer invalidate]，谢谢(手动微笑)！如果不手动释放NSTimer，NSTimer依旧会持续执行定时任务，虽然你看不到，但它就在那里执行。有兴趣的小伙伴可以在中间件的forwardInvocation:打个断点试试。
中间件解决NSTimer的循环引用问题的目的已经达到了。但是在每个使用的地方，都需要引入ORCWeakProxy的头文件，这让我用起来有点不乐意啊！所以我们又添加一个NSTimer分类，代码如下：
@interface NSTimer (NoRetainCycleWithProxy)
@end
@implementation NSTimer (NoRetainCycleWithProxy)
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self orc_exchangeSelector:@selector(scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:)
toSelector:@selector(orc_scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:)];
[self orc_exchangeSelector:@selector(timerWithTimeInterval:target:selector:userInfo:repeats:)
toSelector:@selector(orc_timerWithTimeInterval:target:selector:userInfo:repeats:)];
});
}
+ (NSTimer *)orc_timerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo {
return [self orc_timerWithTimeInterval:ti
target:[ORCWeakProxy proxyWithTarget:aTarget]
selector:aSelector
userInfo:userInfo
repeats:yesOrNo];
}
+ (NSTimer *)orc_scheduledTimerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo {
return [self orc_scheduledTimerWithTimeInterval:ti
target:[ORCWeakProxy proxyWithTarget:aTarget]
selector:aSelector
userInfo:userInfo
repeats:yesOrNo];
}
@end
我们在分类里交换了创建NSTimer的方法，在新的方法里来创建NSTimer，并将中间件作为target传给这个NSTimer。这样，我们就可以无感知的使用中间件来解决NSTimer的循环引用问题了(nice)！
其实写到这里，关于消息转发 -> 使用中间件NSProxy来处理NSTimer的循环引用问题，就已经写完了。但是说实话，总是被提醒：要我们手动释放NSTimer，否则就会造成内存泄漏！这让我怎么的都不是很爽。秉着如果觉得不爽，那就要让自己爽起来的态度，我又在中间件中加了一些小东西：
- 为
ORCWeakProxy添加属性timer。 - 在
forwardingTargetForSelector:对target进行判断，如果target为nil则认为target已经被释放，这个时候就释放timer。
代码片段如下：
@interface ORCWeakProxy : NSProxy
@property (nonatomic, readonly, weak) id target;
@property (nonatomic, weak) id timer;
- (instancetype)initWithTarget:(id)target;
+ (instancetype)proxyWithTarget:(id)target;
@end
- (id)forwardingTargetForSelector:(SEL)selector {
// 如果发现target为nil后，就停掉timer
if (self.target == nil) {
[self.timer invalidate];
}
return self.target;
}
-
timer属性使用weak修饰，避免出现循环引用问题。 -
target为nil后，调用invalidate方法释放timer，那么就不需要再在考虑UIViewController被释放，而NSTimer没被释放的问题了(手动开心)。
以上，我们在使用NSTimer时，只需要调用接口创建NSTimer对象，并使用它满足我们的各种需求，而不再需要去关心，它会不会在满足我们的需求之后，对我们造成什么不好的影响了。
