分析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。如果没有登记观察这个阶段，异步事务组将可能永远不会有机会提交。