4 razones por las que Android no puede ser el sistema perfecto

5 cosas molestas sobre el diseño de Android 12 Está lejos de ser perfecto

Android 12 resultó ser una actualización masiva del sistema; en él, Google implementó una nueva dirección de diseño llamada Material You. Anteriormente escribí un artículo sobre por qué la nueva interfaz colorida con elementos grandes es mejor que Material Design 2. Ahora es el momento de hablar sobre las debilidades. Para algunos, estas deficiencias parecerán insignificantes: este artículo refleja solo una opinión separada basada en la experiencia.

Un exceso de colores y formas parece frívolo.

El diseño actualizado se ve brillante e inusual. Los controles, las curvas y los widgets con forma de engranaje grandes y fáciles de hacer clic refrescan el aspecto del sistema. La cantidad de colores ha aumentado, han aparecido grandes inscripciones, animaciones suaves con transfusiones de luz.

El sistema se ha vuelto expresivo y receptivo, pero este también es el inconveniente de Material You: es menos serio que el diseño estricto y conciso de iOS o versiones anteriores de Android. En busca de la novedad, Google se excedió y agregó todo un zoológico de curvas y características visuales.

Iconos receptivos

Uno de los nuevos elementos en la sección de personalización son los iconos temáticos. Trae iconos de escritorio a un solo estilo con colores adaptados al fondo de pantalla. A aquellos que distinguen los íconos por color no les gustará esta característica; será difícil encontrar rápidamente el correcto. Pero los amantes del minimalismo y la unificación preferirán incluir “Iconos temáticos”. E inmediatamente se enfrentó a un desastre en el escritorio. Por el momento, solo una pequeña parte de todas las aplicaciones está adaptada.

Incluso no todos los programas de Google admiten la función. ¿Vale la pena mencionar a los desarrolladores de terceros? Los creadores de aplicaciones populares tardarán años en agregar soporte para íconos adaptables. Hasta entonces, los escritorios con “Íconos temáticos” activados se verán más desordenados que elegantes y minimalistas.

Personalización desaparecida

La principal característica de Material You son los colores del sistema que se adaptan a la paleta de fondos de pantalla del escritorio. Pero junto con su apariencia, algunas configuraciones de apariencia desaparecieron. Ahora no puede cambiar la fuente integrada en el sistema, la forma de los íconos en la pantalla de inicio y los íconos en la barra de estado. Si antes todo esto estaba en la sección “Fondo de pantalla y estilo”, ahora solo queda la configuración de la cuadrícula de la aplicación, la elección del color de acento, que se ha reducido en comparación con Android 11, y un par de interruptores más.

Pérdida de individualidad

Los programas que siguen principios de diseño comunes se ven hermosos y armoniosos. Pero cuando todos sus elementos están pintados del mismo color tomado del fondo de pantalla, esto induce a error a los usuarios. Se vuelve difícil distinguir entre aplicaciones que parecen idénticas.

Ahora bien, este problema concierne solo a las utilidades de marca. Google debería trabajar en la diversidad de diseño en su software móvil. Los desarrolladores de software de terceros no tienen prisa por cambiar a Material You, por lo que se ha evitado su pérdida de individualidad. Pero aquí también podemos notar otro problema: la mayoría de las aplicaciones se destacarán del estilo general.

Elementos exageradamente agrandados

He dicho más de una vez que los elementos grandes facilitan presionarlos con una mano o sobre la marcha. Y es más fácil obtener datos de objetos no interactivos. Por desgracia, este no es siempre el caso. Algunas cosas en Android 12 se hacen grandes sin razón aparente.

Entonces, en la aplicación de despertador, por alguna razón, un botón gigante para agregar ocupó el lugar en la parte inferior. Se superpone a las cartas y no se oculta de ninguna manera. No menos extrañas son las firmas rusificadas que apenas encajan en el panel inferior. La guinda del pastel es la inscripción “Secondo. “. La sensación de que me metí en el caparazón chino, y no en Android puro.

READ
Android y Microsoft. Mañana es el líder de ayer

Los mosaicos de tonos de notificación son otro ejemplo de mal diseño. Han aumentado, pero hay menos información útil. Al mismo tiempo, se coloca la misma cantidad de interruptores en la forma expandida que antes, pero las firmas no encajan por completo y, por lo tanto, se desplazan, y la altura del bloque se ha vuelto más grande, lo que hace que quepan menos notificaciones. Los mosaicos de acceso rápido se hicieron demasiado grandes sin necesidad de ello.

