AS的UI组件架构设计

Flashplayer拥有独特的帧模型（可变跑道模型）和内部时间片的划分机制。

提供给开发者的编程接口就是ENTER_FRAME事件和RENDER事件。

ENTER_FRAME事件代表播放头进入该帧，标志着该帧开始。

RENDER事件是Flashplayer进行实质的屏幕更新前发出的事件，开发者可以监听该事件，在屏幕渲染前做最后一件事。该事件可以理解为该帧即将结束，下一帧即将开始。

换句话讲，这两个事件一个位于某帧的头，一个位于尾巴。

Flashplayer的帧模型、时间片机制使得AS的UI组件结构设计上呈现出必然的特点：

描绘和屏幕更新（渲染）是分开的。

解释如下：

在某帧没有到达“尾巴”之间，开发这可以对组件进行描绘（draw），这些描绘不会马上反映到屏幕上，也就是说我们眼睛还看不见。一但到达“尾巴”，则开发者无法干预，完全是Flashplayer内部机制在起作用，在进行真正地屏幕更新，也就是说屏幕更新后，我们人眼能够看到描绘后的效果了（屏幕变化了）。

所有的UI组件架构中，都会涉及到ENTER_FRAME事件和RENDER事件。或者两个都利用，或者利用其一。以实例说话：

1. minimalcomps架构使用了ENTER_FRAME事件。

    在该事件监听器中根据上一帧的外观属性进行描绘，然后听凭Flashplayer的机制自行屏幕更新（渲染）。

    而该帧ENTER_FRAME事件发生后，Flashplayer真正屏幕渲染前，这一期间发生的外观属性变化则要等到下一帧才会被更新到屏幕上。

2. flash的UI组件架构中同时使用了ENTER_FRAME事件和RENDER事件。

3. flex的UI组件架构中同时使用了ENTER_FRAME事件和RENDER事件。

上面的三个UI组件架构中还都采用了“延迟策略”。笼统地说就是某一帧的UI变化并不是在该帧进行屏幕更新（渲染），而是利用ENTER_FRAME事件吧屏幕更新延迟到下一帧，甚至下下一帧。

只要帧频的设置能够满足人眼的生理特点（0.1秒的视觉暂留），那么屏幕的变化对于视觉而言就是连续的，不跳跃的。

因此，为什么UI组件架构要采用帧延迟渲染（屏幕更新），是针对特定情境下的特殊设计和通用设计？

这是个值得思考，并需要实验的事情。