一些更新：除了监听事件和使用绑定之外，我们在应用程序中没有做任何事情......意思是，没有 ChangeWatchers，没有手动轮询......只是等待事件。我们一直连接到 FMS，因此有一些开销，但它是最小的。绑定在 Flex 中的效率不是很高，我们发现直接将 [Bindable] 元数据关键字添加到类（量很大，有很多类）是不好的。我们并没有做太多这方面的工作，但这是从您的应用中挤出更多性能的一种方式。如果您使用 [Bindable(event="usersUpdated")] 那么您可以控制绑定，并且它只会在您从类中的函数中 dispatchEvent(new Event("usersUpdated")) 时触发，即您的'用户'的设置器。
任何在 Flex 或 AIR 中使用过 System.gc() 的人都会告诉您 Flex 垃圾收集是个笑话。这是一个部分实现的功能，没有人信任它。这也有技巧......调用它两次，等待一帧，再次调用它。它可能会清理您的旧对象，但不要交叉手指……Flex 会做它想做的事。
此外，使用临时对象来减少触发的绑定数量。代替...
myUser.location = 新位置（）；myUser.location.state = "CO"; myUser.location.city = "丹佛";
做...
var tempLoc：位置=新位置（）；tempLoc.state =“一氧化碳”；tempLoc.city = "丹佛"; myUser.location = tempLoc；
前者会触发 3 个绑定到任何绑定到 location.* 的东西，而后者应该只触发 1 个绑定（实际上，由于 Flex 处理它的方式，它通常是额外的。）
除非您在视觉丰富的应用程序中拥有大量绑定，否则绑定不会杀死您的应用程序……绑定和渲染似乎是 Flex 最慢的工作。
另一个有趣的事情是：在 Flex Builder 中创建一个全新的 Flex3 应用程序并在浏览器中运行它。我们的测试表明，MacBookPro 上的 CPU 保持在 8-10% 之间（当应用程序空闲且浏览器窗口隐藏时）。 我们的应用程序现在以大约 20% 的速度稳定运行，虽然它为了处理视图更改等而峰值更高，但它总是回到接近 20% 的水平。我们最初的担忧是内存泄漏或某些东西失控，这会使 CPU 占用非常高，并使其徘徊在 40-50% 左右（同样，在 MBP 上……都是相对于这台机器而言的）。我们去掉了所有对 Degrafa 的引用，虽然我们注意到性能有了很大的提升，但这并不能说明一切。不过，空的 Flex 应用程序很有启发性 - Flex 本身始终占用 8-10% 的 CPU，即使在空闲时也是如此。
还有一个发现……如果使用 Mate，请小心处理切换视图的方式。通过在 MXML 中使用注入器和绑定，可以很容易地获得可用的资产并在不使用它们时隐藏和禁用它们，但 Flex 在隐藏/禁用事物方面并不是很聪明。最好即时创建视图，并在完成后销毁它们。即使初始创建可能需要更多时间，并且视图之间的等待时间也会更长，使用一些显示魔法（进度条、旋转磁盘等）来指示视图正在切换，等待视图上的 creationComplete，然后淡入其中。
此外，对于视觉丰富的应用程序，请远离 ViewStack。管理您自己的堆栈。
到目前为止，这个线程已经讨论了任何语言共有的基本性能问题，但 Flex 在许多方面都是一个非常特别的小男孩（“特别”并不总是被认为是积极的事情）。有无数的陷阱，因为它构建在一个非常可视化的平台上，但它是为 RIA 构建的，所以虽然 Flash Player 可以优化视频、动画等，但它不会优化 Flex 应用程序。不要期望 Flex 应用程序的性能与 Flash 应用程序相同。AS2 和 AS3 的 AVM（ActionScript 虚拟机）之间也有很大的不同。
这只是触及了 Flex 应用程序的性能问题和潜在收益的表面。这是一门黑暗的艺术，很容易看出原因。
代码，忍者。