A repeating timer reschedules itself based on the scheduled firing time, not 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.
To sum up: timer will retain its target, we need to be careful about the life cycle of this target, especially the repetitive timer.
Repeated timer encounters this situation. If the delay exceeds one cycle, it will be merged with the subsequent trigger, that is, it will only be triggered once in a cycle. But no matter how ridiculously delayed the timer's trigger time is, the trigger time of the timer behind it is always multiples of the gap between the first timer added.
The timer does not cause the subsequent trigger time to be delayed due to the trigger delay.
To sum up: timer is not a real-time mechanism, there will be delay, and the degree of delay is related to the execution of the current thread.
To sum up: Timer must be added to the runloop for it to take effect.
[[NSRunLoop currentRunLoop] addTimer: timer forMode: NSDefaultRunLoopMode];
// Open the following line to output the content of the runloop, you can see that the timer has been added
//NSLog(@"the thread's runloop: %@", [NSRunLoop currentRunLoop]);
// Open the following line, the thread's runloop will run, and the timer will work
//[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:3]];
To sum up: For the timer to take effect, it must be ensured that the thread's runloop has been started, and its runloopmode must also match.
Whether the timer is executed on time
Not on time!
The first is not on time: it is possible to skip over
- Occurs when the thread processes something that is more time consuming
- Also, the runloop mode added to the timer is not the mode in which the runloop is currently running, which often happens.
For the first case, we should not work on the timer, but should avoid this time-consuming work. Then in the second case, as a developer, this is also the most important place to pay attention. Pay attention, and then add timer to multiple modes of runloop depending on the situation.
Although skipped, the subsequent execution will not be based on the delayed time plus the interval time, but will be executed based on the previous time. for example:
The timing interval is 2 seconds, and t1 seconds are added successfully, then events will be registered at t2, t4, t6, t8, and t10 seconds, and triggered at these times. Assuming that it took 5.5 seconds to execute a timeout operation in the 3rd second, the trigger time is: t2, t8.5, t10, and the 4th and 6th seconds were skipped, although it was triggered once at t8.5 seconds , but the next trigger time is t10, not t10.5.
The second is not on time: not on time
For example, the t2, t4, t6, t8, and t10 mentioned above will not be triggered at the exact time, but will be delayed for a small time. The reason can also be attributed to two points:
- In order to save resources, RunLoop will not be triggered at a very precise point in time
- Threads have time-consuming operations, or other threads have time-consuming operations.
https://www.cnblogs.com/mddblog/p/6517377.html
http://www.cnblogs.com/smileEvday/archive/2012/12/21/NSTimer.html