5 cosas molestas sobre el diseño de Android 12 Está lejos de ser perfecto

A primera vista, la forma en que se implementa Material You en Android 12 solo evoca emociones positivas. Un examen detallado del sistema revela fallas que no permiten llamar ideal al nuevo diseño.

Mi traducción anterior de un artículo sobre la aceleración de hardware en Android provocó una acalorada discusión en los comentarios, cuyo motivo principal fue la pregunta “¿por qué se ralentiza Android?”. Una situación similar se observa en Internet y, por lo tanto, a continuación les doy otra traducción muy interesante y fresca (nuevamente de Google+), donde el autor Andrew Munn (sobre él a continuación) analiza las causas reales de las ralentizaciones de Android. Yo mismo leí esta publicación con placer y estoy orgulloso de ser el primero en compartirla con la comunidad habra.

¿Por qué Android es lento cuando iOS, Windows Phone 7, QNX y WebOS funcionan tan bien?

Esta publicación pretende responder a esa pregunta.

Sin embargo, antes de llegar al punto, algunas advertencias. En primer lugar, soy estudiante de tercer año de la especialidad “ingeniería de software”. Estoy internado en el equipo de Android, y Romain Guy, quien fue responsable de la mayor parte del trabajo de aceleración de hardware en Honeycomb, revisó parte de mi código, pero no estaba en el equipo detrás del marco en sí, y he nunca lea el código fuente del código de renderizado de Android. No tengo ninguna autoridad seria sobre el conocimiento de Android y no puedo garantizar que lo que digo aquí sea necesariamente 100 % exacto, pero he hecho todo lo posible para argumentar mi punto.

En segundo lugar, he sido pasante en el equipo de Windows Phone desde enero, por lo que es muy posible que este puesto me vuelva inconscientemente en contra de Android, pero si le preguntas a alguno de mis amigos, es muy difícil pedirme que no hable sobre Android. . Tengo más camisetas de Android que días a la semana y prefiero regalar mi Macbook que mi Nexus S. El Googleplex es como una segunda casa. En cualquier caso, mis intereses quizás estén sesgados a favor de Android.

Así que pasemos al análisis del artículo anterior sobre los mitos (estamos hablando de la versión completa del post de Diana Hackborn).

Diana comienza su publicación con una sorprendente revelación:

“Mirando el renderizado dentro de una ventana, no necesariamente necesitamos usar aceleración de hardware para alcanzar los 60FPS completos. Esto depende en gran medida de la cantidad de píxeles en la pantalla y la velocidad de su procesador. Por ejemplo, el Nexus S no tiene problemas con 60 fps para todas las cosas normales que ves en la interfaz de usuario de Android, como desplazarte por las listas en su pantalla de 800×480″.

¿Sí? ¿Cómo puede ser esto? Cualquiera que haya usado el Nexus S sabe que se ralentiza con cualquier cosa menos con simples ListViews. Y olvídese de cualquier apariencia de rendimiento decente si algo sucede en segundo plano, como instalar una aplicación o actualizar la interfaz de usuario desde el almacenamiento interno. Por otro lado, iOS funciona al 100% sin problemas incluso al instalar aplicaciones. Pero sabemos que Diana no está mintiendo sobre el rendimiento potencial de la CPU, entonces, ¿qué está pasando?

READ
Donald Trump prohíbe a Huawei almacenar Android por un año más
Razón principal

Estas no son pausas debidas al recolector de basura. Esto no se debe a que Android funcione a través de bytecode e iOS funcione con código nativo. Esto se debe a que en iOS, la representación de toda la interfaz ocurre en un subproceso de interfaz de usuario separado en modo de prioridad en tiempo real. Por otro lado, Android sigue el modelo de PC tradicional en el que el renderizado central ocurre con prioridad normal.

Esta no es una diferencia abstracta o académica. Puedes verlo por ti mismo. Tome el iPad o iPhone más cercano y abra Safari. Comienza a cargar una página web compleja como Facebook. A la mitad de la carga, coloque el dedo en la pantalla y muévalo. Todo el renderizado se detiene inmediatamente. El sitio simplemente no se cargará hasta que levantes el dedo. Esto se debe a que el subproceso de la interfaz de usuario intercepta todos los eventos y la representación de la interfaz de usuario se realiza en tiempo real.

