gwt - GWT 调度程序中的 scheduleFinally 和 scheduleDeferred 有什么区别？

Question

我无法在此线程中找到我的答案:

Using the GWT Scheduler

GWT Scheduler 类具有在浏览器事件循环返回后执行的 scheduleDeferred API。 scheduleFinally API 允许我在控件返回到浏览器事件循环之前执行代码。

如何决定我应该使用 scheduleDeferred 还是 scheduleFinally？是否有显示行为差异的代码示例？

Answer 1

要理解这一点，您需要先了解事件循环的基本概念。当您编写要在浏览器中运行的代码时，您不会编写此循环 - 它存在于浏览器中，等待用户执行某事。当某些事情发生时(鼠标事件、键盘事件、AJAX 调用返回、setTimeout 关闭)，循环会调用您的代码，并让您按照自己的意愿进行处理。

首先，我们有 scheduleDeferred，这是一种通知浏览器我们有一些代码要运行的方法很快，但不是在这个循环中。这是一种让浏览器重新获得控制权、呈现一些内容，然后再次将控制权交给您的简便方法。这有助于将计算分解成几个 block 以避免任何“长时间运行的脚本”错误，或者可以是动画的早期尝试(注意:使用浏览器中的实际 requestAnimationFrame api，或 AnimationScheduler.get() .requestAnimationFrame 在 GWT 中而不是这个)。

接下来，循环中有两个有趣的地方，您可能有想要运行的代码 - 要么在浏览器将控制权转移给您时，要么在您再次返回控制权之前。在这两个中，结尾通常更有趣:scheduleFinally。这允许您在当前事件循环内部运行一些代码，但直到它结束。 CssResource 在它的 ensureInjected() 方法中使用这个策略——当你运行这个方法的几个不同的调用时，而不是多次戳 DOM，它使用 scheduleFinally 将它们全部分批并在事件循环结束时运行它们。

最后一个，每个事件循环的开始由另一个方法管理——scheduleEntry。从理论上讲，这可以与 finally 结合使用，以重新实现 AngularJS 绑定(bind)连接的简单版本。

//event comes in to GWT from the $entry method, and follows these steps
try {
  // 1. run registered scheduleEntry calls

  // 2. run the current event or callback that the browser called us for
} finally {
  // 3. run registered scheduleFinally calls
}

在这些步骤中对 scheduleDeferred 的任何调用都会添加对 next 事件循环的调用，作为 #2 的一部分运行。