在我们的应用程序（游戏）中，在某些情况下它的运行速度不够快。显然我们想加快它的速度，但与此同时，当这种情况发生时，它会导致很多问题（或者如果它没有导致这些问题，那么两者是相关的）。与我们自己的功能最不相关的是内置的 Alert.show() 方法停止工作。通常会出现全屏透明框，但不会出现实际弹出窗口。我相信这归结于 Flex 将所有可用周期都分配给其他任务......但事实证明很难进行分析调查，所以我很高兴听到另一种解释。
需要澄清的是，Flex 的核心部分根本无法在这种情况下工作。我已经逐步完成了代码，例如在屏幕上添加了一个新元素，一切都发生了，并且在主显示画布上调用了 addChild() 方法......但随后该元素没有出现。如果我们随后禁用更新循环，该元素会突然出现。
因此，无论 Flex 是否应该运行完全相同的代码，它以某种方式阻塞都是一种奇怪的方式。正如我所说，即使是 Flex Alert.show() 方法也不起作用。
所有 Flash 内容都是逐帧执行的——Flash 执行一帧的代码，然后更新屏幕，然后等待下一帧更新。
当 Flash 无法跟上指定的帧速率时，所发生的只是在帧更新之间等待，而不是在帧更新之间等待，Flash 会尽可能快地完成它们，而不会在两者之间等待。所以唯一可见的区别是帧更新发生的频率较低。从来没有出于性能原因跳过代码、删除事件或跳过屏幕重绘的情况（除非您发现了新的错误）。
所以最有可能的罪魁祸首是，要么你的代码有一个非常依赖时间的问题（例如，期望两个计时器在同一帧上触发的代码），要么是其他一些被误诊的问题。（例如，可能有一个错误导致减速，而不是减速导致你的错误。）
我不太确定 Flex 是否有它自己的一些额外的性能处理。但是对于纯动作脚本来说，唯一会发生的事情是帧率会慢到爬行，一切都会正常发生，只是更慢。如果您堆叠大量透明或蒙版对象，您可能会遇到一些奇怪的行为，但这应该更明显。
而且我想告诉你用 Flex 制作游戏并不是一个好主意（只是因为框架的性能开销）有点晚了；）
我喜欢在 FLEX 3 (actionscript3) 中制作游戏，与 Flash CS3 相比，它实际上是非常方便的解决方案：良好的调试环境，没有麻烦。当然这取决于游戏风格哪个更好，如果你需要大量的图形你可能更喜欢 Flash，但是 Flex 允许你使用外部图像、组件等。注意我这里不是在谈论 Flex XML 项目。
回答您的性能问题：您可以使用例如旧的 MacOSX 机器来查看在非常慢的机器上会发生什么，一些解决方案是： - 当机器旧时移动对象超过 x++ y++ 像素 - 减少对象
你可以用计时器检测机器有多慢..