自从FutureSplash以来，就一直从事Flash方面的工作，对于Flash’">播放器的开发，我也有了自己的一些看法。

　　欢迎加入这个弹性极大的跑道模型的讨论。

　　我将Flash 播放器看作如一条跑道。跑道上有两个截然不同的部分，一个是处理ActionScript（它包括事件处理），一个是将内容表现到屏幕上。运行时，Flash播放器围绕着跑道按照SWF文件里指定的帧速前进。不管播放器被赋予什么样的指令，播放器都会尝试按预定的速度播放文件。指定的帧速即是跑道的最大速度，播放速度只能在此之下而不能超过这个限制值。
播放器跑道模型

　　SWF文件告诉播放器在规定的时间做相应的事。播放器处理ActionScript或者显现到屏幕或者两者同时发出的指令的时候，跑道就会被伸展。如果有许多的数据或者影片剪辑要处理，或者在跑道的单一环线中处理你添加的一切内容或指令，播放器会跳过要求它执行的那些指令，并会在最短的时间里完成一个循环，但不会比指定的帧速快。

　　ActionScript 繁重时

　　图形繁重时

　　ActionScript and 图形都繁重时

　　有混合这个模型的另外几个方面。首先，播放器会将图形元素构造到一个递减的目录树中。从基本的节点开始，有许多的以帧的内容和次级节点构成的分支。播放器每一个循环树目录上所有的元素都会被处理。当前的Flash 7播放器中，帧的内容按照需要从level0最高级开始依照从小到大的顺序被扫描和处理。根据图解表现关键是使树的层级与元素的内在需要一样的简单分明。树的菜单越少，层级越浅图形元素将会被更快速的显现到屏幕上。

　　树的结构同样也适用于对ActionScript 字节码的处理当中。在AS阶段，树的现状被将以字节代码形式被扫描出来。每一个指定的事件将被逐级执行处理。ActionScript是基于栈的以栈为基础的，这样所有的字节代码被集中到堆栈上并被依照树的结构被线性处理。根据给出的帧上的代码和事件的容量，跑道上的AS部分将会被扩展。尽管没有一种固定的方法延迟代码的执行，播放器将会在每一个帧的循环中处理完被请求处理的所有内容。有趣的是，我们注意到那些使用功能和事件的代码能被排列成一个成的序列，等待着处理。在某种意义上，播放器从不会消损的，它会一直的做你所要求的所有工作，不会顺从于一个帧的循环。关键是不要在给出的帧上要求播放器处理太多的内容，并能对最新的帧依照逻辑和事件去处理。

　　至于Flash 8，从播放器的Beta版的外观来看，cacheAsBitma允许图形作为位图存储为一个MC的分支。矢量图会以位图的形式储存，但要等到图片改变了才会渲染。很好的允许播放器集中的存储于播放器的不同区域，专注于矢量存储怎样被利用。在一个基于树的表现模型里，树的一些分支被设置成branch.cacheAsBitmap=true， 存储进程会在第一关创建一个位图并将重复利用这张位图直到本区域的矢量图标记为dirty。 同样，如果每一帧位图存储分支都被标记为dirty，你不得不强制播放器在每一个帧循环中产生一张位图（处理+存储）。在我的测试当中，最优化利用cacheAsBitmap并不像看起来那样简单。

　　总之，Flash8播放器清晰的表明了它是两个不同元素的组合，图形处理和ActionScript 字节码处理。如果你滥用两者之中的一种或两种播放器的运行效率将会降低，导致下一个循环之前就认定一切已被完成。在更大的项目开发中，弹性跑道有助于帮助我们解释Flex和Flash发展中所表现的良好性能优化背后的一些晦涩难懂的逻辑。就像以前说过的许多次一样，“等那一帧”