分析facebook的AsyncDisplayKit框架，async-display使用async-transaction

上一篇《分析facebook的AsyncDisplayKit框架中的Transaction的工做原理》介紹了fb的asdk的異步事務ASAsyncTransaction，本篇介紹其在asdk異步如何應用這個異步事務。

這個圖的中心點是transaction group連結了兩個框架，左邊是QuartzCore`CALayer的是display的顯示框架，右邊是CoreFundation`CFRunLoop的主循環框架。Adsk的將CALayer擴展成ASDisplayLayer，在CALayer的display顯示框架中應用異步顯示時，將會使用Adsk的事務框架（，ASAsyncTransaction），全部事務都會被集中到一個事務組統一提交。而提交的機會（或者說時間地方）是依賴在RunLoop中的某一個運行階段。

CALayer使用了異步事務，就會將自身或包含本身的容器（CALayer(ASDisplayNodeAsyncTransactionContainer)）登記在異步事務組。

異步事務組，只有一個單例，向RunLoop登記了做爲BeforeWaiting和Exit兩個運行階段的觀察者。並在觀察者通知回調時，提交事務。

若是你熟讀CFRunLoop模塊的代碼並經過調試深刻試探過UIKit的執行流，就會清楚BeforeWaiting是在RunLoop處理完source0事件以後，在將進入mach_port等待以前，RunLoop設立的一個觀察點。而UIKit有一條事件隊列_UIApplicationHandleEventQueue，而這個隊列掛接在一個source0上（，CFRunLoopSource0能夠被RunLoop發起的事件），例如touch輸入就會被post到這個事件（注意與event source的區分）隊列中。RunLoop在處理徹底部fired的source0後纔會到達BeforeWaiting階段，也就是在UIKit的事件隊列處理以後。

異步事務組還向RunLoop登記了在Exit處觀察，由於RunLoop可能運行在一次過的模式，在使用了異步事務功能以後，就直接要結束一次性的RunLoop循環，到達Exit。若是沒有登記觀察這個階段，異步事務組將可能永遠不會有機會提交。