Si repite este ejercicio en Android, notará que el navegador intentará mostrar tanto la página como el HTML, es decir hacer “perfectamente” tanto lo uno como lo otro. Para Android, aquí es donde realmente ayuda un eficiente procesador de doble núcleo, razón por la cual el Galaxy S II es conocido por su suavidad.

En iOS, cuando se instala una aplicación desde App Store y coloca el dedo en la pantalla, la instalación se detendrá instantáneamente hasta que se complete la representación. Android intenta hacer ambas cosas con la misma prioridad, por lo que la velocidad de fotogramas se ve afectada. Una vez que note que esto sucede, verá que está por todas partes en un teléfono Android. ¿Por qué el desplazamiento es lento en la aplicación Películas? Porque las miniaturas de películas se agregan dinámicamente a la lista de películas cuando se desplaza hacia abajo, pero en iOS solo se agregan silenciosamente cuando se detiene el desplazamiento.

Varias personas se han encargado de explicar los errores que cometí en mi descripción simplificada del proceso de renderizado en iOS. En particular:

1) Configuración previa de composición y animación: todo lo que incluye Core Animation y la representación de las capas que lo acompañan realmente sucede en el subproceso de fondo.

2) Dibujar nuevo contenido en la capa Core Animation y configurar su animación se lleva a cabo en el hilo principal. Este es el mismo hilo que dibuja la interfaz de usuario.

3) En código nativo, todo el código creado por el desarrollador aparecerá en el hilo principal. Sin embargo, Apple ofrece una API muy simple (Grand Central Dispatch y NSOperation) para mover estas cosas a subprocesos en segundo plano administrados por el sistema. En iOS 5, incluso puede afirmar que el contexto Core Data (base de datos relacional de objetos) no se puede usar directamente en el hilo principal.

¿Qué notamos? La imagen no se muestra hasta que termina de desplazarse por la lista, la representación de la página WebKit se detiene cuando el sistema detecta un toque en la pantalla, es un mecanismo incorporado que detiene todo el mundo mientras su dedo está en la pantalla.
(En realidad, esto no es del todo cierto: el hilo principal se coloca en un modo especial mientras se monitorea el sensor y, de forma predeterminada, ciertas devoluciones de llamadas se retrasan en este modo. Sin embargo, muchas otras cosas, como la carga desde el disco o la actividad de la red, se mantienen completamente en un subproceso de fondo sin detenerse, nada de esto se detiene automáticamente en el momento del desplazamiento. El desarrollador debe especificar explícitamente los retrasos para estas cosas). Este comportamiento intencional es cuidadosamente implementado por el desarrollador de cada aplicación individual.

READ
Qué Android One es el siguiente para Xiaomi Mi A1?

No es una diferencia técnica, es una diferencia cultural. Los buenos desarrolladores de iOS no lanzan el software hasta que se ejecuta a unos 60 fps en desplazamiento y tiene un seguimiento táctil casi perfecto, al igual que los buenos desarrolladores de Android.

Otras razones

La razón principal por la que Android se ralentiza es la estructura de los subprocesos de la interfaz de usuario y su prioridad, pero esta no es la única razón. Primero, la aceleración de hardware, a pesar de las reservas de Diana, todavía ayuda. Mi Nexus S nunca ha funcionado tan bien desde que actualicé a ICS [traducción aproximada: ¡El mío también! :)]. La aceleración de hardware marca una gran diferencia en aplicaciones como la pantalla de inicio y Android Market. La ayuda proporcionada por la GPU también mejora la duración de la batería, porque las GPU son hardware de función fija, por lo que funcionan con menos energía.

En segundo lugar, contrariamente a lo que dije anteriormente, la recolección de basura sigue siendo un problema, incluso cuando se trabaja a tiempo parcial con GC en Dalvik. Por ejemplo, si alguna vez usó la aplicación de galería de fotos en Honeycomb o ICS, es posible que se pregunte por qué la velocidad de fotogramas es tan baja. Resulta que la velocidad de fotogramas está limitada a 30 fotogramas por segundo, y el desplazamiento de fotos es posible a 60 FPS en la mayoría de los casos, pero a veces las pausas en el recolector de basura provocan un tartamudeo notable. Limitar la velocidad de fotogramas a 30 corrige el “tartamudeo” y garantiza una animación fluida todo el tiempo.

