utilizados usados tipos principales navegadores mas los internet caracteristicas javascript android ios mobile javascript-events

javascript - usados - ¿Hay algún estándar para los navegadores web de dispositivos móviles en términos de hilo de dormir?



safari (1)

Dado el siguiente jsFiddle, que es un simple incremento de contador

http://jsfiddle.net/C93ms/6/

.... si visito la url de arriba usando un dispositivo móvil (teléfono inteligente o tableta por razones de argumento), el contador comienza a incrementarse como era de esperar siempre que haya soporte de JavaScript, entonces parece que si presiono el botón "Inicio" ", o haga clic en el botón de encendido una vez para apagar la pantalla (pero mantenga el teléfono encendido), entonces la secuencia de comandos se detendrá y el contador dejará de aumentar. Espero que esto ocurra y agradezco las razones por las que reservar la duración de la batería es muy importante en un dispositivo móvil, por lo que tiene sentido que el hilo de la interfaz de usuario duerma, o similar. Una vez que vuelves a visitar el navegador, el contador continúa incrementándose. En el mundo real, supongo que los sitios web que determinan el período de tiempo de espera usando JavaScript no tendrán tiempo de espera a pesar del período de inactividad.

También estoy asumiendo que esto variará según el dispositivo, el firmware y el software, lo que intento averiguar aquí es si existe un enfoque estándar o un comportamiento predeterminado en los marcos de desarrollo móviles para esto y cualquier forma de coherencia en la forma en que dispositivos se comportan.

No estoy del todo seguro de haber hecho una buena pregunta aquí, pero he tenido problemas para encontrar información 100% relevante de SO, o no sé exactamente cuál es la pregunta que debo hacer al buscar.

Gracias


Ningún marco de JavaScript puede detener la ejecución o cambiar el comportamiento del motor JS subyacente. No podrán influir en setTimeout .

Sin embargo, el comportamiento se estandariza en el borrador actual de HTML5 en la interfaz WindowTimers (lo que no significa que se implementó así). Ahí encontrarás la nota:

Esta API no garantiza que los temporizadores se ejecutarán exactamente a tiempo. Se esperan demoras debido a la carga de la CPU, otras tareas, etc.

y, aún más explícito:

9) Opcionalmente, espere otro tiempo definido por el agente de usuario.

Nota: Esto está diseñado para permitir que los agentes de usuario rellenen los tiempos de espera según sea necesario para optimizar el uso de energía del dispositivo. Por ejemplo, algunos procesadores tienen un modo de baja potencia donde la granularidad de los temporizadores se reduce; en tales plataformas, los agentes de usuario pueden reducir la velocidad de los temporizadores para ajustarse a este cronograma en lugar de requerir que el procesador use el modo más preciso con su mayor uso de energía asociado.

Puede ver ese comportamiento también en los navegadores de escritorio, que implementan un tiempo de espera mínimo de 4 ms (lea la explicación en MDN ). Entonces, es legítimo que cada dispositivo / software / firmware detenga tal ejecución si solo piensan que sería necesario.

Es posible que también desee echarle un vistazo al borrador de WindowAnimationTiming .

Y si usa setInterval / setTimeout en animaciones / relojes / etc, siempre mida el tiempo realmente transcurrido con los objetos Date (por ejemplo, a través de Date.now() ).