A primera vista, parece que generar una estimación precisa del tiempo debería ser bastante fácil. Después de todo, el algoritmo que produce la barra de progreso conoce todas las tareas que necesita hacer antes de tiempo ... ¿no?

En su mayor parte, es cierto que el algoritmo de origen sabe lo que debe hacer antes de tiempo. Sin embargo, fijar el tiempo que llevará realizar cada paso es una tarea muy difícil, si no prácticamente imposible.

Todas las tareas no son iguales

La forma más simple de implementar una barra de progreso es usar un gráfico representación del contador de tareas. Donde el porcentaje completado simplemente se calcula como Tareas completadas / Número total de tareas . Si bien esto tiene sentido lógico desde el principio, es importante recordar que (obviamente) algunas tareas tardan más en completarse.

Considere las siguientes tareas realizadas por un instalador:

1. Crear estructura de carpetas.
2. Descomprimir y copiar 1 GB de archivos.
3. Crear entradas de registro.
4. Crear entradas de menú de inicio.

En este ejemplo, los pasos 1, 3 y 4 se completarían muy rápidamente, mientras que el paso 2 tomaría algún tiempo. Así que una barra de progreso trabajando en un conteo simple saltaría al 25% muy rápido, se paralizaría un poco mientras el paso 2 estaba funcionando y luego saltaría al 100% casi de inmediato.

Este tipo de implementación es bastante común entre las barras de progreso porque, como se indicó anteriormente, es fácil de implementar. Sin embargo, como puede ver, está sujeto a tareas desproporcionadas que sesgan el porcentaje de progreso real en relación con el tiempo restante.

Para solucionar esto, algunas barras de progreso pueden usar implementaciones donde los pasos son ponderados. Considere los pasos anteriores donde se asigna un peso relativo a cada paso:

1. Crear estructura de carpetas. [Peso = 1]
2. Descomprime y copia 1 GB de archivos. [Peso = 7]
3. Crear entradas de registro. [Peso = 1]
4. Crear entradas del menú de inicio. [Peso = 1]

Usando este método, la barra de progreso se moverá en incrementos de 10% (como el peso total es 10) con los pasos 1, 3 y 4 moviendo la barra 10% al finalizar y paso 2 moviéndolo 70% Aunque ciertamente no es perfecto, métodos como este son una forma sencilla de agregar un poco más de precisión al porcentaje de la barra de progreso.

Los resultados anteriores no garantizan el rendimiento futuro

Considere un ejemplo simple de que le pida que cuente hasta 50 mientras Utilizo un cronómetro para cronometrarte. Digamos que cuentas hasta 25 en 10 segundos. Sería razonable suponer que contarás los números restantes en 10 segundos adicionales, por lo que una barra de progreso que siga esto mostraría un 50% de compleción con 10 segundos restantes.

Sin embargo, cuando tu cuenta llegue a 25, empiezo a lanzar pelotas de tenis a ti. Probablemente, esto romperá tu ritmo a medida que tu concentración se haya movido de números estrictamente contables a esquivar bolas arrojadas en tu camino. Suponiendo que pueda continuar contando, su ritmo se ha ralentizado un poco. Así que ahora la barra de progreso todavía se está moviendo, pero a un ritmo mucho más lento con el tiempo estimado restante en reposo o en realidad subiendo más.

Para un ejemplo más práctico de esto, considere la posibilidad de descargar un archivo. Actualmente está descargando un archivo de 100 MB a una velocidad de 1 MB / s. Esto es muy fácil de determinar el tiempo estimado de finalización. Pero el 75% del camino hasta allí, algunos congestiones de red alcanzan y su tasa de descarga cae a 500 KB / s.

Dependiendo de cómo el navegador calcule el tiempo restante, su ETA podría pasar instantáneamente de 25 segundos a 50 segundos (usando el presente solo estado: Tamaño Restante / Velocidad de Descarga ) o, lo más probable, el navegador usa un algoritmo de promedio variable que se ajustará a las fluctuaciones en la velocidad de transferencia sin mostrar saltos dramáticos al usuario.

Un ejemplo de el algoritmo de rodadura con respecto a la descarga de un archivo podría funcionar de la siguiente manera:

• La velocidad de transferencia de los 60 segundos anteriores se recuerda con el valor más reciente reemplazando al más antiguo (p. ej., el valor 61 sustituye al primero).
• la tasa para el cálculo es el promedio de estas mediciones.
• El tiempo restante se calcula como: Tamaño Restante / Velocidad de descarga efectiva

Por lo tanto, utilizando nuestro escenario anterior (en aras de la simplicidad, usaremos 1 MB = 1,000 KB):

