NSTimer有坑，坑在哪里？

它会持有target的引用计数，不出意外的话你的target还会持有它的引用计数。另外，还会被runloop持有它的引用计数。

是不是感觉特别混乱？往往在这种情况下我们也容易出现循环引用的错误，会导致该释放的资源没有办法被正确释放。

举个例子，通常我们的应用场景是我们的ViewController持有这个timer，想让它定时唤起某个操作。这里首先ViewController持有了timer的引用计数，然后timer又会持有ViewController，那么循环引用就产生了。可能有些同学会在deinit中写上timer.invalidate()，然而由于循环引用的原因，根本就进不了这儿。

好吧，可能有的同学会想些其他的方法来让timer失效。通常做法的要么增加复杂程度要么破坏了封装，所以不见得是个好的做法。

于是，我�把之前在OC中的做法（当然方法来源于大神Matt Galloway）翻译成了swift的版本，直接上代码吧：

public typealias TimerExcuteClosure = @convention(block) () -> ()

extension Timer {
    private class TimerActionBlockWrapper : NSObject {
        var block : TimerExcuteClosure
        init(block: @escaping TimerExcuteClosure) {
            self.block = block
        }
    }

    public class func YQ_scheduledTimerWithTimeInterval(_ ti:TimeInterval, closure: @escaping TimerExcuteClosure, repeats yesOrNo: Bool) -> Timer {
        return self.scheduledTimer(timeInterval: ti, target: self, selector: #selector(Timer.excuteTimerClosure(_:)), userInfo: TimerActionBlockWrapper(block: closure), repeats: true)
    }
    
    @objc private class func excuteTimerClosure(_ timer: Timer) {
        if let action = timer.userInfo as? TimerActionBlockWrapper {
            action.block()
        }
    }
}

这里把想要执行的操作放到了一个闭包里，然后把它设为userInfo。比较关键的地方在于这里的target是NSTimer自己了，这里防止了它去持有外部调用者的引用计数，比如我们的ViewController。切断了之前的联系之后，deinit就能正常调用了，也能正常调用timer.invalidate()了，timer失效的时候也会释放它对target的引用，从而能够正确的释放资源。

这里有一点需要注意的是，NSTimer的userInfo的类型是AnyObject，这意味这你不能直接把closure传给它，需要用unsafeBitCast来转一下。当然既然苹果说了这个东西是unsafe的，那么自然有它的道理，用的时候需要小心。