4

当此应用程序的用户对字段进行更改时，需要在其他字段中进行大量更改。通常，即使使用优化的脚本，浏览器也会在 IE 中阻止用户输入超过 1 秒。为了阻止发生，我这样做：

var i = 100;
GetTextInputs().filter('[' + name + ']').each(function()
{    
    setTimeout("DoWork('" + this.id + "', '" + v + "', '" + name + "');", i);
    i += 25;
});

这对我来说有点骇人听闻，但效果很好。

  • 这种方法有什么问题吗？
  • 或者，有没有更好的方法？
4

3 回答 3

3

现在，我认为你实际上没有太多选择。

我没有检查你的函数是否正常工作，但使用 setTimeout 并将工作分成小块可能是要走的路。


不过，将来您可能会为此使用Web Workers；引自Mozilla 的网页：

Worker 为 Web 内容提供了一种在后台线程中运行脚本的简单方法。创建后，工作人员可以通过将消息发布到创建者指定的事件处理程序来向生成任务发送消息。

工作线程可以在不干扰用户界面的情况下执行任务。此外，它们可以使用 XMLHttpRequest 执行 I/O（尽管 responseXML 和 channel 属性始终为空）。

和 ：

工作者有用的一种方法是允许您的代码执行处理器密集型计算而不阻塞用户界面线程。

这些已经在 Firefox 3.5 中可用，而且我认为它们也是由 Google Gears 提供的——但它们还没有被广泛使用，所以你可能不应该在几年前使用它们，至少对于“任何人” ：-（

于 2009-08-28T18:30:40.193 回答
3

可能会出现严重错误的一件事是，拥有过多的高频计时器会 [讽刺地] 使 ui 反应迟缓/反应迟钝。来自http://googlecode.blogspot.com/2009/07/gmail-for-mobile-html5-series-using.html：

使用低频定时器——延迟一秒或更长的定时器——我们可以创建许多定时器，而不会显着降低任一设备的性能。即使安排了 100 个计时器，我们的应用程序的响应速度也没有明显降低。然而，对于高频定时器，情况恰恰相反。每 100-200 毫秒触发几个计时器足以让我们的 UI 感觉迟缓。

于 2009-08-28T18:55:05.870 回答
1

为了获得更好的用户体验，我大量使用 setTimeout，以便尽可能多的工作可以在后台进行。

它在 Windows 中类似于让一切都在主事件线程上运行。让应用程序脱离该线程需要做更多的工作，但最终用户将获得更好的体验。

唯一可能出错的是，如果您在 setTimeout 中实际使用变量之前进行了变量更改，那么操作可能会有所不同。

因此，如果您看到一些奇怪的行为，您至少可以意识到这一点。理想情况下，您的设计不应该允许它，但它可能会发生。

于 2009-08-28T18:34:57.347 回答