• A los 75 segundos de la descarga, nuestros 60 valores recordados serían cada uno de 1,000 KB. La velocidad de transferencia efectiva es 1,000 KB (60,000 KB / 60) lo que produce un tiempo restante de 25 segundos (25,000 KB / 1,000 KB).
• A los 76 segundos (donde la velocidad de transferencia cae a 500 KB), la velocidad de descarga efectiva se convierte en ~ 992 KB (59,500 KB / 60) que rinde un tiempo restante de ~ 24,7 segundos (24,500 KB / 992 KB).
• A los 77 segundos: Velocidad efectiva = ~ 983 KB (59,000 KB / 60) rindiendo el tiempo restante de ~ 24.4 segundos (24,000 KB / 983 KB).
• A los 78 segundos: velocidad efectiva = 975 KB (58,500 KB / 60) rindiendo tiempo restante de ~ 24,1 segundos (23,500 KB / 975 KB).

Puedes ver el patrón que surge aquí es que la disminución en la velocidad de descarga se incorpora lentamente en el promedio que se utiliza para estimar el tiempo restante. Según este método, si el chapuzón solo duró 10 segundos y luego volvió a 1 MB / s, es poco probable que el usuario advierta la diferencia (salvo por una pérdida muy leve en la cuenta regresiva estimada).

Llegar a las tachuelas de bronce - esto es simplemente una metodología para transmitir información al usuario final por la causa subyacente real ...

No se puede determinar con precisión algo que no es determinista

En última instancia, la inexactitud de la barra de progreso se reduce al hecho de que está tratando de determinar tiempo para algo que no es determinista. Debido a que las computadoras procesan tareas tanto a pedido como en segundo plano, es casi imposible saber qué recursos del sistema estarán disponibles en cualquier momento en el futuro, y es la disponibilidad de los recursos del sistema lo que se necesita para completar cualquier tarea.

Utilizando otro ejemplo, suponga que está ejecutando una actualización de programa en un servidor que realiza una actualización de base de datos bastante intensa. Durante este proceso de actualización, un usuario envía una solicitud exigente a otra base de datos que se ejecuta en este sistema. Ahora los recursos del servidor, específicamente para la base de datos, tienen que procesar solicitudes tanto para su actualización como para la consulta iniciada por el usuario, un escenario que será mutuamente perjudicial para el tiempo de ejecución. Alternativamente, un usuario podría iniciar una solicitud de transferencia de archivos de gran tamaño que gravaría el rendimiento del almacenamiento, lo que también reduciría el rendimiento. O una tarea programada podría iniciarse, lo que lleva a cabo un proceso intensivo de memoria. Te da la idea.

Como, quizás, una instancia más realista para un usuario común: considera ejecutar Windows Update o un análisis de virus. Ambas operaciones realizan operaciones intensivas de recursos en segundo plano. Como resultado, el progreso que cada uno hace depende de lo que el usuario está haciendo en ese momento. Si está leyendo su correo electrónico mientras se está ejecutando, lo más probable es que la demanda de recursos del sistema sea baja y la barra de progreso se mueva constantemente. Por otro lado, si está haciendo edición de gráficos, su demanda de recursos del sistema será mucho mayor, lo que provocará que el movimiento de la barra de progreso sea esquizofrénico.

En general, es simplemente que no hay bola de cristal. Ni siquiera el propio sistema sabe qué carga estará bajo ningún punto en el futuro.

En definitiva, realmente no importa

La intención de la barra de progreso es, bueno, indicar que efectivamente se está progresando y el proceso respectivo no se cuelga. Es bueno cuando el indicador de progreso es preciso, pero generalmente es solo una pequeña molestia cuando no lo es. En su mayor parte, los desarrolladores no dedicarán una gran cantidad de tiempo y esfuerzo a los algoritmos de la barra de progreso porque, francamente, hay tareas mucho más importantes para pasar el tiempo.

Por supuesto, tiene todo el derecho a estar molesto. cuando una barra de progreso salta al 99% completa al instante y luego te hace esperar 5 minutos para el uno por ciento restante. Pero si el programa respectivo funciona bien en general, recuerde que el desarrollador tenía claras sus prioridades.

Todos esos "sellos de aprobación" en los sitios web no significan nada

Verán insignias como "Norton Secured", "Microsoft Certified Partner" y "BBB Accredited Business" en toda la web, especialmente al descargar software. No debe confiar ciegamente en un sitio web que muestre tales insignias; son solo imágenes que cualquiera puede copiar y pegar. Consejos como "Si ve un sello McAfee SECURE en un sitio web, sabe que es seguro", es incorrecto.

(how-to)

Los 5 mejores juegos gratuitos de iPhone (que son realmente gratuitos)

Los juegos "Freemium", como se los conoce colectivamente, son una plaga en las tiendas de aplicaciones de todo tipo, ya sea ITunes de Apple, Google Play o incluso la Tienda de Windows. Prohibido en el episodio de South Park "Freemium no es gratis", juegos como Simpsons: Tapped Out se pusieron en marcha para crear de forma activa y consciente escenarios de cajas de Skinner donde los jugadores podían juegue un juego para "gratis", solo para descubrir que su capacidad para subir de nivel o agregar nuevos objetos estaba bloqueada en un pago por monedas del juego.

(how-to)