Adobe Flex 移动后台进程
Flex 中多线程的最佳解决方案是什么，我注意到如果我在 Flex 中播放 mp3 并同时执行其他操作，则最终会出现问题，要么歌曲停止播放，要么 UI 挂起大约一秒钟。它没有我希望实现的流畅响应。如果可能的话我想调用一个多线程java类来做一些客户端后端处理。我只是不知道这是否可能。任何见解将不胜感激，我坚持这一点。
-菲尔
What is the best solution for multi threading in flex, I notice if I play a mp3 in flex and do something else at the same time something ends up giving out, either the song stops playing or the UI hangs for about a split second. It doesn't have that fluid response that I am looking to achieve. If possible I would like to call a multi threaded java class to do some of the client-side end back end processing. I just don't know if that is possible. Any insight would be greatly appreciated I am stuck on this one.
-Phil
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Flex/Flash 本身不支持多线程 - Adobe 一直认为多线程对于大多数潜在的 Flex 应用程序来说并不是必需的，而且只会增加普通 Flex 开发人员的复杂性。
我自己在寻找解决方案时只找到了一些片段，其中要同时完成的任务在逻辑上被切成更小的片段，然后逐片段运行它们，让 UI 获得中间的时间片。它可能对某些人有用，但不能解决您的问题。
现在到 Java - 使用本机进程 api 可以使其工作。 Java 进程将接管处理的某些部分，您将控制其对输入/输出流的工作写入和读取，这些输入/输出流在 Java 进程和 Flex 应用程序之间连接。另一种可能性可能是进程间套接字通信（在本机进程 api 出现之前我自己做了 - 有效！）
Flex/Flash alone don't support multithreading - Adobe keeps argumenting that multithreading is not necessary for most of potential flex applications and would just increase complexity for the average flex developer too much.
Looking for solutions myself I have only found snippets where the task to be done simultanously gets logically cut into smaller pieces, then you run them piece by piece, letting UI get time slices in between. It might work for some but is no solution to your problem.
Now to Java - using the native process api could make it work. Java process would take over some part of the processing and you would control its working writing to and reading from input/output streams which gets connected between java process and flex app. Another possibility could be inter-process socket communication (did it myself before native process api was there - works!)
如果用户界面挂起，您就会遇到另一个问题。在我看来，您似乎正在循环某种数据来产生这种“滞后”。您可以做的就是更好地格式化数据，这样就不会遇到这种情况。或者查看挂起发生时运行的流程并更好地优化它。
If the UI is hanging you have another issue. It seems to me like you are looping through some sort of data to make this "lag". What you can do is format the data better so you don't run into this. Or look into your process that you run when the hanging happens and optimize it better.
Flex/Flash 没有阻塞方法，因此不需要线程，只需在计时器或输入帧上调用函数，并确保它在 25 毫秒左右的时间内产生。至于速度，Java（运行在 Android 的“Dalvik”VM 中）也好不了多少……C 是获得终极速度的唯一选择。
Flex/Flash has no blocking methods and so doesn't need threading, just call a function on a timer or enterframe, and make sure it yields in under 25ms or so. As for speed, Java (running in Android's 'Dalvik' VM ) is not a lot better... C is the only option for ultimate speed.
这是一个相当完整的“Greean Thread”库 - http://blog.generalrelativity.org /actionscript-30/green-threads/
我发现它很有用，因为无论 Tom 的观点如何，线程绝对是经常需要的东西，但尚未得到正确支持（还？？）
Here is a rather complete 'Greean Thread' lib - http://blog.generalrelativity.org/actionscript-30/green-threads/
I have found it useful, as irrespective of Tom's views Threading is most definitely often a needed things that is not supported properly (yet??)
另请记住，调试播放器的行为与标准播放器非常不同，并且（一个单独的问题）在调试会话期间，性能关键代码的速度明显下降......只相信浏览器插件，非调试版本，在浏览器中运行，而不是调试。这是唯一可靠的测试。我发现仅通过更改为发布播放器（极端情况）即可将速度提高 25-30 倍。我以为我有一个主要的性能问题，但实际上没有:)
Also bear in my mind that the debug player behaves very differently from the standard player, and (a separate issue) that during a debug session, significant slowdowns can be apparent with performance critical code... Only believe the browser plugin, non-debug version, running in a browser, not debugging. That is the only reliable test. I have seen speed up of 25-30x just by changing to the release player (extreme case). Thought I had a major performance problem, but actually didn't :)