主線程的 RunLoop 里有兩個預(yù)置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。這兩個 Mode 都已經(jīng)被標(biāo)記為"Common"屬性。

線程和 RunLoop 之間是一一對應(yīng)的，其關(guān)系是保存在一個全局的 Dictionary 里。線程剛創(chuàng)建時并沒有 RunLoop，如果你不主動獲取，那它一直都不會有。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時，RunLoop 的銷毀是發(fā)生在線程結(jié)束時。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外)

每一個線程都有一個與之關(guān)聯(lián)的RunLoop，而每一個RunLoop可能會有多個Mode。CPU會在多個線程間切換來執(zhí)行任務(wù)，呈現(xiàn)出多個線程同時執(zhí)行的效果。執(zhí)行的任務(wù)其實就是RunLoop去各個Mode里執(zhí)行各個item。因為RunLoop是獨立的兩個，相互不會影響，所以在子線程添加timer，滑動視圖時，timer能正常運行

NSTimer與RunLoop
實際開發(fā)中，若是遇到ScrollView類與NSTimer共同使用的時候，應(yīng)該會發(fā)現(xiàn)這時的NSTimer是不準(zhǔn)時的。就是在當(dāng)你用手滑動的時候，NSTimer的時間很有可能是停止的，而松手之后，NSTimer又恢復(fù)正常了。

dispatch_barrier_async
一個dispatch barrier 允許在一個并發(fā)隊列中創(chuàng)建一個同步點。當(dāng)在并發(fā)隊列中遇到一個barrier, 他會延遲執(zhí)行barrier的block,等待所有在barrier之前提交的blocks執(zhí)行結(jié)束。 這時，barrier block自己開始執(zhí)行。 之后， 隊列繼續(xù)正常的執(zhí)行操作
這里指定的并發(fā)隊列應(yīng)該是自己通過dispatch_queue_create函數(shù)創(chuàng)建的。如果你傳的是一個串行隊列或者全局并發(fā)隊列，這個函數(shù)等同于dispatch_async函數(shù)

dispatch_barrier_async的順序執(zhí)行還是依賴queue的類型，必需要queue的類型為
dispatch_queue_create創(chuàng)建的，而且attr參數(shù)值必需是DISPATCH_QUEUE_CONCURRENT類型，前面兩個非
dispatch_barrier_async的類型的執(zhí)行是依賴其本身的執(zhí)行時間的，如果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;動畫效果變化的結(jié)束值（絕對值）
@property(nullable, strong) id byValue;動畫效果變化的結(jié)束值（相對值）