NSTimer所隐藏的内存泄漏问题

日常的编码工作中，经常会碰到某些需要定期或延时执行的操作，这个时候会有多种计时方法供我们使用，比如NSTimer、CADisplayLink、GCD等。前两种方式在使用中都可能会出现循环引用而导致内存泄漏问题。

what

我们先来看一下，NSTimer所隐藏的内存泄漏问题是什么样子的，通常，在push出来的viewController中我们是这样做的：

@interface MainViewController ()
@property (nonatomic, strong) UIButton *fireButton;
@property (nonatomic, strong) UIButton *invalidateButton;
@property (nonatomic, strong) NSTimer *timer;
@end

@implementation MainViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view.
    ...
}

- (void)fire {
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timeStart) userInfo:nil repeats:YES];
}

- (void)invalidate {
    [self.timer invalidate];
}

- (void)timeStart {
    NSLog(@"timeStart");
}

- (void)dealloc {
    [self.timer invalidate];
}

就这样，一个坑被我们在不知不觉中挖好了。我们希望当viewController将要释放的时候，在dealloc方法中去将NSTimer对象给停掉释放。结果往往是不尽人意的，控制台在viewController弹栈后仍然不停的打印“timeStart”。

why

知道了这种隐藏的内存问题是什么，那我么接下来看一下为什么这种情况下会产生循环引用。

[NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timeStart) userInfo:nil repeats:YES];

在这个方法中，如果repeats传入的参数是YES，那么NSTimer对象会保留target传入的对象，也就是强持有它，这种情形会保持到NSTimer对象失效为止。如果是一次性的定时器，不需要手动去invalidate就会失效，但是重复性的定时器，需要主动去调用invalidate方法才会失效。

综上看来，viewController强持有了NSTimer对象，而NSTimer对象在其[NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timeStart) userInfo:nil repeats:YES];方法中对传入的target参数也进行了强引用，这也保证了NSTimer对象调用时的正确性。此时如果传入target的是self，那么就会形成viewController和NSTimer对象的循环引用环，如果循环引用环没有被打破，那么viewController在弹栈的时候就不会被释放，也就不会走dealloc方法，也就不会将NSTimer对象invalidate，这个时候viewController和NSTimer对象都得不到释放，也就产生了内存泄漏。

how

如何才能解决这种内存泄漏问题呢，关键在于破掉viewController和NSTimer对象的循环引用环。此时可能会有两种思路：
　　1、viewController弱引用NSTimer对象
　　2、NSTimer对象弱引用传入target的self对象

第一种方案

我们首先采用第一种方法@property (nonatomic, weak) NSTimer *timer;，运行程序后发现在viewController弹栈后依然在打印“timeStart”，这是因为NSTimer对象被创建后会被加入到RunLoop中，会被RunLoop强持有，这种思路是不能解决问题的。

第二种方案

在第二种方法中,我们做如下处理

__weak typeof(self) weakSelf = self;
[NSTimer scheduledTimerWithTimeInterval:1.0 target: weakSelf selector:@selector(timeStart) userInfo:nil repeats:YES];

运行程序，viewController弹栈后我们依然发现控制台在打印“timeStart”，是不是要疯了？冷静下来，仔细想想，其实__weak typeof(self) weakSelf = self只是帮我们创建了一个新的变量weakSelf，而weakSelf这个变量所指向的对象和self是一致的，那么我们所做的这些事没有任何意义的，NSTimer对象持有的仍然是viewController的当前对象，不论你传入的是self或者weakSelf！
上面在分析原因的时候说到，NSTimer对象会保留target传入的对象，也就是强持有它，这种情形会保持到NSTimer对象失效为止。那么我们主动去将NSTimer对象调用invalidate方法不就可以了吗，现在问题是这个调用invalidate的时机在哪最好呢，我们怎么知道什么时候才是NSTimer的最佳释放时机呢？其实不一定非得是最佳时机，利用viewController的生命周期方法也可以解决循环引用问题。在的viewController将要消失的时候，我们去invalidate定时器，在viewController创建后的恰当时机再次启动定时器不就可以解决这个问题了吗，代码如下：

- (void)viewWillDisappear:(BOOL)animated {
    [super viewWillDisappear:animated];
    if (self.timer.isValid) {
        [self.timer invalidate];
    }
}

