iOS-NSTimer

NSTimer是iOS常见定时器。它经过特定时间间隔就会触发，将指定的消息发送到目标对象。定时器是线程通知自己做某件事的方法，定时器和runLoop的特定的模式相关。如果定时器所在的模式当前未被runLoop监视，那么定时器将不会开始，直到runLoop运行在相应的模式下。如果runLoop停止运行，那定时器也会停止动。

NSTimer会对外界传递的target进行强持有。如果只使用一次，会在本次使用之后自身销毁invalidate，并且会对NSTimer的那个target进行release操作。如果是多次重复调用，就需要我们自己手动进行invalidate，否则NSTimer会一直存在。

NSTimer在那个线程创建就要在那个线程停止，否则资源不能正确的释放。

NSTimer的API

按照是否需要手动将timer放入定时器，我们可以把NSTimer的方法分为两种：

1. 需要手动加入runLoop：

+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)ti invocation:(NSInvocation *)invocation repeats:(BOOL)yesOrNo;
+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo;
+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block;
- (instancetype)initWithFireDate:(NSDate *)date interval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block;
- (instancetype)initWithFireDate:(NSDate *)date interval:(NSTimeInterval)ti target:(id)t selector:(SEL)s userInfo:(nullable id)ui repeats:(BOOL)rep;

上述几个方法需要将timer放到runLoop才能执行：

- (void)addTimer:(NSTimer *)timer forMode:(NSRunLoopMode)mode;

2. 不需要手动放入runLoop：

+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti invocation:(NSInvocation *)invocation repeats:(BOOL)yesOrNo;
+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo;
+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block；

NSTimer精准度问题

NSTimer不是一个高精度的定时器，这是因为NSTimer是依赖于runloop，如果它当前所处的线程正在进行大数据处理，NSTimer的执行就会等到这个大数据处理完之后。等待的过程可能会错过很多次NSTimer的循环周期，但是NSTimer并不会将前面错过的执行次数在后面都执行一遍，而是继续执行后面的循环。而且无论循环延迟多久，循环间隔都不会发生变化。

在有UIScrollView或者其子类的控制器中使用NSTimer，需要注意scrollView的滑动操作会影响到NSTimer。因为scrollView在滑动的时候会将runloop的模式从NSDefaultRunLoopMode切换到UITrackingRunLoopMode，这是NSTimer就不会进行回调了。此时需要调用如下方法：

[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes]；

将NSTimer的将runloop的模式切换到NSRunLoopCommonModes，这样才不会对其进行影响。

NSTimer注意事项

使用多次循环的NSTimer一定要进行销毁动作，否则会导致内存泄露问题。销毁的方法如下：

- (void)invalidate

target
The object to which to send the message specified by aSelector when the timer fires. The timer maintains a strong reference to this object until it (the timer) is invalidated.
This method is the only way to remove a timer from an NSRunLoop object. The NSRunLoop object removes its strong reference to the timer, either just before the invalidate method returns or at some later point.

从官方给出的文档可以看出，timer对传入的target是强引用，而invalidate则是从runLoop对象删除计时器的唯一方法，如果我们我们不调用该方法，就对导致这个强引用对象释放不掉，从而出现内存问题。需要特别注意的是，必须在设置计时器的线程调用该方法，如果从别的线程调用该方法，可能并不会从runLoop删除timer，会导致线程的异常。

下面我们看一个例子，我们从A控制器push到B控制器，并在B控制器实现以下代码：

@property (nonatomic, strong) NSTimer *timer;
@property (nonatomic, assign) int num;

- (void)fireTimer {
    self.timer = [NSTimer timerWithTimeInterval:1 target:self selector:@selector(timerAction) userInfo:nil repeats:YES];
    [[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSDefaultRunLoopMode];
}

- (void)timerAction {
    num++;
    NSLog(@"==%d==",num);
}

运行程序，先从A控制器进入B控制器，然后再返回。我们可以发现，控制台依然在输出，timer并没有被停止。这就是因为self本身对timer持有，而timer也强引用了self，而我们没有调用invalidate来打破这个循环引用，timer无法被释放销毁。

我们知道block可以使用weakSelf打破循环引用，那么此处我们将传入的self改为weakSelf是否可以呢？

__weak typeof(self) weakSelf = self;

运行程序，可以发现，timer依然没有被释放销毁。在控制台调试一下self和weakSelf，

lldb) po self
0x7fa5b7c10770

(lldb) po weakSelf
0x7fa5b7c10770

(lldb) po &self
0x0000000103d70fc8

(lldb) po &weakSelf
0x00007ffeee377f68

可以得出，self和weakSelf其实是指向同一快空间的不同指针。timer对weakSelf的强持有是对weakSelf这个对象的持有，其实也就是对self的持有，而block对外界对象的持有是对指针地址的持有，而weakSelf的指针和self的指针并不相同，所以block使用weakSelf可以打破循环引用，而timer不能。

关于block的分析可以参考block(二)-底层分析。

打破timer对self强持有的方法有以下几种

• 1. 在dealloc中调用invalidate方法，此方法有个缺陷就是如果控制器其他地方内存逻辑出现问题，可能会不走dealloc方法。

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

• 2. 在didMoveToParentViewController中调用invalidate

- (void)didMoveToParentViewController:(UIViewController *)parent{
    if (parent == nil) {
       [self.timer invalidate];
        self.timer = nil;
    }
}

• 3. 使用一个中间层打破timer和target之间的强引用。将timer的响应方法交给中间层，而中间层处理不了，再通过消息转发告诉target来进行处理。此方法还是需要使用invalidate。

@interface TProxy : NSProxy
+ (instancetype)proxyWithTransformObject:(id)object;
@end

@interface TProxy()
@property (nonatomic, weak) id object;
@end

@implementation TProxy
+ (instancetype)proxyWithTransformObject:(id)object{
    TProxy *proxy = [TProxy alloc];
    proxy.object = object;
    return proxy;
}

// 仅仅添加了weak类型的属性还不够
// 为了保证中间件能够响应外部self的事件，需要通过消息转发机制，
// 让实际的响应target还是外部self，这一步至关重要，主要涉及到runtime的消息机制。
// 转移
-(id)forwardingTargetForSelector:(SEL)aSelector {
    return self.object;
}

// VC
- (void)proxyTimer {
    TProxy *proxy = [TProxy proxyWithTransformObject:self];
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:proxy selector:@selector(timerAction) userInfo:nil repeats:YES];
}

使用NSProxy的时候，官方给出的文档是继承自NSProxy的类，可以直接实现methodSignatureForSelector和forwardInvocation来处理自身未实现的消息。这样会比直接走消息转发流程快一些。

// NSProxy已经实现，性能更高
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [self.object methodSignatureForSelector:sel];
}

- (void)forwardInvocation:(NSInvocation *)invocation {
    [invocation invokeWithTarget:self.object];
}

总结

• 由于NSTimer依赖于runloop，其精度不高
• 使用NSTimer需要注意是其中有些方法需要我们手动添加到runloop才能执行。
• 使用NSTimer必须要调用invalidate，否则会出现内存问题。