主線程的 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;動畫效果變化的結束值（相對值）