Work requires a quick knowledge of several timers on the ios.
I don’t know how the underlying timing, should be at a certain time, add an event to the runLoop, this also means that if you want to open timer in asynchronous thread, need to manually add timer to runLoop, and run.
Online to see some say the accuracy is not clear, pro test, sub thread to create a timer, runLoop, run, timer as long as the inside of the event, not more than timer timing time, timer timing is still very accurate, so if the project needs, timer inside the execution time of events over the time of the timer will be a problem (imagine, even if the event and then get another thread to execute, the execution time is always greater than the timing of the time, even if does not affect the timing of time, then the event processing accumulation event will be more and more, certainly can not meet the demand, so the best is the event split, create a pipeline, multiple timer, timer timer event processing time is greater than the time). We usually say that the timer would be a problem, I guess may be a timer defined in the main thread, the runloop performs a long cycle, missed the timer cycle, it will certainly be a problem, there is not enough timer inside the processing time of the event will be a problem. So my solution is to raise the thread runLoop run, keep the thread, and ensure that the event processing time within the timer does not exceed timer time, so ok.
To sum up, with general events completely enough, just use the need to pay attention to.
This is according to the screen frame rate to send events is dependent on runLoop, that is to say, we can only control the number of frames, we define the trigger events that can be used to interface the refresh control, time can not be arbitrary, we do not meet the general requirements. It’s easy to use. Look at API yourself
Timer source GCD:
Personally think this is awesome (forgive me lack of vocabulary) of a timer. The reasons are as follows, it does not depend on runLoop, the bottom two queue, an event queue, a task queue, then to remove the timing, the event from the task queue and added to the event queue (before there is a step to the task queue push task), as for his execution events has been performed (why not rely on in runLoop, the GCD of the underlying implementation, interested can understand), into a sub thread (to use mainQUeue the packet layer in the main thread of execution, the execution order in Zi Xiancheng), is a serial, so if the execution of the block event time is greater than the regular time, or will block, can a certain degree, please look at the following generation
You can use a queue in the block block to execute asynchronously and wrap up, but let’s look at the execution results
Indeed, the surface does not affect the implementation of the event timer, but the watch is always assigned to execute several threads system events, that is to say the thread is reusable, when used for the first time, the second time use, the timing is not accurate (may be needed to clear the thread specific events clearly, there are timer) is not accurate, it may be with the internal implementation of the GCDSource relationship, so this is not recommended, at present my personal idea is, if the event processing time is too long, you should try to split the event, and the pipeline, and to prolong the time timer, it.
Compared with timer, the advantage is that there is no need to maintain runLoop (performance may vary, have not actually seen), and the thread itself is executed, and it does not block the main thread.
These are just my personal ideas and conclusions. I’m sure there is something wrong with it. I hope to discuss more and criticize more.