NSTimer Thrashing - Do I Need to Handle It? - ios

Question

It's possible this question is already out there, but I couldn't find it. My question is essentially this. If I have a repeating NSTimer that executes something that takes longer than the timer interval, will there be some thrashing that will crash the app? Alternatively, does the new time event not start until the task being executed completes?

Answer 1

Since the NSTimer runs on the run loop it was created in, I think it can't ever re-enter the method it calls. This document on the run loops confirms this (see the "Timer Sources" section:
"Similarly, if a timer fires when the run loop is in the middle of
executing a handler routine, the timer waits until the next time
through the run loop to invoke its handler routine"

Answer 2

You can always just schedule an nstimer that only occurs once and then reschedule it when the function completes.
- (void)myFunction {
......stuff that your method does
[NSTimer scheduledTimerWithTimeInterval:1.0f target:self selector:#selector(myFunction) userInfo:nil repeats:NO];
}

Answer 3

A repeating timer always schedules itself based on the scheduled firing time, as opposed to the actual firing time. For example, if a timer is scheduled to fire at a particular time and every 5 seconds after that, the scheduled firing time will always fall on the original 5 second time intervals, even if the actual firing time gets delayed. If the firing time is delayed so far that it passes one or more of the scheduled firing times, the timer is fired only once for that time period; the timer is then rescheduled, after firing, for the next scheduled firing time in the future.
https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/Reference/NSTimer.html

Answer 4

As long as you avoid kicking off some asynchronous jobs, you'll be fine. If asynchronously dispatching tasks that routinely take longer than the interval between invocations of the timer, then that queue can get backed up. If doing animations, the timer will fire even though the animation may not be done.
Let me provide two examples. For both examples, let's imagine that we create a timer that fires once per second:
self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0
target:self
selector:#selector(handleTimer:)
userInfo:#"tick"
repeats:YES];
First example: Let's assume we have some serial queue:
self.queue = [[NSOperationQueue alloc] init];
self.queue.maxConcurrentOperationCount = 1;
Furthermore, let's assume we have a NSTimer handler that does something like:
- (void)handleTimer:(NSTimer *)timer
{
NSLog(#"%s %#", __FUNCTION__, timer.userInfo);
[self.queue addOperationWithBlock:^{
NSLog(#"%s starting some slow process; has %d operations queued", __FUNCTION__, self.queue.operationCount);
// to simulate a slow process, let's just sleep for 10 seconds
sleep(10);
NSLog(#"%s done", __FUNCTION__);
}];
}
Because the timer is firing every second, and because the timer handler returns almost immediately (because all it's doing is queueing up background operations), by the time the first queued operation (which takes 10 seconds) finishes and the second one starts, there are already 10 operations sitting on that background queue. And by the time the second background operation finishes, when the third operation kicks off, there are 19 operations queued up. It only gets worse because the NSTimer handler will simply keep getting called, firing more quickly than the slower background operations are getting cleared out of their queue. Obviously, if the handler did everything synchronously in the current queue, though, everything is fine, and there's no backlogging, no "thrashing" by the NSTimer.
Second example: Another example of this problem is animation. Let's assume that the timer handler method is doing something like the following, that starts a 10 second animation that moves a UIImageView:
- (void)handleTimer:(NSTimer *)timer
{
NSLog(#"%s %#", __FUNCTION__, timer.userInfo);
[UIView animateWithDuration:10.0
animations:^{
self.imageView.frame = [self determineNewFrame];
}
completion:nil];
}
This won't work (or more accurately, you'll see the subsequent invocations of the timer call handleTimer even though the previous animation is not done). If you're going to do this, you have to keep track of whether the animation is done. You have to do something like:
- (void)handleTimer:(NSTimer *)timer
{
NSLog(#"%s %#", __FUNCTION__, timer.userInfo);
if (!self.animating)
{
NSLog(#"%s initiating another animation", __FUNCTION__);
[UIView animateWithDuration:10.0
animations:^{
self.animating = YES;
self.imageView.frame = [self determineNewFrame];
}
completion:^(BOOL finished){
self.animating = NO;
}];
}
}
You either have to do some state flag (like my boolean animation flag) to prevent additional animations before the first one is done, or just not use recurring timers and simply kick off another timer in the completion block of the UIView animation class method.