在过去的几周里，我一直在使用使用blazeDS连接到J2EE后端的Flex前端构建原型应用程序。
原型是一个学习flex的实验，看看它是否适用于需要通过pub子类型模型进行大量动态更新（即每秒大于20秒）的复杂交易应用程序。
在一些轻量级性能测试中，我很明显需要使用多个线程来确保从服务器接收大量更新时UI保持稳定。一切顺利，直到我发现flex有一个单线程编程模型！
从一个快速的谷歌看起来好像有很多黑客可以实现线程般的行为。
我相信很多人一定遇到过类似的问题。人们可以让我知道：
答案 0 :(得分：12)
我见过非常密集的交易者桌面类型的Flex应用程序，它们在Flex的单线程模型中运行良好。原因是内部Flex应用程序使用异步网络IO。因此，在您发出请求时，UI不会阻止。你可能会遇到BlazeDS的限制，也许应该考虑使用RTMP的东西（比如LCDS）。 RTMP是一种更有效的协议，用于将大量数据流式传输到客户端。还有一些方法可以优化客户端事件处理和呈现代码，这样就不会让UI陷入困境。 Christophe Coenraets在做这类事情时有一些很好的演示：http://coenraets.org/blog/?s=trader+desktop
您尝试做的事情当然可以通过Flex实现，并且有些人已经成功完成了它。
但是在bugs.adobe.com上有一个打开功能请求： https://bugs.adobe.com/jira/browse/ASL-23
答案 1 :(得分：1)
如果您在使用UI的稳定性时遇到问题，那么很可能是您没有在Flex中正确使用UIComponent模型。它基于失效/验证模型工作，该模型允许延迟更新，直到UI线程准备重新绘制屏幕为止。这里有一个很棒的演示文稿：
http://tv.adobe.com/#vi+f15384v1002
即使你的Flex应用程序在这些优化之后仍然无法每秒处理20-30个UI更新，那么人们可以真正理解数据以这个速率发生变化吗？我认为只要完整的数据集可用于计算和分析，每秒刷新一次UI就足够了。
答案 2 :(得分：1)
我正在做一些非常类似的事情，而且限制不在于单个线程，它实际上是所有正在发回的数据并试图实时更新。事实是，你不需要实时，或者至少你可以弯曲“实时”的真正含义。
在服务器端，不是在上次推送后立即推送数据，而是让它等待一秒钟，看看是否有更多更新。如果是，您可以推送更新的数据。没有理由立即返回“实时”数据，如果毫秒之后您将返回另一个更新。我讨厌说投票是去这里的方式，因为它不是，但伪投票或延迟响应是要走的路。把它作为火车拉进车站，然后让一个人放松。停下来稍等一下然后让50更有效率。
答案 3 :(得分：1)
要回答有关Silverlight的问题，它确实允许多个theads。
答案 4 :(得分：0)
不确定您是否已经看过这个，但您可以使用PixelBender有效地获得多线程Flash应用。请参阅Using Pixel Bender to do heavy lifting calculations, makes Flash Player multi-thread。
祝你好运！涓
答案 5 :(得分：0)
为什么abobe实施单一的 线程模型？
Adobe没有。 Macromedia做到了。单线程模型是虚拟机的核心。他们必须从头开始编写Actionscript VM以引入线程模型。
答案 6 :(得分：0)
如果您的UI在发送或接收发布/订阅消息期间锁定，则可能是由数据的消息（de）/序列化引起的。诀窍是无限制地限制有效载荷大小。您真的是否需要刚刚发送的所有对象中的每个字段？
同样，尽量不要从客户端发送对象 - ＆gt;您不需要的服务器。通常，只发送一个标识对象的键而不是整个对象本身更有效。
此外，您可以通过仅将数据对象发送到将在屏幕上呈现的客户端（及其各自的字段）来实现性能改进，并将其他成本推迟到实际需要之前。 （即，数据分页）
LCDS提供了开箱即用的功能，但是，对于BlazeDS，您可以使用dpHibernate或Gilead。
（披露：我在dpHibernate团队中）