En tercer lugar, hay problemas con el equipo, que también menciona Diana. Tegra 2, a pesar de las grandilocuentes afirmaciones del departamento de marketing de Nvidia, perjudica el bajo ancho de banda de la memoria y carece de soporte para el conjunto de instrucciones NEON (las instrucciones NEON de ARM son el equivalente de Intel a SSE, que permiten cálculos matriciales más rápidos en la CPU). Las tabletas Honeycomb serían mejores con diferentes GPU, incluso si fueran teóricamente menos potentes en algunos aspectos que Tegra 2. Por ejemplo, el Samsung Hummingbird en el Nexus S o el Apple A4. Esto nos dice que la tableta más rápida lanzada por Honeycomb, la Tab Galaxy 7.7, ejecuta el procesador Exynos del Galaxy S II.

En cuarto lugar, Android tiene una forma de avanzar hacia una composición de interfaz de usuario más eficiente. en iOS, cada vista de la interfaz de usuario se representa por separado y se almacena en la memoria, por lo que muchas animaciones solo requieren la GPU para ver la recomposición de la interfaz de usuario. Las GPU son muy buenas en esto. Desafortunadamente, en Android, la jerarquía de la interfaz de usuario se aplana antes de la renderización, por lo que las animaciones requieren volver a dibujar cada sector de la pantalla en el que ocurren.

En quinto lugar, la VM Dalvik no es tan madura como la JVM de escritorio. Java es conocido por el terrible rendimiento de la GUI en los escritorios. Sin embargo, muchos problemas no se trasladan a la implementación de Dalvik. Swing fue terrible porque era una capa multiplataforma sobre la API nativa. Es interesante notar que la interfaz de usuario principal de Windows Phone 7 se basa en código nativo, aunque el plan original se basaría completamente en Silverlight. Microsoft finalmente decidió que para darle a la interfaz el rendimiento que necesitaba, el código tenía que ser nativo. Es fácil ver la diferencia entre nativo y código de bytes en Windows Phone 7, ya que las aplicaciones de terceros escritas en Silverlight tienen un rendimiento inferior (Nodo y Mango han mitigado este problema y las interfaces de Silverlight son generalmente muy fluidas ahora).

READ
Varios errores molestos encontrados en Android Lollipop

Afortunadamente, cada uno de los cinco problemas enumerados anteriormente se puede resolver sin cambios drásticos en Android. La aceleración de hardware estará en todos los teléfonos con Android ICS, Dalvik continúa mejorando la eficiencia de su recolector de basura, Tegra 2 finalmente está obsoleto, existen soluciones para los problemas de composición de la interfaz de usuario existentes y Dalvik VM se vuelve más rápido con cada lanzamiento. Recientemente le pregunté a Jason Kincaid de TechCrunch qué tan suave era el Galaxy Nexus y respondió:

“En general, encontré que el ICS en el Galaxy Nexus es bastante fácil de usar. Hay tartamudeos ocasionales: un lugar en el que puedo ponerme constantemente nervioso en el Galaxy Nexus es cuando presiono el botón multitarea, donde a menudo se detiene durante un cuarto de segundo. Sin embargo, encuentro que el iPhone 4S también tartamudeó más de lo que esperaba, especialmente cuando fui a acceder a la búsqueda general de aplicaciones (donde se desliza hacia la izquierda desde la pantalla de inicio)”.

Entonces, vamos, el problema de retraso de Android está básicamente resuelto, ¿no? No tan rapido.

Hacia el futuro

La interfaz de usuario de Android nunca será perfectamente fluida debido a las limitaciones de diseño que discutimos al principio:

– La representación de la interfaz se produce en el hilo principal de la aplicación;
– La representación de la interfaz ocurre con una prioridad normal;

Incluso con un Galaxy Nexus o un procesador de cuatro núcleos EeePad Transformer Prime, no hay forma de garantizar velocidades de cuadro uniformes y aceptables si se mantienen esas dos limitaciones de diseño. Esto sugiere que la potencia del Galaxy Nexus es suficiente para igualar la suavidad de funcionamiento con el primer iPhone hace tres años. Entonces, ¿por qué el equipo de Android usó esta estructura de representación en particular?

El trabajo en Android comenzó incluso antes de que se lanzara el iPhone, y en ese momento, el sistema Android fue diseñado para ser un competidor de Blackberry. El prototipo original de Android no tenía una pantalla táctil. Los compromisos de Android tienen sentido para los dispositivos con un teclado de hardware y trackball. Y cuando salió el iPhone, el equipo de Android se apresuró a lanzar un competidor para este producto, pero, desafortunadamente, ya era demasiado tarde para reescribir toda la interfaz de usuario del sistema.

