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的,那么自然有它的道理,用的时候需要小心。