什么应该被称为“长时间运行的任务”？在 SwingWorker 线程中执行？
我知道如何使用 SwingWorker 线程，但我仍然没有精确的标准来决定何时使用或不使用。
I/O 似乎很明显，但是对潜在的大型集合进行操作的方法又如何呢？
标准可以是实际运行时间，但是什么样的数字（以毫秒为单位）才符合条件呢？
I know how to use SwingWorker threads, but I still don't have precise criteria to decide when to use one or not.
I/O seems obvious, but what about methods operating on potentially large collections ?
A criterion could be the actual running time, but what kind of number (in ms) would qualify ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
重要的是 UI 的响应能力如何。
Jef Raskin（Mac UI 名人）表示最大延迟应限制在 50 毫秒。 RISC OS 指南称 100 ms。按钮点击大约需要 50 毫秒，因此如果您想在发布时执行操作，则需要快速执行操作，因为用户模型通常是单击执行操作。超过 140 毫秒，不仅会出现一些无响应，而且 UI 响应似乎与用户操作断开连接（例如，请参阅 O'Reilly 的 Mind Hacks）。
250-350 毫秒，（普通）用户会认为出现了问题。
另一方面，您需要 8 fps（并且包括渲染）才能产生动画（例如）滚动的错觉。你知道游戏玩家有多喜欢他们的 fps。
然而，我更喜欢或多或少能工作的软件，而不是不可用的最佳软件。话虽如此，在编辑过程中让 Opera 锁定几分钟并敲打光盘并不让我高兴。
The important thing is how responsive is the UI.
Jef Raskin (of Mac UI fame) said that the maximum delay should be limited to 50 ms. RISC OS guidelines said 100 ms. Button clicks are about 50 ms, so if you want to act on release you need to act fast as the user model is generally click for action. Above 140 ms, not only does it some unresponsive but UI responses appear to disconnected from user actions (see, for instance, O'Reilly's Mind Hacks).
250-350 ms and the (normal) user will think something has gone wrong.
On the other side of things, you need 8 fps (and the includes rendering) to have the illusion of animation (for instance) scrolling. And you know how gamers like their fps.
However, I prefer software that more or less works than best possible software that is not available. Having said that, having Opera lock up for a few minutes whilst it hammered the disc in the middle of this edit did not please me.
对我来说就是 1 秒。
如果您的处理时间超过这个时间，您的 UI 将冻结。在这种情况下，最好显示“繁忙”的绘画或进度条。
您希望等待您使用的任何应用程序响应多长时间？假设您打开 IDE 或 MS-Word 或任何其他。如果您注意到，大多数时候，当应用程序加载时，即使文档/项目/任何内容足够小，可以在 2 秒内打开，也会显示进度条或其他一些动画。
For me it would be 1 s.
If your processing takes more than that, your UI will freeze. In that situation is much better to show a "busy" paint, or progress bar.
How much time would you like to wait for ANY application that you use, become responsive? Let's say you open your IDE or MS-Word or anyother. If you notice most of the times, when the application is loading, a progress bar or some other animation shows, even when the document/project/whatever is small enough as to be opened in 2 s.
没有具体的数字，而是应用程序应该做什么以及 GUI 需要如何响应的问题。最好的方法是做一些测试，没有人能为你回答这个问题。 （尽管评论可能对您确定需要进行哪些测试很有用）
There is not a specific number, it is a matter of what the app is supposed to do and how responsive the gui needs to be. Best approach is to do some testing, no one can answer this for you. ( though comments may be of great use to you in determining what testing you need to do )
长时间运行的任务是指足够长的任务，让用户能够注意到重绘 UI 时出现的故障或延迟。
设置标签的文本可能不是“长时间运行”，但只需花费几毫秒将图像绘制到屏幕外位图中，就可能会延迟 UI 重绘足够长的时间，从而引起人们的注意。
A long running task would be anything long enough for the user to notice glitches or delays in redrawing the UI.
Setting the text of a label is probably not "long running", but just taking a few milliseconds to draw an image into an offscreen bitmap may delay the UI redrawing long enough to be noticeable.
基本上，如果您无法预测处理需要多长时间，那么将其放在单独的线程中是一个好主意，因为即使在数据错误等极端情况下，它也能让您的应用程序保持响应。好的候选人是
但为什么不简单地制定一个规则，如果它有一个循环（任何 for/while）那么它就进入 SwingWorker 中呢？
Basically if you cannot predict how long the processing will take it will be a good idea to put it in a separate thread as it will keep you applciation responsive even in extreme cases with bad data etc. Good candidates are
But why not just simply make a rule, if it has a loop (any for/while) then it goes in a SwingWorker?