El problema subyacente son los diferentes modelos de animación en Android e iOS. iOS usa CoreAnimation, una API creada por el equipo de iPhone para el iPhone original que fue portado nuevamente al escritorio OSX. Todas las GUI generalmente funcionan de la misma manera. Hay un hilo principal con un bucle que procesa los mensajes de una cola. Los mensajes pueden ir desde “mover vista a esta ubicación” o “el usuario ha realizado un toque en la ubicación”. El punto es que es una _queue_, por lo que cada mensaje generalmente se procesa uno a la vez y por orden de llegada.
Para la mayoría de los kits de herramientas de UI, incluidos los que se encuentran en iOS y Android, el acceso y la modificación de los objetos deben realizarse en el hilo principal. A pesar de que a veces se le llama hilo de interfaz de usuario, generalmente también es el hilo principal y, a menudo, es responsable no solo de pintar, cambiar colores, mover objetos, sino también de cargar archivos, decodificar imágenes, manejar respuestas de red, etc.
En Android, si desea animar un objeto y hacer que mueva un objeto de ubicación1 a ubicación2, la API de animación calcula las ubicaciones intermedias (interpolación) y luego pone en cola en el hilo principal las operaciones de movimiento apropiadas en los momentos apropiados usando un temporizador . Esto funciona bien, excepto que el hilo principal generalmente se usa para muchas otras cosas: pintar, abrir archivos, responder a las entradas del usuario, etc. Un temporizador en cola a menudo se puede retrasar. Los programas bien escritos siempre intentarán realizar tantas operaciones como sea posible en subprocesos en segundo plano (no principales); sin embargo, no siempre puede evitar usar el subproceso principal. Las operaciones que requieren que opere en un objeto de IU siempre deben realizarse en el hilo principal. Además, muchas API canalizarán las operaciones al hilo principal como una forma de seguridad de hilo. Por lo general, es casi imposible mantener todas las operaciones en el subproceso principal a 1/60 de segundo para permitir que las animaciones se procesen sin problemas. Incluso si Google pudiera lograr que su código hiciera exactamente eso, no significa que los escritores de aplicaciones de terceros puedan hacerlo.
- ¿Por qué necesitamos una aplicación para ver contenido en teléfonos inteligentes / PDA?
- ¿Cuál es la mejor manera de redirigir a un usuario a un sitio móvil?
- ¿Cómo construir un juego para Android e iOS? ¿Cuáles son los pasos y el costo involucrados?
- Cómo crear una aplicación desde un sitio web
- ¿Qué es un sitio móvil y por qué lo necesito?
En iOS, las operaciones en objetos de IU también deben realizarse en el hilo principal, con la excepción de las operaciones de animación realizadas a través de CoreAnimation. CoreAnimation se ejecuta en un subproceso de fondo y puede manipular, mover, cambiar el color y remodelar directamente los objetos de la interfaz de usuario en un subproceso de fondo (CoreAnimation). La composición, la representación también se realiza en este hilo. Lo hace a través de una combinación de hardware y software, proporcionando animaciones muy suaves y rápidas. Desde el hilo principal, básicamente puede emitir una llamada a CallAnimation y decirle que mueva object1 de location1 a location2. Esta animación continuará ejecutándose incluso si el hilo principal está bloqueado realizando otra operación. Es por eso que las animaciones casi nunca tartamudean en iOS.
Piense en el modelo de iOS de esta manera: el subproceso principal administra los datos de la aplicación y el estado de la aplicación de la interfaz de usuario (el estado de la aplicación de la interfaz de usuario incluye cosas como las cadenas que se mostrarán en un ListView, etc.) pero emite solicitudes de cambio de estado de la interfaz de usuario física a una alta prioridad separada y dedicada Hilo CoreAnimation (los estados físicos incluyen cosas como el color, la posición y la forma). Todos los cambios de estado físico pueden ser animados y CoreAnimation también realizará la interpolación por usted (como las API de animación de Android). CoreAnimation emitirá directamente los cambios de estado físico no animados y el subproceso principal (no el subproceso CoreAnimation) se bloqueará hasta que se realicen. Los cambios de estado físico animados emitidos por el subproceso principal se realizarán de forma asincrónica por el subproceso CoreAnimation. Debido a que el estado de la interfaz de usuario física y solo el estado de la interfaz de usuario física es administrado por el subproceso CoreAnimation, el subproceso principal puede estar bloqueado u ocupado, pero el subproceso CoreAnimation continuará no solo representando con precisión el último estado conocido de la IU (tal como lo emite el subproceso principal ), pero también continúa representando cualquier cambio de estado físico de la IU animado pendiente o incompleto según lo solicite el hilo principal.
En Windows Vista, Microsoft introdujo la composición de escritorio mediante la cual el sistema operativo mantenía un búfer de píxeles separado para cada ventana. Esto significaba que incluso si una aplicación se bloqueaba, el último estado de la ventana (cómo se veía) todavía se representa en lugar de simplemente dibujarse en blanco (el sistema operativo gestionó parcialmente el estado de los píxeles en la ventana). CoreAnimation va más allá de esto y descarga gran parte del trabajo de la interfaz de usuario gestionado tradicionalmente por el hilo principal, incluida la gestión no solo de los píxeles (como Vista) sino de conceptos de nivel superior, como widgets, ubicaciones de widgets, colores de widgets, etc.
iOS y Android utilizan arquitecturas de software completamente diferentes para realizar animaciones. Apple probablemente se enfocó más en crear algo como CoreAnimation porque Apple es mucho más TOC sobre diseño y experiencia de usuario que la mayoría de las compañías de software. Estoy seguro de que Steve habría tenido algunas palabras con los arquitectos de iOS si el desplazamiento tartamudeaba al leer un correo electrónico porque era necesario cargar una imagen en el correo electrónico. Los humanos no son computadoras. A menudo, la percepción del rendimiento es más importante que el rendimiento real cronometrado. Un correo electrónico que demore 50 ms en cargarse no será tan notorio como una pantalla táctil que no responde y se mueve instantáneamente cuando un usuario desliza su dedo sobre él.
No hay nada absolutamente malo con el modelo de animación de Android. Es la forma en que funcionan muchos juegos de herramientas, incluido Flash, que definitivamente fue muy animada. Yo diría que el modelo iOS hace que la experiencia general del usuario sea más agradable y descarga una preocupación más para el desarrollador de vuelta al sistema operativo. Estoy seguro de que Google seguirá reconociendo la importancia de la animación en dispositivos con pantalla táctil y continuará acelerando (o reestructurando) Android en los próximos lanzamientos.
Un iPhone de primera generación de 5 años realizará animaciones más suaves y confiables que el último teléfono Samsung Android de cuatro núcleos. Es un problema de diseño de software y no es algo en lo que puedas arrojar más núcleos (¡sobre todo porque el hilo principal solo se ejecutará en un núcleo!).
Por el momento, nunca verá algo tan simple como un tartamudeo de la rueda de carga en iOS. Espero que esto explique por qué 🙂
