正文
NSTimer有坑，坑在哪里？
它会持有target的引用计数，不出意外的话你的target还会持有它的引用计数。另外，还会被runloop持有它的引用计数。
是不是感觉特别混乱？往往在这种情况下我们也容易出现循环引用的错误，会导致该释放的资源没有办法被正确释放。
举个例子，通常我们的应用场景是我们的ViewController持有这个timer，想让它定时唤起某个操作。
这里首先ViewController持有了timer的引用计数，然后timer又会持有ViewController，那么循环引用就产生了。
可能有些同学会在deinit中写上timer.invalidate()，然而由于循环引用的原因，根本就进不了这儿。
好吧，可能有的同学会想些其他的方法来让timer失效。通常做法的要么增加复杂程度要么破坏了封装，所以不见得是个好的做法。
于是，我把之前在OC中的做法（当然方法来源于大神Matt Galloway）翻译成了swift的版本，直接上代码吧：
代码语言：javascript复制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
