定时器工作流程：硬件时钟信号->操作系统->进程->线程
现代计算机基本可以忽略时钟信号分发到线程之前的延时，因此当我们探讨某个系统api定时器是否准确的时候，我们只需要关注时钟信号从进程到线程的延时即可
因此这个议题要区分线程来讨论，iOS中有三个api可以用来实现定时器，他们分别是NSTimer、CADisplayLink、GCD（dispatch_source_t、dispatch_time_t）
区别：
NSTimer和CADisplayLink需要注册到RunLoop去执行，GCD仅仅依赖于线程，和RunLoop无关。
NSTimer和CADisplayLink不支持多线程，GCD可以NSTimer和dispatch_source_t依赖的是硬件时钟发送信号的频率，因此粒度可以分得更细，比如1毫秒，而CADisplayLink依赖的是硬件时钟的VSync信号，该信号固定一秒钟发出60次，这意味着粒度最细也就16.7毫秒执行一次回调
三种定时器的执行过程
NSTimer
NSTimer由硬件时钟计数信号驱动，操作系统接收到时钟信号之后将其转换为时钟计数，然后分发给活跃的App进程，进程内注册时间信号的线程，会在runloop启动后注册CFRunLoopTimerRef，接收进程分发过来的时钟计数信号，Runloop随之执行一次
CADisplayLink
CADisplayLink由硬件时钟VSync信号驱动，每秒钟发出60次，渲染服务进程接收到VSync信号后，会通过IPC通知到活跃的App进程，进程内注册VSync信号的线程，会在Runloop启动后会注册CFRunLoopSourceRef（这里是source1，基于mach_port），接收进程分发过来的VSync信号，Runloop随之执行一次
dispatch_source_t
dispatch_source_t同样由硬件时钟计数信号驱动，只是不依赖于runloop，操作系统接收到时钟信号之后将其转换为时钟计数，然后分发给活跃的App进程，进程检测到有注册到操作系统内核的时间源，随即会申请一个线程，该线程是重新创建的还是复用线程池中的由操作系统决定，操作系统会最大限度复用现有空闲线程，之后执行source回调
以上就是非主线程三种定时器的执行过程，我们可以明显看出他们的开销：
NSTimer和CADisplayLink在创建之初就会绑定一个线程，并且会注册到当前线程的runloop，该线程会一直存在直到定时器销毁，线程被激活后，定时器的回调会在runloop中处理；dispatch_source_t创建之初不会绑定线程，但是在每次执行之前都会申请一个线程，这里有从新创建线程的开销，但是没有runloop执行的开销
存在的弊端：
1.NSTimer和CADisplayLink底层是runloop实现的，所以有可能并不准时，如果runloop任务过于繁重，每一圈的处理就会耗时，就导致不准时。
2.对于CADisplayLink，当CPU忙于其他计算，就无法保证每秒60次的频率执行屏幕绘制。
GCD定时器直接和系统内核挂钩，不依赖于runloop，相对精准。
