Chrome: ¿tiempos de espera/intervalo suspendidos en pestañas en segundo plano?
Estaba probando la precisión del setTimeoutuso de esta prueba . Ahora me di cuenta de que (como era de esperar) setTimeoutno es muy preciso, pero para la mayoría de los electrodomésticos no es dramáticamente inexacto. Ahora, si ejecuto la prueba en Chrome y la dejo ejecutar en una pestaña en segundo plano (es decir, cambio a otra pestaña y navego allí), vuelvo a la prueba e inspecciono los resultados (si la prueba finalizó), cambian drásticamente. Parece que los tiempos de espera han estado corriendo mucho más lento. Probado en FF4 o IE9, esto no ocurrió.
Entonces parece que Chrome suspende o al menos ralentiza la ejecución de JavaScript en una pestaña que no tiene foco. No pude encontrar mucho en Internet sobre el tema. Significaría que no podemos ejecutar tareas en segundo plano, como por ejemplo verificar periódicamente en un servidor usando llamadas XHR y setInterval(sospecho que al ver el mismo comportamiento setInterval, escribiré una prueba si tengo tiempo).
¿Alguien ha encontrado esto? ¿Habría una solución para esta suspensión/desaceleración? ¿Lo llamarías un error y debería presentarlo como tal?
Recientemente pregunté sobre esto y es comportamiento por diseño. Cuando una pestaña está inactiva, solo se llama a la función como máximo una vez por segundo. Aquí está el cambio de código .
Quizás esto ayude: ¿ Cómo puedo hacer que setInterval también funcione cuando una pestaña está inactiva en Chrome?
TL;DR: utilice trabajadores web .
Existe una solución para utilizar Web Workers, porque se ejecutan en procesos separados y no se ralentizan.
He escrito un pequeño script que se puede usar sin cambios en el código; simplemente anula las funciones setTimeout, clearTimeout, setInterval, clearInterval.
Solo inclúyelo antes de todo tu código.
http://github.com/turuslan/HackTimer
Reproducir un sonido vacío obliga al navegador a conservar la interpretación. Lo descubrí después de leer este comentario: ¿Cómo hacer que JavaScript se ejecute a velocidad normal en Chrome incluso cuando la pestaña no está activa?
Con la fuente de ese comentario encontrada aquí :
El experto de Chromium también aclaró que la limitación agresiva se desactivará automáticamente para todas las pestañas de fondo que "reproducen audio", así como para cualquier página donde haya una "conexión websocket activa".
Necesito rendimiento ilimitado bajo demanda para un juego de navegador que usa WebSockets, así que sé por experiencia que el uso de WebSockets no garantiza un rendimiento ilimitado, pero según las pruebas, reproducir un archivo de audio parece garantizarlo.
Aquí hay dos bucles de audio vacíos que creé para este propósito, puedes usarlos libremente y comercialmente: http://adventure.land/sounds/loops/empty_loop_for_js_performance.ogg http://adventure.land/sounds/loops/empty_loop_for_js_performance.wav
(Incluyen ruido de -58db, -60db no funciona)
Los juego, según demanda del usuario, con Howler.js: https://github.com/goldfire/howler.js
function performance_trick()
{
if(sounds.empty) return sounds.empty.play();
sounds.empty = new Howl({
src: ['/sounds/loops/empty_loop_for_js_performance.ogg','/sounds/loops/empty_loop_for_js_performance.wav'],
volume:0.5,
autoplay: true, loop: true,
});
}
Es triste que no exista un método integrado para activar o desactivar el rendimiento completo de JavaScript de forma predeterminada; sin embargo, los mineros criptográficos pueden secuestrar todos sus subprocesos informáticos utilizando Web Workers sin ningún aviso.