Esta es la misma razón por la que Windows Mobile 6.5, Blackberry OS, Symbian tienen un rendimiento de pantalla táctil terrible. Al igual que Android, no fueron diseñados para “priorizar” la representación de la interfaz de usuario. Después del lanzamiento del iPhone, RIM, Microsoft y Nokia abandonaron sus sistemas operativos móviles y comenzaron el desarrollo desde cero. Android es el único sistema operativo móvil que existía antes de la era del iPhone.

Entonces, ¿por qué el equipo de Android no cambió el status quo? Dejaré que Romain Guy explique:

READ
Los propietarios de teléfonos inteligentes Huawei ya no podrán usar lanzadores de terceros

“… Mucho del trabajo que necesitamos hacer hoy se debe a ciertas elecciones hechas hace muchos años… Con la animación UI, el mayor problema es. Estamos trabajando en otras soluciones para intentar mejorarlo (la capacidad de usar un subproceso de procesamiento separado, etc.). La solución simple, por supuesto, es crear un nuevo conjunto de herramientas gráficas, pero este enfoque tiene muchas desventajas. “

Romain no explica los pros y los contras de esta solución, pero no es difícil de adivinar:

– Todas las aplicaciones deben ser reescritas para soportar la nueva estructura;
– Android tendrá que proporcionar un modo de soporte para aplicaciones más antiguas;
– Se suspenderá el trabajo en otras funciones de Android hasta que se desarrolle el nuevo sistema;

Sin embargo, creo que la escritura “desde cero” debería suceder, a pesar de estos inconvenientes y deficiencias. Como gerente principiante, encuentro que la lentitud de Android es completamente inaceptable. Este problema debe convertirse en la prioridad número 1 para el equipo de Android.

Cuando el tema de Android lo plantean amigos expertos y no expertos en tecnología, escucho una y otra vez que Android es lento y lento. La realidad es que Android puede abrir aplicaciones y mostrar páginas web tan rápido o incluso más rápido que iOS, pero la experiencia lo es todo. Arreglar la interfaz de usuario lenta será el comienzo de un largo viaje para restaurar la reputación y la imagen de Android.

La percepción del problema, los frenos: esto es una violación de la filosofía de Google. Google cree que todo debe ser rápido. Esa es la filosofía principal detrás de la Búsqueda de Google, Gmail y Chrome. Es por eso que Google creó SPDY, para mejorar HTTP. Es por eso que Google crea herramientas para ayudarlo a optimizar su sitio. Es por eso que Google está lanzando su propio CDN. Esta es la razón por la que Google Maps se representa mediante WebGL. Es por eso que el almacenamiento en búfer de Youtube es algo que la mayoría de nosotros recordamos bien, pero vemos cada vez menos.

Pero quizás una de las razones más importantes por las que la interfaz de usuario retrasada de Android proviene inaceptablemente del ámbito de la interacción humano-computadora (HCI). Las pantallas táctiles modernas implican una correspondencia uno a uno entre un dedo y una animación en pantalla. Es por eso que el efecto de desplazamiento en iOS (banda elástica) es tan genial, divertido e intuitivo. Y es por eso que las pantallas táctiles de Virgin America Flights son tan frustrantes: son increíblemente lentas y muy imprecisas.

Los frenos de la interfaz de usuario interrumpen la comunicación de la pantalla táctil humana. La comunicación con el dispositivo deja de ser natural. Pierde su magia. El usuario está excluido de interactuar con ellos y debe reconocer incondicionalmente que está utilizando simulaciones informáticas imperfectas. A menudo me pierdo en el iPad, pero me pongo nervioso cuando el Xoom tartamudea entre pantallas. Los 200 millones de usuarios de Android se merecen algo mejor.

Y sé que lo conseguirán eventualmente. El equipo de Android es uno de los equipos de desarrollo más dedicados y talentosos del mundo. Con estrellas como Diana Hackborn y Romain Guy, Android está en buenas manos.

Espero que esta publicación reduzca la confusión sobre los retrasos de Android.
Con un poco de suerte, Android 5.0 nos brindará la experiencia fluida de Android con la que todos soñamos desde el HTC G1. Mientras tanto, estaré en Redmond trabajando en un sistema operativo móvil agradable y fluido y tratando de darle algo del reconocimiento que se merece.

Rating
( No ratings yet )
Like this post? Please share to your friends:
Leave a Reply

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: