RxSwift学习插曲--Timer补充内容

前言

在之前的一篇内容RxSwift学习--核心逻辑初探中，曾列举了一些使用RxSwift优势的小例子，其中关于Timer定时器的例子，在RxSwift中创建的定时器并不受RunLoop的影响，至于为什么不受RunLoop的影响，具体原因还有待分析。

Timer的创建方式

1. NSTimer

相信大家在Object-C中都有使用过NSTimer,其创建方式在Swift中比较类似的

(1)第一种写法

func testTimer(){
    timer = Timer.init(timeInterval: 1, target: self, selector: #selector(timerFire), userInfo: nil, repeats: true)
    RunLoop.current.add(timer, forMode: .common)
}

@objc func timerFire(){
    print("If i know what love is,it is because of you!")
}

(2)第二种写法

timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true, block: { (timer) in
    print("If i know what love is,it is because of you!")
})
RunLoop.current.add(timer, forMode: .common)

这两种方式创建的Timer都会受RunLoop的影响，它的准确性依赖于RunLoop的状态。

2. Dispatch Source Timer

Dispatch Source Timer 是一种与 Dispatch Queue 结合使用的定时器,当需要在后台 queue 中定期执行任务的时候，使用 Dispatch Source Timer 要比使用 NSTimer 更加自然，也更加高效，且无需在 main queue 和后台 queue 之前切换.

func testGCD(){
        gcdTimer = DispatchSource.makeTimerSource()
        gcdTimer?.schedule(deadline: DispatchTime.now(), repeating: DispatchTimeInterval.seconds(1))
        gcdTimer?.setEventHandler(handler: {
            print("You are not brave，no one is strong for you.")
        })
        gcdTimer?.resume()
        //gcdTimer?.suspend()
        //gcdTimer?.cancel()
        //gcdTimer = nil

    }

Dispatch Source Timer是不受RunLoop状态的影响的。

注意1： gcdTimer?.cancel() 则是真正意义上的取消 Timer,被取消之后如果想再次执行 Timer，只能重新创建新的 Timer。这个过程类似于对 NSTimer 执行 invalidate.

注意2： 关于取消 Timer,gcdTimer?.suspend() 之后的 Timer，是不能被释放的（gcdTimer = nil）,会引起崩溃，因为使用 gcdTimer?.suspend() 时，Timer 本身的实例需要一直保持,但是使用 gcdTimer?.cancel() 则没有这个崩溃问题。

3. CADisplayLink

CADisplayLink是用于同步屏幕刷新频率的计时器.