问题又来了，生命周期方法并不是谁都有的，这并不是一个通用的解决办法。有没有一种方法能够一劳永逸的解决这个问题呢，我创建NSTimer后，不必去关心它什么时候需要释放，但又不会引起循环引用。有，上面用过的dealloc方法，任何一个对象被销毁之前都会调用这个对象的dealloc方法，但是我们要保证已经强引用了NSTimer对象的这个对象不被NSTimer对象强引用即可。
对了，我们似乎想到了一个类似的问题，为什么UIBUtton的target传入self，而没有被强引用导致出现循环引用问题呢？是不是其内部做了某些处理呢，那么又是如何处理的呢？不得不说Github是个好地方，在上面扒到一个第三方库Chameleon，它包含苹果用于iOS的UIKit以及一些用于MAC OS X的一些框架的接口实现，虽然已经在2014年停止更新维护了，但是仍然不失是一个学习利器。在里面看到了如下代码

- (void)addTarget:(id)target action:(SEL)action forControlEvents:(UIControlEvents)controlEvents {
    UIControlAction *controlAction = [[UIControlAction alloc] init];
    controlAction.target = target;
    controlAction.action = action;
    controlAction.controlEvents = controlEvents;
    [_registeredActions addObject:controlAction];
}

并且

@interface UIAction : NSObject
@property (nonatomic, weak) id target;
@property (nonatomic, assign) SEL action;
@end

也就是说，UIButton没有直接对target进行强引用，而是创建了一个的UIControlAction对象controlAction，并对它做了强引用。UIControlAction继承于UIAction，而UIAction也有一个target属性，并且是weak修饰的，这么看来，UIButton通过UIControlAction对象弱引用target对象，这样就避免了UIButton和target对象的循环引用。这对我们来说是一种启示，我们当然也可以用这种方法来解决NSTimer带来的循环引用问题。代码如下：

#import "DWTimer.h"

@interface DWTimerTarget : NSObject
@property (nonatomic, weak) id target;
@property (nonatomic, assign) SEL selector;
@property (nonatomic, weak) NSTimer* timer;
@end

@implementation DWTimerTarget

- (void) fire:(NSTimer *)timer {
    if(self.target) {
        [self.target performSelector:self.selector withObject:timer.userInfo afterDelay:0.0f];
    } else {
        [self.timer invalidate];
    }
}

@end

@implementation DWTimer

+ (NSTimer *) scheduledTimerWithTimeInterval:(NSTimeInterval)interval
                                      target:(id)aTarget
                                    selector:(SEL)aSelector
                                    userInfo:(id)userInfo
                                     repeats:(BOOL)repeats {
    DWTimerTarget* timerTarget = [[DWTimerTarget alloc] init];
    timerTarget.target = aTarget;
    timerTarget.selector = aSelector;
    timerTarget.timer = [NSTimer scheduledTimerWithTimeInterval:interval
                                                         target:timerTarget
                                                       selector:@selector(fire:)
                                                       userInfo:userInfo
                                                        repeats:repeats];
    return timerTarget.timer;
}

@end

如此，基本实现了我们的目标：通过弱引用传入的target对象，彻底解决了NSTImer所隐藏的内存泄漏问题。CADisplayLink和NSTimer的问题基本一致，就不再赘述，也可以利用上述方法解决问题。

后续优化方案

文章写了这么长时间后回头再看，发现还有一种更好的方案，记录如下。

给NSTimer增加一个分类，提供一个Block方法，这样我们在使用Block时就可以像使用普通block那样去处理循环引用问题了。

// NSTimer+Block.h
@interface NSTimer (Block)
+ (NSTimer *)dw_scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block;
@end
    
// NSTimer+Block.m
+ (NSTimer *)dw_scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer * _Nonnull))block {
    return [NSTimer scheduledTimerWithTimeInterval:interval target:self selector:@selector(callback:) userInfo:[block copy] repeats:YES];
}

+ (void)callback:(NSTimer *)timer {
    void(^block)(NSTimer *) = timer.userInfo;
    block(timer);
}

这样在合适的时机（比如dealloc方法中执行invalidate方法）关闭timer即可。