RunLoop

主线程的 RunLoop 里有两个预置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。这两个 Mode 都已经被标记为"Common"属性。

线程和 RunLoop 之间是一一对应的，其关系是保存在一个全局的 Dictionary 里。线程刚创建时并没有 RunLoop，如果你不主动获取，那它一直都不会有。RunLoop 的创建是发生在第一次获取时，RunLoop 的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop（主线程除外)

每一个线程都有一个与之关联的RunLoop，而每一个RunLoop可能会有多个Mode。CPU会在多个线程间切换来执行任务，呈现出多个线程同时执行的效果。执行的任务其实就是RunLoop去各个Mode里执行各个item。因为RunLoop是独立的两个，相互不会影响，所以在子线程添加timer，滑动视图时，timer能正常运行

NSTimer与RunLoop
实际开发中，若是遇到ScrollView类与NSTimer共同使用的时候，应该会发现这时的NSTimer是不准时的。就是在当你用手滑动的时候，NSTimer的时间很有可能是停止的，而松手之后，NSTimer又恢复正常了。

dispatch_barrier_async
一个dispatch barrier 允许在一个并发队列中创建一个同步点。当在并发队列中遇到一个barrier, 他会延迟执行barrier的block,等待所有在barrier之前提交的blocks执行结束。 这时，barrier block自己开始执行。 之后， 队列继续正常的执行操作
这里指定的并发队列应该是自己通过dispatch_queue_create函数创建的。如果你传的是一个串行队列或者全局并发队列，这个函数等同于dispatch_async函数

dispatch_barrier_async的顺序执行还是依赖queue的类型，必需要queue的类型为
dispatch_queue_create创建的，而且attr参数值必需是DISPATCH_QUEUE_CONCURRENT类型，前面两个非
dispatch_barrier_async的类型的执行是依赖其本身的执行时间的，如果attr如果是DISPATCH_QUEUE_SERIAL
时，那就完全是符合Serial queue的FIFO特征了

fromValue和toValue不为空，动画的效果会从fromValue的值变化到toValue。
fromValue和byValue都不为空，动画的效果将会从fromValue变化到fromValue+byValue。
@property(nullable, strong) id fromValue;动画的效果变化的初始值
@property(nullable, strong) id toValue;动画效果变化的结束值（绝对值）
@property(nullable, strong) id byValue;动画效果变化的结束值（相对值）