iOS Timer 的循环引用问题

Timer 的循环引用

在使用 Timer 时，如果直接引用 self，会导致循环引用。示例代码：

class TimerExample {

    var timer: Timer?

    init() {
        // Timer
        // timer = Timer.scheduledTimer(timeInterval: 1.0, target: self, selector: #selector(observeTimeLine), userInfo: nil, repeats: true)

        // 创建一个 Timer，并直接捕获 self
        timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
            self.timerFired()
        }
    }

    func timerFired() {
        print("Timer fired")
    }

    deinit {
        timer?.invalidate()
        print("TimerExample deinitialized")
    }
}

Timer 对目标对象（如 self）有一个强引用；
如果 self 对 timer 也有强引用，则形成循环引用，导致对象无法正常释放。

即使在 deinit 中这样写，试图手动销毁 timer，也是无效的。因为deinit根本不被调用！

deinit {
    timer?.invalidate()
    print("TimerExample deinitialized")
}

需要在销毁TimerExample实例前，手动调用timer?.invalidate()才行，不然因为实例被强持有不会触发deinit。

为什么 weak 修饰无效？

在某些场景下，开发者可能尝试用 weak 修饰 timer，以为可以解决循环引用问题：

class TimerExample {

    weak var timer: Timer?  // 尝试用 weak 修饰

    init() {
        // Timer
        // timer = Timer.scheduledTimer(timeInterval: 1.0, target: self, selector: #selector(observeTimeLine), userInfo: nil, repeats: true)

        timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
            self.timerFired()
        }
    }

    func timerFired() {
        print("Timer fired")
    }

    deinit {
        timer?.invalidate()
        print("TimerExample deinitialized")
    }
}

这种情况下，weak 并不起作用，原因如下：

1. Timer 被 RunLoop 强引用：

   • 当 Timer 被注册到 RunLoop 后，RunLoop 会对 Timer 保持一个强引用。
   • 即使 self.timer 是 weak，RunLoop 中的强引用仍然会让 Timer 存在，无法自动释放。

2. self 闭包引用：

   • 即使 timer 是 weak，Timer 的闭包仍然捕获了 self 的强引用。
   • 这种隐式的强引用使得对象无法释放，导致循环引用。

对于Timer.scheduledTimer 的 Handler 方式，[weak self] 可解循环引用

正确的做法是在 Timer 的闭包中使用 [weak self]，避免直接引用 self，从而解决循环引用问题：

class TimerExample {
    var timer: Timer?

    init() {
        timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { [weak self] _ in
            self?.timerFired()
        }
    }

    func timerFired() {
        print("Timer fired")
    }

    deinit {
        timer?.invalidate()
        print("TimerExample deinitialized")
    }
}

闭包会捕获 self 的弱引用；
当 self 被释放时，闭包中的 self 自动为 nil，避免了循环引用问题。

总结

• 直接使用 Timer 时，RunLoop 的强引用使得 weak 修饰的 timer 无法释放。
• 解决循环引用的关键：在 Timer 的闭包中捕获 self 的弱引用，或使用其他方法（如 Proxy 或 DispatchSourceTimer）避免强引用问题。

使用 Proxy 解决循环引用

核心思想：通过引入一个中间对象（Proxy），Proxy 弱引用目标对象（self），从而避免 Timer 强引用 self。

// Proxy 类：
class TimerProxy {
    weak var target: AnyObject?

    init(target: AnyObject) {
        self.target = target
    }

    @objc func timerFired(_ timer: Timer) {
        (target as? TimerHandling)?.timerFired()
    }
}

protocol TimerHandling: AnyObject {
    func timerFired()
}


// 使用 Proxy 的类：
class TimerExample: TimerHandling {
    private var timer: Timer?

    init() {
        let proxy = TimerProxy(target: self)
        timer = Timer.scheduledTimer(timeInterval: 1.0,
                                     target: proxy,
                                     selector: #selector(TimerProxy.timerFired(_:)),
                                     userInfo: nil,
                                     repeats: true)
    }

    func timerFired() {
        print("Timer fired")
    }

    deinit {
        timer?.invalidate()
        print("TimerExample deinitialized")
    }
}

Timer 持有 TimerProxy 的强引用，Proxy 弱引用 self。
当 TimerExample 被销毁时，TimerProxy 的弱引用变为 nil，不会引发循环引用。

使用 DispatchSourceTimer

核心思想：DispatchSourceTimer 不会被 RunLoop 持有，且可以灵活管理生命周期，通过捕获 self 的弱引用避免循环引用。

class TimerExample {
    private var timer: DispatchSourceTimer?

    init() {
        // 创建一个 GCD 定时器
        timer = DispatchSource.makeTimerSource(queue: DispatchQueue.global())
        timer?.schedule(deadline: .now(), repeating: 1.0) // 设置定时间隔
        
        // 使用 [weak self] 避免循环引用
        timer?.setEventHandler { [weak self] in
            self?.timerFired()
        }
        
        timer?.resume() // 开始定时器
    }

    func timerFired() {
        print("Timer fired")
    }

    deinit {
        timer?.cancel() // 停止定时器
        print("TimerExample deinitialized")
    }
}

DispatchSourceTimer 通过 DispatchQueue 管理，避免了 RunLoop 持有的问题。
self 被弱引用，销毁时不会造成循环引用。

区别对比

选择建议：

1. 如果需要频繁更新 UI（如主线程计时器），使用 Proxy 更贴近 UIKit 风格。
2. 如果是后台定时任务或性能优先场景，优先选择 DispatchSourceTimer。