func testCAD(){
   cadTimer = CADisplayLink(target: self, selector: #selector(timerFire))
    cadTimer?.preferredFramesPerSecond = 1
    cadTimer?.add(to: RunLoop.current, forMode: .common)
    
   // cadTimer?.remove(from: RunLoop.current, forMode: .common)
}

@objc func timerFire(){
    print("Like is the choice, love is only you!")
}

CADisplayLink同样会受RunLoop的状态的影响。

注意： cadTimer?.remove(from: RunLoop.current, forMode: .common)将接收者从给定的模式中移除,这个方法会对计时器进行隐式的release,在调用.remove(),需要做判断,如果当期计时器不在RunLoop的话,会出现野指针的crash.

RxSwift中的Timer

1.Timer的创建

先来写一个小例子试一下：

func RxTimer(){
        rxtimer = Observable.timer(1, period: 3, scheduler: MainScheduler.instance)
        rxtimer.subscribe(onNext: { (num) in
            print("Happy in pain \(num)")
        }).disposed(by: disposeBag)
        
        
    }

运行之后可以看到rxtimer完全不受RunLoop的状态的影响。

timer是Observable的一个操作符,(Observable有很多操作符，后续会不断补充)

public static func timer(_ dueTime: RxTimeInterval, period: RxTimeInterval? = nil, scheduler: SchedulerType) -> RxSwift.Observable

参数dueTime：初始延时(订阅开始和发送第一个元素值之间的时间段)

参数period：每次发送的时间间隔

参数scheduler：所在调度器，类似于线程

timer.png

2.源代码分析

下面开始分析原因：
首先来到RxSwift下的Timer.swift文件，找到Timer类，源码如下：

final private class Timer: Producer {
    fileprivate let _scheduler: SchedulerType
    fileprivate let _dueTime: RxTimeInterval
    fileprivate let _period: RxTimeInterval?

    init(dueTime: RxTimeInterval, period: RxTimeInterval?, scheduler: SchedulerType) {
        self._scheduler = scheduler
        self._dueTime = dueTime
        self._period = period
    }

    override func run(_ observer: Observer, cancel: Cancelable) -> (sink: Disposable, subscription: Disposable) where Observer.Element == Element {
        if self._period != nil {
            let sink = TimerSink(parent: self, observer: observer, cancel: cancel)
            let subscription = sink.run()
            return (sink: sink, subscription: subscription)
        }
        else {
            let sink = TimerOneOffSink(parent: self, observer: observer, cancel: cancel)
            let subscription = sink.run()
            return (sink: sink, subscription: subscription)
        }
    }
}

看过RxSwift核心逻辑的应该知道，继承于Producer的类，必然会进入到当前类run()方法,(具体逻辑请参考RxSwift核心逻辑);

可以看到当前类的run()方法，会创建一个TimerSink，然后这个TimerSink执行了自己的sink.run()方法，那么再次跟进去TimerSink类的源码:

final private class TimerSink : Sink where Observer.Element : RxAbstractInteger  {
    typealias Parent = Timer

    private let _parent: Parent
    private let _lock = RecursiveLock()

    init(parent: Parent, observer: Observer, cancel: Cancelable) {
        self._parent = parent
        super.init(observer: observer, cancel: cancel)
    }

    func run() -> Disposable {
        return self._parent._scheduler.schedulePeriodic(0 as Observer.Element, startAfter: self._parent._dueTime, period: self._parent._period!) { state in
            self._lock.lock(); defer { self._lock.unlock() }
            self.forwardOn(.next(state))
            return state &+ 1
        }
    }
}

可以看到TimerSink的run()方法会返回self.Timer._scheduler.schedulePeriodic()方法，那么就再次跟进去这个方法；这里在跟方法的时候，可能不知道跟进去哪一个？

image

在最初声明这个Timer的时候，我们在传参数的时候,对参数scheduler:传入的是MainScheduler.instance,那么我们就跟进去ConcurrentMainScheduler.schedulePeriodic()这个方法;

public func schedulePeriodic(_ state: StateType, startAfter: RxTimeInterval, period: RxTimeInterval, action: @escaping (StateType) -> StateType) -> Disposable {
        return self._mainScheduler.schedulePeriodic(state, startAfter: startAfter, period: period, action: action)
    }

进去之后发现这只是一个过渡方法，那么久继续跟进；

public func schedulePeriodic(_ state: StateType, startAfter: RxTimeInterval, period: RxTimeInterval, action: @escaping (StateType) -> StateType) -> Disposable {
        return self.configuration.schedulePeriodic(state, startAfter: startAfter, period: period, action: action)
    }

发现还是过渡方法，那就再次跟进;

func schedulePeriodic(_ state: StateType, startAfter: RxTimeInterval, period: RxTimeInterval, action: @escaping (StateType) -> StateType) -> Disposable {
        let initial = DispatchTime.now() + startAfter

        var timerState = state

        let timer = DispatchSource.makeTimerSource(queue: self.queue)
        timer.schedule(deadline: initial, repeating: period, leeway: self.leeway)
        
        var timerReference: DispatchSourceTimer? = timer
        let cancelTimer = Disposables.create {
            timerReference?.cancel()
            timerReference = nil
        }

        timer.setEventHandler(handler: {
            if cancelTimer.isDisposed {
                return
            }
            timerState = action(timerState)
        })
        timer.resume()
        
        return cancelTimer
    }

最终来到schedulePeriodic()这个方法的具体实现，可以看到这句let timer = DispatchSource.makeTimerSource(queue: self.queue)这里就是初始化了一个Dispatch Source Timer。

然后看一下timer.setEventHandler()方法，在这个方法里有这样一句代码timerState = action(timerState)就是一直在改变timer的状态，那么这个action是什么呢？可以看到，这个action传入的是一个尾随闭包，那么这个闭包是什么呢？视线再次回到TimerSink类的源码：

{ state in
            self._lock.lock(); defer { self._lock.unlock() }
            self.forwardOn(.next(state))
            return state &+ 1
        }

这个就是action传入的尾随闭包。看到这里会发现，每次执行action()方法的时候，也就是每次会调用这个闭包，在这个闭包内部会执行self.forwardOn(.next(state)),

self.forwardOn(.next(state))这个方法会调用self._observer.on(event),这个self._observer.on(event)方法就会把的event传入到.subscribe()订阅方法中，订阅方法中的AnonymousObserver的闭包会根据传入的event枚举值调用onNext(),这时.subscribe()订阅方法中的onNext:就能够等到响应了。(这里具体的逻辑请参考上篇内容，由于代码过多，在这里就不再次赘述了)

总结

至此，关于RxSwift中的Timer就写到这里，可以看到在Timer的源码中，是创建了一个Dispatch Source Timer，并且不断的调用timer的状态，让订阅方法中的闭包得到响应。关于Timer的研究还是不够深入，后续会再更新。