从源代码可以看出引擎设计者是想这两大模块独立于渲染节点树管理，这样做的好处可以比较清晰的拆分实现模块。
但是这种拆分又会导致各个模块
远离渲染树节点关系和节点状态，以至Node内部需要通过pause/resume enter/exit向两大模块同步自己的状态和节点关系,
Node::exit的时候会自动调用resume enter的时候会自动调用resume ， 如果逻辑层需要调用pause/resume的话就要小心和内部状态冲突了。(比如你pause，然后切换场景，然后你会发现pause掉的节点突然复活了~~~)
更不爽的是还需要cleanup这样坑的接口给逻辑层管理，如果cleanup则Action和scheduler丢失，如果不cleanup…ActionManager&Scheduler将一直持有你的引用！
强大的cocos2dx确实把节点状态和两大模块同步的很好了,但是仅仅是节点状态处理了，渲染树上的节点不仅仅只有状态，还有层级关系。
比如这样一些用例：
1：战斗层所有动画节奏加速两倍，UI效果保持不变。
2：或者某角色上所有动画加速播放，但是场景其他动画节奏保持不变。
3：上面两种情况的结合或者更为复杂的多动画节奏的控制。
其实可以预想在多动画速度控制分组的情况下，这些分组和节点关系有关。
比如战斗层的动画的节点应该都是战斗层的子节点，某角色的动画应该也都运行在角色节点的子节点上。
有这个前提那不如将Action的驱动和管理交给Node
大概实现如下
每个Node实例在需要Action的时候都会有一个自己的ActionManager，在节点析构的时候顺便把ActionManager也释放了，自然就不需要cleanup了
从Director层遍历渲染树每个节点，通过节点更新各自的ActionManager来驱动Action的update (*通过每个节点添加一个时间缩放速度来达到动画节奏控制的目的)
内部不需要通过enter/exit来控制动画，在exit的以后节点不在渲染树上自然的动画就不会被驱动了
同理Scheduler和也可以这样实现，随便提一下如果EventDispatcher也通过渲染树来派生消息的话那么3.*的”dispatch events based on rendering sequence“就是在自然不过的事情了。
但是这样的实现必然会导致Node臃肿无比，这时候Component的设计模式就可以很好的排上用途了,我的大概思路是这样： 还是以Node为主，优化Component结构，ActionManager，Scheduler 和EventHandler都以Component的方式挂在Node上面，开放Node各个事件到外部的传递接口。
以上皆为个人经验和分析，欢迎讨论.
