Puede haber algunas explicaciones … especialmente porque no ha mencionado específicamente dónde ve el retraso. Supongo que es el retraso de la interfaz de usuario, la tendencia de las cosas de la interfaz de usuario a “tartamudear” un poco. Esto puede ser un poco técnico, pero intentaré que sea lo más simple posible.
Configure la máquina de retroceso en 1985
Curiosamente, me tomó mucho, mucho tiempo acostumbrarme a lo mismo en Windows. Tal vez no sea tan obvio en estos días en nuestras máquinas grandes, pero Windows tenía un retraso de UI absolutamente atroz … particularmente para una persona como yo que venía de AmigaOS.
- ¿Cuánta RAM libre tiene Xiaomi Redmi Note 3 en promedio?
- ¿Qué debo agregar / reemplazar en mi PC para que funcione FIFA 17/18? Tengo una PC vieja con Intel Pentium Dual Core y 2 GB de RAM.
- ¿Jugar juegos en modo de ventana usa menos memoria que jugar en modo de pantalla completa?
- ¿Cómo podemos aumentar la RAM?
- ¿Por qué Google Chrome toma más RAM que Mozilla Firefox?
Para aquellos que no saben, AmigaOS fue el sistema operativo de la serie de computadoras personales Commodore Amiga. En 1985, teníamos una interfaz de usuario realmente rápida que se ejecutaba en un procesador 68000 de 7.16MHz en tan solo 256K RAM. Con multitarea? Usted podría preguntar, ¿cómo podría ser eso?
Aquí está el truco: el Amiga era un sistema operativo en tiempo real (nunca calificó completamente de manera formal, pero cumplió con todos los demás criterios). La interfaz de usuario fue manejada por un subsistema llamado Intuition que realizó la manipulación real de ventanas y elementos de la interfaz de usuario, intercambiando mensajes con cada aplicación. Y Intuition se ejecutó en un nivel de prioridad de tarea más alto que cualquier tarea de aplicación. En resumen, la interfaz de usuario en el Amiga fue muy rápida porque casi todo lo demás en el sistema se salía del camino cuando era necesario hacer algo en la interfaz de usuario. Entonces no hubo competencia ni imprevisibilidad.
Entrar en Windows
Así que gradualmente comencé a usar Windows después de que Commodore murió. AmigaOS fue genial, pero fue agradable y ocasionalmente importante para el trabajo poder usar nuevas computadoras. ¡Pero Windows como siempre es tan torpe! A medida que aprendí más al respecto, quedó bastante claro que, a pesar del hardware cada vez más rápido, Windows permanecería torpe durante mucho tiempo. Tenía, en relación con AmigaOS, defectos de diseño. Windows se diseñó originalmente para “cooperativa”, también conocida como multitarea “falsa”. El sistema operativo originalmente no tenía tareas reales. La interfaz de usuario funcionó a través de mensajes … desafortunadamente, a diferencia de la Intuición de Amiga que maneja cada ventana con una cola de mensajes separada, envía solo mensajes que esa tarea en particular solicitó, administra los gadgets / widgets / elementos de la interfaz de usuario, etc., maneja su propia actualización de ventana, en Windows, la aplicación tuvo que procesar todos estos mensajes, volver a dibujar su propia ventana, actualizar los elementos de la interfaz de usuario por su cuenta, etc. Y todo esto, desde el principio, se realizó en la aplicación principal.
De hecho, Windows era particularmente malvado. En un sistema operativo normal, puedo configurar dos tareas diferentes (hilos, como quiera llamarlas) y enviar señales o mensajes directamente entre ellos (claro, el sistema operativo está facilitando esto, pero la conexión es lógicamente directa). Incluso en Windows 95, tratar de hacer esto terminó convirtiendo esa señal en un mensaje en la cola de mensajes de esa aplicación. Sin comunicaciones directas, todo filtrado a través de la aplicación en la prioridad de nivel de aplicación. La conclusión fue que, cuando el sistema se puso muy ocupado, las aplicaciones se volvieron desiguales. Pero también significó que un diseño deficiente de la aplicación podría empeorar aún más las cosas: cuando la aplicación se llena, no se manejan mensajes de eventos de IU y un programa parece bloquearse. En AmigaOS, incluso si la aplicación principal estuviera ocupada, Intuition todavía estaría administrando partes de la interfaz de usuario … por lo que la computadora en su conjunto no parecía retrasarse.
Interfaz de usuario en Android
En Android, tenemos una situación similar a la de Windows: Android hace que su interfaz de usuario funcione en el hilo principal de una aplicación de Android. Sin embargo, Android utiliza prioridades: por supuesto, es un sistema operativo multitarea moderno y completamente funcional construido sobre Linux. En Android, tiene programas interactivos para el usuario, llamados Aplicaciones, y programas de fondo (por ejemplo, no interactivos) llamados Servicios. Cuando un sistema Android está realmente ocupado, las Aplicaciones no se ralentizan al trabajar como Servicios. Y dado que las aplicaciones son, por definición, interactivas, es de esperar que la mayoría de las aplicaciones estén esperando la entrada del usuario, la única que está utilizando es esa excepción y esa se ejecuta sin problemas.
Pero eso también depende del diseño de la aplicación. Al igual que en Windows, es posible hacer todo tipo de cosas en el hilo principal de Android. Si está esperando la E / S de archivos o redes en el hilo principal, las cosas de la interfaz de usuario no se están manejando. El diseño adecuado de un programa de Android tiene los elementos críticos de la interfaz de usuario en el hilo principal y otros trabajos realizados en otros hilos. Pero no hay nada en el sistema operativo que fuerce esto. Pero lo que esto le dice es que es bastante posible construir una aplicación muy fluida, y bastante posible crear una aplicación lenta, solo mirando la aplicación misma.
El ecosistema de Android
Sabiendo que gran parte del buen comportamiento de una aplicación de Android depende del diseño adecuado del programa, no debería sorprendernos que algunos dispositivos aparezcan retrasados, mientras que otros con el mismo nivel de tecnología no. Esto se debe a que cada OEM de Android tiene la opción de modificar o incluir sus propias versiones de prácticamente cualquier aplicación de Android. Entonces, por ejemplo, Samsung tiene una versión modificada del “Launcher” básico de Android y una interfaz de usuario llamada TouchWiz. Al menos hace un tiempo, esto tenía fama de ser lento, una razón podría ser que TouchWiz está haciendo más cosas de interfaz de usuario: renderizado más complejo, más dibujo, más animaciones. Otra podría ser que no es un diseño tan optimizado como un sistema Android estándar. De hecho, tengo una tableta Android de Samsung y realmente no noto retraso en todos estos días. En mi tableta anterior de ASUS, no era más que retraso. El Samsung tiene algunas mejoras significativas de hardware, RAM y Flash más rápidos y núcleos de CPU más rápidos, pero probablemente también se actualizaron en el sistema operativo, un mejor diseño en el Iniciador e incluso algunas de las aplicaciones que podrían agregar a la impresión general de “retraso” dispositivo “versus” dispositivo rápido “.
Otras razones para el retraso de Android
Hay otras posibles razones. Recuerde, vamos a ver un retraso cuando la aplicación actual se ralentiza por otra actividad de la CPU. En versiones anteriores de Android, las cosas de la interfaz de usuario normal no usaban aceleración de GPU, por lo que los bits de la interfaz de usuario, como la animación, etc., tomaron más tiempo, ejecutándose solo en la CPU principal. El iOS de Apple ha tenido aceleración de GPU por un tiempo … y lo necesitaba, porque Apple usó más animación. Pero las versiones más recientes de Android han agregado más de eso, y sin una buena aceleración, viste que las cosas se retrasaron.
Android administra la memoria de manera similar a iOS y otros sistemas operativos móviles, pero de manera muy diferente a los sistemas operativos de escritorio típicos. Cuando ejecuta un sistema operativo de escritorio y la memoria se agota, el sistema intentará asignar algo de memoria “virtual”; básicamente, falsifica RAM adicional al usar una unidad de administración de memoria para afirmar que hay más memoria de la que realmente hay, luego usando rutinas en el sistema operativo para intercambiar secciones de memoria menos utilizadas para el almacenamiento. Y si no hay memoria virtual adicional disponible, el sistema operativo simplemente falla esa solicitud de memoria.
En Android, no hay memoria virtual: fue diseñado para admitir dispositivos móviles, que generalmente no tenían almacenamiento HDD. Sí, Linux admite VM, pero no se está utilizando. Entonces, cuando una aplicación realiza una solicitud de memoria, si no hay ninguna disponible, el sistema operativo Android puede cerrar una o más aplicaciones que aún están en la RAM. El diseño de Android hace que esto sea esperado: el sistema operativo puede cerrar una interfaz de usuario, restaurar una interfaz de usuario o hacer lo mismo para toda la aplicación. En cada caso, la aplicación tiene la oportunidad de prepararse para el cierre. Todo esto lleva mucho tiempo de CPU adicional, y la aplicación que solicita memoria se pausa hasta que dicha memoria esté disponible.
En un problema relacionado, las versiones anteriores de Android ejecutaban todas las aplicaciones en una máquina virtual llamada Dalvik. El modelo de programación de Android se basa en Java, y en Java, los programadores no necesitan asignar explícitamente memoria o eliminar memoria, solo crean nuevos objetos, y el entorno de ejecución se da cuenta cuando ya no son necesarios, a través de un proceso llamado basura colección. En versiones anteriores de Android, el recolector de basura, que aparentemente se ejecutaba con una prioridad más alta, a veces invocado por una aplicación cuando la memoria era corta, provocaba un retraso en todo el sistema. A partir de Android L, el nuevo modelo de aplicación ART (Android RunTime) reemplaza a Dalvik como el principal entorno de ejecución y, entre otras cosas, renueva por completo la forma en que se realiza la recolección de basura.
Otro problema: errores. Algunas versiones de Android parecen haber tenido lo que se llama una “pérdida de memoria”. Como mencioné, el entorno de ejecución de Android (ART o Dalvik) y el sistema operativo hacen toda la limpieza de memoria en Android, no es un problema de aplicación. Eso es genial, ya que evita que las aplicaciones malvadas bloqueen la memoria que no se puede reclamar. Pero si ese sistema en sí no ocasionalmente libera memoria, eso se denomina pérdida de memoria. Con el tiempo, el sistema operativo se queda sin memoria y, en ese momento, solo un reinicio restablecerá las cosas. No creo que ninguna versión de Android que estoy usando actualmente tenga una pérdida de memoria a nivel del sistema, pero es muy probable que algunas versiones lo hayan hecho en el pasado. El efecto de esto es que, a medida que pasa el tiempo, el sistema operativo está haciendo más recolección de basura, cerrando más aplicaciones y eventualmente luchando por mantener la memoria disponible incluso para la única aplicación que está utilizando.
Android e Internet
Cualquier retraso inesperado puede verse como un retraso, pero no hay mucho en el camino del comportamiento impredecible en su teléfono o tableta, aparte de los problemas de software mencionados anteriormente. La memoria flash, las pantallas táctiles, las tarjetas SD, etc. son bastante deterministas: se comportan igual siempre. Pero internet … no tanto.
Android tiene un diseño bastante interesante, ya que está muy integrado con Internet. De hecho, pequeños bits de código en Android, llamados “Intentos”, se envían datos entre sí a través de URI (Universal Resource Identifiers, un componente básico de Internet moderno). Como resultado, es bastante posible que algunas aplicaciones vivan en parte en Android, en parte en servidores de Internet. Y eso es completamente transparente para el usuario. Algunas aplicaciones hablan con un servidor en Internet cuando su dispositivo tiene acceso a Internet, y un Servicio en Android cuando Internet no está disponible.
Internet en sí, el protocolo TCP / IP, están diseñados para transmisiones imperfectas. No hay un tiempo específico para esperar una respuesta de Internet, eso depende del programa que realice esas llamadas de Internet. Estos pueden diseñarse para que se agote el tiempo de espera del servidor o la red en sí no está disponible, pero eso lleva tiempo. Y esa espera puede hacer algunos de los mismos males para ralentizar un programa de Android si ese programa no está cuidadosamente diseñado.
