No dude en señalar si mi siguiente comprensión es incorrecta: suponga que nuestra frecuencia de actualización de pantalla es de 60 Hz (sé que no siempre es el caso, pero supongamos que es de 60 Hz), por lo que la página web actualizará la pantalla 60 veces cada segundo si todo va bien. Eso significa que el renderizado está ocurriendo en un intervalo de 16 ms (aproximadamente), ¿verdad? Entonces, cualquier cosa en nuestro JavaScript que tarde más de 16 ms en ejecutarse causaría una experiencia de bloqueo para el usuario. Entonces mi pregunta es:
handleScroll y tardará 100 ms en ejecutarse de principio a fin. y lo agregamos a addEventListener('scroll', handleScroll) . ¿Es cierto que cada vez que se activa un evento de scroll , el usuario experimenta una experiencia de bloqueo ya que se omiten/eliminan 6 fotogramas en el ciclo de renderizado? porque 100ms / 16ms = 6.25? Sé que una tarea lleva mucho tiempo en el hilo principal, detendrá todas las demás tareas hasta que finalice, pero aquí quería obtener algunos análisis cuantitativos o metodologías para el análisis cualitativo para un problema de rendimiento de este tipo. específicamente, quería entender (aproximadamente) cuántos fotogramas se eliminarán con una devolución de llamada de este tipo (si la frecuencia de actualización es de 60 Hz)requestAnimationFrame le dice al navegador que ejecute la devolución de llamada antes de que se procese el siguiente cuadro, por lo que vi que la gente mencionó que puede evitar que se eliminen cuadros para la animación. Pero no tengo claro cómo va a ayudar con eso, ya que la devolución de llamada que pasamos a requestAnimationFrame aún se ejecutará hasta completarse, por lo que si esa devolución de llamada demora más de 16 ms, inevitablemente perderemos el siguiente cuadro, ¿verdad?sí, en ese caso estaría disparando handleScroll a mucho menos de 60 fps; dependiendo de lo que esté haciendo su devolución de llamada handleScroll , sus usuarios pueden experimentar algunos bloqueos.
requestAnimationFrame hará todo lo posible para mantener 60 fps, pero no garantiza 60 fps. Potencialmente, puede funcionar mucho más lento según la CPU, la GPU, la memoria y otras limitaciones disponibles.
Tenga en cuenta que incluso cuando se ejecuta a> 60 fps, eso le brinda (como señaló) un presupuesto de cuadro de 16-17 ms para realizar sus acciones de devolución de llamada.
Entonces, si su devolución de llamada tarda 100 ms en ejecutarse, entonces no obtendrá una animación fluida de 60 fps, incluso usando requestAnimationFrame . Las herramientas de desarrollo de rendimiento de Chrome pueden ayudarlo a identificar qué está causando el retraso en sus animaciones, pero depende de usted optimizar su devolución de llamada para que se ejecute en menos de 17 ms para evitar la pérdida de cuadros.
Consulte este artículo para obtener un desglose más detallado.
Hay dos advertencias en sus suposiciones, la primera es que tiene un presupuesto de 16 ms (en 60 hercios) para gastar, lo cual no es correcto ya que el navegador ha realizado algún tipo de cálculo interno para dibujar el siguiente cuadro, lo que lleva bastante tiempo alrededor de 6 ms en Chrome, por lo que nosotros tener alrededor de ~ 10 ms como se explica aquí
La segunda suposición es que los dispositivos tendrán una frecuencia de actualización de 60 Hz , que quedará obsoleta en un futuro cercano a medida que más dispositivos usen frecuencias de actualización altas para mejorar la fluidez del desplazamiento, o incluso reducir la frecuencia de actualización para ahorrar batería; así que esas no son suposiciones seguras .
Por cierto, generalmente el principio es el mismo, si una tarea lleva mucho tiempo en el subproceso principal , detendrá todas las demás tareas hasta que finalice, demostrémoslo en acción:
la función de lag simula una tarea de uso intensivo de la CPU que tarda un tiempo en ejecutarse; la función raf moverá los 200px al programar un requestAnimationFrame recursivo a sí mismo que cambiará la propiedad translateX del cuadro; y finalmente tenemos un laggyRaf que usa la función de lag para simular una tarea larga;
const box = document.querySelector('.box'); const x_move_distance = 200; function lag (delay = 1000) { const time = Date.now(); while ( Date.now() < time + delay ) { // waits } } function moveBox ( position ) { box.style.transform = `translateX(${position}px)`; } let counter = 0; function raf() { moveBox(counter); if ( counter < x_move_distance ) { requestAnimationFrame(raf); counter++; } } let counter2 = 0; function laggyRaf() { moveBox(counter2); lag(100); //100 ms seconds extra lag if ( counter2 < x_move_distance ) { requestAnimationFrame(laggyRaf); counter2++; } } .box { width: 100px; height: 100px; background: blue; } <div class='box'></div> <button onclick="counter = 0; raf()">start raf animations</button> <button onclick="lag()">start cpu-intensive task</button> <br /> <button onclick="counter2 = 0; laggyRaf()">start laggy animations</button>