Swift中如何实现变量变化的持续检测？替代定时器方案问询

当然可以实现变量变化的持续检测，而且完全不需要依赖定时器这种轮询方案——你遇到的精度不足和卡顿问题，本质上就是因为定时器是被动轮询，而我们需要的是主动事件触发的机制。下面给你几个适配不同场景的解决方案，包括你提到的“等待过程中触发中断”的需求：

一、属性观察器：最简单的自定义属性检测 #

如果你要检测的是自己定义的变量，属性观察器（didSet/willSet）是最直接的方案——变量一发生变化，就会立刻触发回调，完全没有延迟或卡顿问题，精度是即时的。

举个例子，检测一个Int类型变量的变化：

class VariableMonitor {
    var targetValue: Int = 0 {
        didSet {
            // 变量变化时立刻执行这里的逻辑
            print("targetValue 从 \(oldValue) 变为 \(targetValue)")
            // 如果需要中断某个等待任务，这里可以触发cancel信号
            interruptWaitingTask()
        }
    }
    
    // 模拟等待任务的中断逻辑
    private func interruptWaitingTask() {
        // 这里可以实现任务取消、信号量触发等逻辑
    }
}

这种方案的优势是轻量、无额外性能开销，完全基于语言特性实现，适合你能控制变量定义的场景。

二、KVO：检测系统/第三方类的属性变化 #

如果你要观察的是系统框架类（比如UIView的frame、UIScrollView的contentOffset）或者你无法修改源码的第三方类属性，Key-Value Observing（KVO）是标准解决方案。它也是事件驱动的，不需要轮询。

举个例子，观察UIView的frame变化：

class ViewFrameObserver: NSObject {
    private let observedView: UIView
    
    init(view: UIView) {
        self.observedView = view
        super.init()
        // 添加观察者，指定要观察的属性
        observedView.addObserver(self, forKeyPath: "frame", options: [.old, .new], context: nil)
    }
    
    // KVO回调方法
    override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {
        guard keyPath == "frame", let change = change else { return }
        let oldFrame = change[.oldKey] as? CGRect ?? .zero
        let newFrame = change[.newKey] as? CGRect ?? .zero
        print("View frame 从 \(oldFrame) 变为 \(newFrame)")
        // 在这里触发等待任务的中断
        interruptWaitingTask()
    }
    
    private func interruptWaitingTask() {
        // 实现中断逻辑
    }
    
    // 记得在对象销毁时移除观察者，避免内存泄漏
    deinit {
        observedView.removeObserver(self, forKeyPath: "frame")
    }
}

注意：KVO仅适用于继承自NSObject的类，Swift的结构体无法使用KVO。

三、结合Async/Await实现“等待+中断”机制 #

针对你提到的“在等待定时器运行时设置异常中断”的需求，我们可以用Swift的Async/Await结合任务取消来实现——不再依赖定时器等待，而是让任务处于挂起状态，当变量变化时主动取消任务并触发逻辑。

举个例子，模拟一个等待任务，当目标变量变化时立刻中断等待：

class VariableInterruptMonitor {
    var targetValue: Int = 0 {
        didSet {
            // 变量变化时，取消等待任务
            waitingTask?.cancel()
            // 执行你需要的操作
            handleVariableChange()
        }
    }
    
    private var waitingTask: Task<Void, Never>?
    
    // 启动等待任务（模拟你说的“等待定时器运行”的场景）
    func startWaitingTask() {
        waitingTask = Task {
            do {
                // 模拟等待操作，比如等待某个异步任务完成
                try await Task.sleep(nanoseconds: 5_000_000_000) // 等待5秒
                print("等待任务正常完成")
            } catch is CancellationError {
                print("等待任务被变量变化中断")
                // 这里可以执行中断后的逻辑
            }
        }
    }
    
    private func handleVariableChange() {
        print("变量已变化，执行相关操作")
    }
}

这个方案中，等待任务不再是轮询变量，而是真正的挂起等待；当变量变化时，通过Task.cancel()立刻中断等待流程，完全符合你想要的“异常中断机制”。

为什么这些方案比定时器更好？ #

• 精度问题：定时器的触发间隔受RunLoop优先级、系统负载影响，无法保证毫秒级精度；而上述方案都是事件驱动，变量变化的瞬间就会触发回调，精度是即时的。
• 卡顿问题：定时器轮询会持续占用CPU资源，尤其是高频轮询时；事件驱动的方案只有在变量变化时才会执行逻辑，几乎没有额外性能开销。

内容的提问来源于stack exchange，提问作者vrthmy5312