一个extension让你在Swift中用NSTimer更少操心

发表于 | 分类于
NSTimer有坑，坑在哪里？它会持有target的引用计数，不出意外的话你的target还会持有它的引用计数。另外，还会被runloop持有它的引用计数。

正文

NSTimer有坑，坑在哪里？

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
public typealias TimerExcuteClosure = @convention(block)()->()
extension NSTimer{
    public class func YQ_scheduledTimerWithTimeInterval(ti:NSTimeInterval, closure:TimerExcuteClosure, repeats yesOrNo: Bool) -> NSTimer{
      return self.scheduledTimerWithTimeInterval(ti, target: self, selector: "excuteTimerClosure:", userInfo: unsafeBitCast(closure, AnyObject.self), repeats: true)
    }

    class func excuteTimerClosure(timer: NSTimer)
    {
        let closure = unsafeBitCast(timer.userInfo, TimerExcuteClosure.self)
        closure()
    }
}

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

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

转载自http://www.jianshu.com/p/7e3610367b91