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;動畫效果變化的結束值(相對值)

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容