How do I create a NSTimer on a background thread?

前端 未结 10 605
感情败类
感情败类 2020-11-28 02:04

I have a task that needs to be performed every 1 second. Currently I have an NSTimer firing repeatedly every 1 sec. How do I have the timer fire in a background thread (no

相关标签:
10条回答
  • 2020-11-28 02:34

    My Swift 3.0 solution for iOS 10+, timerMethod() will be called in background queue.

    class ViewController: UIViewController {
    
        var timer: Timer!
        let queue = DispatchQueue(label: "Timer DispatchQueue", qos: .background, attributes: .concurrent, autoreleaseFrequency: .workItem, target: nil)
    
        override func viewDidLoad() {
            super.viewDidLoad()
    
            queue.async { [unowned self] in
                let currentRunLoop = RunLoop.current
                let timeInterval = 1.0
                self.timer = Timer.scheduledTimer(timeInterval: timeInterval, target: self, selector: #selector(self.timerMethod), userInfo: nil, repeats: true)
                self.timer.tolerance = timeInterval * 0.1
                currentRunLoop.add(self.timer, forMode: .commonModes)
                currentRunLoop.run()
            }
        }
    
        func timerMethod() {
            print("code")
        }
    
        override func viewDidDisappear(_ animated: Bool) {
            super.viewDidDisappear(animated)
            queue.sync {
                timer.invalidate()
            }
        }
    }
    
    0 讨论(0)
  • 2020-11-28 02:35

    The timer would need to be installed into a run loop operating on an already-running background thread. That thread would have to continue to run the run loop to have the timer actually fire. And for that background thread to continue being able to fire other timer events, it would need to spawn a new thread to actually handle events anyway (assuming, of course, that the processing you're doing takes a significant amount of time).

    For whatever it's worth, I think handling timer events by spawning a new thread using Grand Central Dispatch or NSBlockOperation is a perfectly reasonable use of your main thread.

    0 讨论(0)
  • 2020-11-28 02:42

    For swift 3.0,

    Tikhonv's answer does not explain too much. Here adds some of my understanding.

    To make things short first, here is the code. It is DIFFERENT from Tikhonv's code at the place where I create the timer. I create the timer using constructer and add it into the loop. I think the scheduleTimer function will add the timer on to the main thread's RunLoop. So it is better to create timer using the constructor.

    class RunTimer{
      let queue = DispatchQueue(label: "Timer", qos: .background, attributes: .concurrent)
      let timer: Timer?
    
      private func startTimer() {
        // schedule timer on background
        queue.async { [unowned self] in
          if let _ = self.timer {
            self.timer?.invalidate()
            self.timer = nil
          }
          let currentRunLoop = RunLoop.current
          self.timer = Timer(timeInterval: self.updateInterval, target: self, selector: #selector(self.timerTriggered), userInfo: nil, repeats: true)
          currentRunLoop.add(self.timer!, forMode: .commonModes)
          currentRunLoop.run()
        }
      }
    
      func timerTriggered() {
        // it will run under queue by default
        debug()
      }
    
      func debug() {
         // print out the name of current queue
         let name = __dispatch_queue_get_label(nil)
         print(String(cString: name, encoding: .utf8))
      }
    
      func stopTimer() {
        queue.sync { [unowned self] in
          guard let _ = self.timer else {
            // error, timer already stopped
            return
          }
          self.timer?.invalidate()
          self.timer = nil
        }
      }
    }
    

    Create Queue

    First, create a queue to make timer run on background and store that queue as a class property in order to reuse it for stop timer. I am not sure if we need to use the same queue for start and stop, the reason I did this is because I saw a warning message here.

    The RunLoop class is generally not considered to be thread-safe and its methods should only be called within the context of the current thread. You should never try to call the methods of an RunLoop object running in a different thread, as doing so might cause unexpected results.

    So I decided to store the queue and use the same queue for the timer to avoid synchronization issues.

    Also create an empty timer and stored in the class variable as well. Make it optional so you can stop the timer and set it to nil.

    class RunTimer{
      let queue = DispatchQueue(label: "Timer", qos: .background, attributes: .concurrent)
      let timer: Timer?
    }
    

    Start Timer

    To start timer, first call async from DispatchQueue. Then it is a good practice to first check if the timer has already started. If the timer variable is not nil, then invalidate() it and set it to nil.

    The next step is to get the current RunLoop. Because we did this in the block of queue we created, it will get the RunLoop for the background queue we created before.

    Create the timer. Here instead of using scheduledTimer, we just call the constructor of timer and pass in whatever property you want for the timer such as timeInterval, target, selector, etc.

    Add the created timer to the RunLoop. Run it.

    Here is a question about running the RunLoop. According to the documentation here, it says it effectively begins an infinite loop that processes data from the run loop's input sources and timers.

    private func startTimer() {
      // schedule timer on background
      queue.async { [unowned self] in
        if let _ = self.timer {
          self.timer?.invalidate()
          self.timer = nil
        }
    
        let currentRunLoop = RunLoop.current
        self.timer = Timer(timeInterval: self.updateInterval, target: self, selector: #selector(self.timerTriggered), userInfo: nil, repeats: true)
        currentRunLoop.add(self.timer!, forMode: .commonModes)
        currentRunLoop.run()
      }
    }
    

    Trigger Timer

    Implement the function as normal. When that function gets called, it is called under the queue by default.

    func timerTriggered() {
      // under queue by default
      debug()
    }
    
    func debug() {
      let name = __dispatch_queue_get_label(nil)
      print(String(cString: name, encoding: .utf8))
    }
    

    The debug function above is use to print out the name of the queue. If you ever worry if it has been running on the queue, you can call it to check.

    Stop Timer

    Stop timer is easy, call validate() and set the timer variable stored inside class to nil.

    Here I am running it under the queue again. Because of the warning here I decided to run all the timer related code under the queue to avoid conflicts.

    func stopTimer() {
      queue.sync { [unowned self] in
        guard let _ = self.timer else {
          // error, timer already stopped
          return
        }
        self.timer?.invalidate()
        self.timer = nil
      }
    }
    

    Questions related to RunLoop

    I am somehow a little bit confused on if we need to manually stop the RunLoop or not. According to the documentation here, it seems that when no timers attached to it, then it will exits immediately. So when we stop the timer, it should exists itself. However, at the end of that document, it also said:

    removing all known input sources and timers from the run loop is not a guarantee that the run loop will exit. macOS can install and remove additional input sources as needed to process requests targeted at the receiver’s thread. Those sources could therefore prevent the run loop from exiting.

    I tried the solution below that provided in the documentation for a guarantee to terminate the loop. However, the timer does not fire after I change .run() to the code below.

    while (self.timer != nil && currentRunLoop.run(mode: .commonModes, before: Date.distantFuture)) {};
    

    What I am thinking is that it might be safe for just using .run() on iOS. Because the documentation states that macOS is install and remove additional input sources as needed to process requests targeted at the receiver's thread. So iOS might be fine.

    0 讨论(0)
  • 2020-11-28 02:46

    Today after 6 years, I try to do same thing, here is alternative soltion: GCD or NSThread.

    Timers work in conjunction with run loops, a thread's runloop can be get from the thread only, so the key is that schedule timer in the thread.

    Except main thread's runloop, runloop should start manually; there should be some events to handle in running runloop, like Timer, otherwise runloop will exit, and we can use this to exit a runloop if timer is the only event source: invalidate the timer.

    The following code is Swift 4:

    Solution 0: GCD

    weak var weakTimer: Timer?
    @objc func timerMethod() {
        // vefiry whether timer is fired in background thread
        NSLog("It's called from main thread: \(Thread.isMainThread)")
    }
    
    func scheduleTimerInBackgroundThread(){
        DispatchQueue.global().async(execute: {
            //This method schedules timer to current runloop.
            self.weakTimer = Timer.scheduledTimer(timeInterval: 1, target: self, selector: #selector(timerMethod), userInfo: nil, repeats: true)
            //start runloop manually, otherwise timer won't fire
            //add timer before run, otherwise runloop find there's nothing to do and exit directly.
            RunLoop.current.run()
        })
    }
    

    Timer has strong reference to target, and runloop has strong reference to timer, after timer invalidate, it release target, so keep weak reference to it in target and invalidate it in appropriate time to exit runloop(and then exit thread).

    Note: as an optimization, syncfunction of DispatchQueue invokes the block on the current thread when possible. Actually, you execute above code in main thread, Timer is fired in main thread, so don't use sync function, otherwise timer is not fired at the thread you want.

    You could name thread to track its activity by pausing program executing in Xcode. In GCD, use:

    Thread.current.name = "ThreadWithTimer"
    

    Solution 1: Thread

    We could use NSThread directly. Don't afraid, code is easy.

    func configurateTimerInBackgroundThread(){
        // Don't worry, thread won't be recycled after this method return.
        // Of course, it must be started.
        let thread = Thread.init(target: self, selector: #selector(addTimer), object: nil)
        thread.start()
    }
    
    @objc func addTimer() {
        weakTimer = Timer.scheduledTimer(timeInterval: 1, target: self, selector: #selector(timerMethod), userInfo: nil, repeats: true)
        RunLoop.current.run()
    }
    

    Solution 2: Subclass Thread

    If you want to use Thread subclass:

    class TimerThread: Thread {
        var timer: Timer
        init(timer: Timer) {
            self.timer = timer
            super.init()
        }
    
        override func main() {
            RunLoop.current.add(timer, forMode: .defaultRunLoopMode)
            RunLoop.current.run()
        }
    }
    

    Note: don't add timer in init, otherwise, timer is add to init's caller's thread's runloop, not this thread's runloop, e.g., you run following code in main thread, if TimerThread add timer in init method, timer will be scheduled to main thread's runloop, not timerThread's runloop. You can verify it in timerMethod() log.

    let timer = Timer.init(timeInterval: 1, target: self, selector: #selector(timerMethod), userInfo: nil, repeats: true)
    weakTimer = timer
    let timerThread = TimerThread.init(timer: timer)
    timerThread.start()
    

    P.S About Runloop.current.run(), its document suggest don't call this method if we want runloop to terminate, use run(mode: RunLoopMode, before limitDate: Date), actually run() repeatedly invoke this method in the NSDefaultRunloopMode, what's mode? More details in runloop and thread.

    0 讨论(0)
  • 2020-11-28 02:47

    If you need this so timers still run when you scroll your views (or maps), you need to schedule them on different run loop mode. Replace your current timer:

    [NSTimer scheduledTimerWithTimeInterval:0.5
                                     target:self
                                   selector:@selector(timerFired:)
                                   userInfo:nil repeats:YES];
    

    With this one:

    NSTimer *timer = [NSTimer timerWithTimeInterval:0.5
                                               target:self
                                             selector:@selector(timerFired:)
                                             userInfo:nil repeats:YES];
    [[NSRunLoop mainRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
    

    For details, check this blog post: Event tracking stops NSTimer

    EDIT : second block of code, the NSTimer still runs on the main thread, still on the same run loop as the scrollviews. The difference is the run loop mode. Check the blog post for a clear explanation.

    0 讨论(0)
  • 2020-11-28 02:47

    If you want your NSTimer to run in even background, do the following-

    1. call [self beginBackgroundTask] method in applicationWillResignActive methods
    2. call [self endBackgroundTask] method in applicationWillEnterForeground

    That's it

    -(void)beginBackgroundTask
    {
        bgTask = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^{
            [self endBackgroundTask];
        }];
    }
    
    -(void)endBackgroundTask
    {
        [[UIApplication sharedApplication] endBackgroundTask:bgTask];
        bgTask = UIBackgroundTaskInvalid;
    }
    
    0 讨论(0)
提交回复
热议问题