在我们的应用程序(游戏)中，某些情况下运行速度不够快。显然，我们希望加快速度，但是与此同时，这会导致很多问题(或者如果没有造成问题，则两者是相关的)。
与我们自己的功能最不相关的一个是内置的Alert.show()方法停止工作。通常，会显示全屏透明框，而不显示实际弹出窗口。我认为这取决于Flex为其他任务提供所有可用的周期...但是事实证明，很难进行分析性调查，因此我很高兴听到另一种解释。

需要澄清的是，Flex的核心部分在这种情况下根本无法工作。我已经遍历了代码，例如在屏幕上添加了一个新元素，一切都发生了，并且在主显示画布上调用了addChild()方法……但是随后该元素没有出现。如果然后禁用更新循环，该元素会突然出现。

因此，不管Flex是否应该运行完全相同的代码，以某种方式阻止它都是某种奇怪的方式。如我所说，即使Flex Alert.show()方法也不起作用。

解决方案

我不太确定Flex是否具有自己的其他性能处理。但是对于纯动作脚本，唯一会发生的是帧速率会缓慢爬行，通常一切都会变慢。如果我们堆叠大量透明或者遮罩的对象，则可能会出现一些奇怪的现象，但这应该更引人注意。

而且我想告诉我们，用Flex制作游戏并不是一个好主意(只是由于框架具有性能开销)，这有点晚了；

我喜欢用FLEX 3(actionscript3)制作游戏，与Flash CS3相比，它实际上是非常方便的解决方案：良好的调试环境，无需麻烦。
当然，这取决于哪种游戏风格更好，如果我们需要大量图形，我们可能会更喜欢Flash，但是Flex允许我们使用外部图像，组件等。

解决效果问题的方法：我们可以使用在旧的MacOSX机器上，看看在非常慢的机器上会发生什么，有以下几种解决方案：
机器旧时，将对象移动超过x ++ y ++像素
减少对象

我们可以使用计时器检测机器的运行速度。

所有Flash内容都是按帧执行的。Flash将执行一帧代码，然后更新屏幕，然后等到下一帧更新。

当Flash无法跟上指定的帧速率时，所有发生的事情就是Flash不必等待两次帧更新，而是尽可能快地完成它们，而无需等待两次更新。因此，唯一可见的区别是帧更新发生的频率降低。绝不会因性能原因而跳过代码，删除事件或者跳过屏幕重绘(除非我们发现了新的错误)。

因此，最有可能的罪魁祸首是我们遇到了非常依赖时间的代码问题(例如，希望两个计时器在同一帧上触发的代码)，或者是其他一些被误诊的问题。 (例如，也许是一个导致速度下降的错误，而不是导致错误的速度下降。)