VueJS 在不活动的浏览器选项卡上阻止 activity
VueJS block activity on not active browser tab
我有一个用 Typescript 和 VueJS 编写的网络应用程序，它执行一组任务（ajax 请求）并跟踪整个过程（并一个接一个地执行任务）我使用 Vue 实例作为总线通知组件之间的变化。
如果用户打开一个新的浏览器选项卡，该过程将停止。如果用户回来，则该过程恢复。
Firefox 和 Chrome 中存在该问题。
我在我的代码中输入了一个简单的 window.setInterval 以每 2 秒记录一次 'Hello' 并且......令人惊讶的是我每 2 秒有一个 'Hello' 而没有任何时间 'hole'。
我在 github 中看到一个类似情况的非常老的问题：https://github.com/vuejs/Discussion/issues/76 但似乎太老了。
我希望该过程不会停止，而是继续进行而不会中断..
https://developers.google.com/web/updates/2017/03/background_tabs
Background tabs can have a dramatic negative effect on browser performance, especially on battery life. To mitigate this, Chrome has been placing various restrictions on background tabs for the last several years. Recently there’s been a number of efforts to make further improvements, and this document gives an overview of the Chrome policy. This document focuses on describing current policies in Chrome 57. Long-term strategy and further plans can be found in this document.
https://www.chromestatus.com/feature/6172836527865856
As an intervention we want to limit how much CPU a background page is allowed to use and to throttle timer queues when this limit is violated. Current target is that background page CPU load level should be under 1%.
我有一个用 Typescript 和 VueJS 编写的网络应用程序，它执行一组任务（ajax 请求）并跟踪整个过程（并一个接一个地执行任务）我使用 Vue 实例作为总线通知组件之间的变化。 如果用户打开一个新的浏览器选项卡，该过程将停止。如果用户回来，则该过程恢复。
Firefox 和 Chrome 中存在该问题。 我在我的代码中输入了一个简单的 window.setInterval 以每 2 秒记录一次 'Hello' 并且......令人惊讶的是我每 2 秒有一个 'Hello' 而没有任何时间 'hole'。 我在 github 中看到一个类似情况的非常老的问题：https://github.com/vuejs/Discussion/issues/76 但似乎太老了。
我希望该过程不会停止，而是继续进行而不会中断..
https://developers.google.com/web/updates/2017/03/background_tabs
Background tabs can have a dramatic negative effect on browser performance, especially on battery life. To mitigate this, Chrome has been placing various restrictions on background tabs for the last several years. Recently there’s been a number of efforts to make further improvements, and this document gives an overview of the Chrome policy. This document focuses on describing current policies in Chrome 57. Long-term strategy and further plans can be found in this document.
https://www.chromestatus.com/feature/6172836527865856
As an intervention we want to limit how much CPU a background page is allowed to use and to throttle timer queues when this limit is violated. Current target is that background page CPU load level should be under 1%.