iOS中的几种timer比较

工作需要，粗略了解了ios上的几种定时器。

NSTimer：

           这个底层怎么定时我不清楚，应该是到了一定时间之后，向runLoop添加一个事件，这也就意味着，如果想在异步线程开启timer ，就需要手动的将timer 添加到runLoop中，并且run起来。

           网上看了一些说的精确度，不是明白，亲测过，子线程创建一个timer，runLoop run起来，只要timer里面的事件，不超过timer定时的时间，timer定时还是很准确的，所以如果项目需要，timer里面的执行事件的时间超过了定时器的时间，就会出问题了（试想一下，即使把事件再拿到另外一个线程去执行，执行时间永远都是大于定时时间的，即使不影响定时时间，那么事件处理的堆积事件就会越来越多，肯定无法满足需求，所以最好的是，将事件拆分，做成多个管道，多个定时器，定时器时间大于处理定时器事件的时间）。我们通常说的timer会出问题，我猜想可能是在主线程定义了一个timer，runloop执行一个耗时很长的循环，错过了timer的周期，这肯定会出问题，还有就是timer里面的事件处理时间不够也会出问题。所以我的解决办法是，子线程runLoop run起来，保持线程，同时保证timer里面的事件处理时间不超过timer时间，这样就ok了。

          综上所诉，用处理一般的事件完全足够，只是使用中需要注意。

CADisplayLink：

          这个是根据屏幕的帧率来发送事件，也依赖于runLoop，也就是说，我们只能控制多少帧，触发我们定义的事件，可用于界面的刷新，不能随心所欲的控制时间，不满足我们一般的需求。使用也很简单，自行看API

GCD的source timer：

      个人觉得这是比较给力（原谅我词汇的匮乏）的一个定时器了。原因如下，它不依赖于runLoop，底层两个队列，一个事件队列，一个任务队列，定时到了之后，从任务队列里取出事件，加入到事件队列（之前还有一步，向任务队列push任务），执行事件，至于他的一直执行（为什么不依赖于runLoop，这于GCD的底层实现有关，有兴趣可以自行了解），放到一个子线程执行（想在主线程执行的，可以用mainQUeue包一层），在子线程的执行顺序也是串行的，所以如果block的执行事件时间大于定时时间，还是会阻塞，可以一定层度上解决，请看下面代

可以在block块里再用一个队列，异步执行，包起来，但是我们看一下执行结果

确实，执行事件表面看并没有影响定时器的定时，但是注意看始终都是系统分配的几个线程去执行事件，也就是说这几个线程是重复利用的，当第一次使用完，第二次使用的时候，定时并不准确（可能是线程清理需要事件，具体不清楚），还有定时器的定时还是不准确，这可能就跟GCDSource内部实现有关系了，所以不推荐这样使用，目前我个人的想法就是，如果事件处理时间过长，要吗想办法拆分事件，加管道，加定时器，要吗延长定时时间。

与timer相比，的优势就是，不需要维持runLoop，（性能消耗上或许有区别，没有实际看过），还有本身就是子线程去执行的，不会阻塞主线程。

以上只是我个人的想法和总结，肯定有说得不对的地方，希望多讨论，多批评指正。