Uma das mais frequentes críticas aos equipamentos Android, é a de que a sua utilização não é tão fluida quanto os equipamentos iOS da Apple - e isso tem sido muitas vezes atribuído à falta de aceleração gráfica por hardware. Mas eis que surge um post altamente elucidativo da Dianne Hackborn, que tem o dever de saber do que fala, já que trabalha no desenvolvimento do Android no Google desde 2005.
Afinal, a aceleração por hardware já é feita no Android desde as primeiras versões, no que respeita ao chamado "window compositing" e a grande número das animações das janelas, menus, etc. que aparecem no ecrã.
Apenas o conteúdo desenhado no interior de cada "janela" é que era inicialmente feito "por software" à custa do CPU - e é algo que passou também a ser possível acelerar por hardware a partir do Android 3.0, desde que os programadores especificassem que queriam utilizar essa aceleração nas suas Apps.
Com o Android 4.0, essa decisão passa a estar feita automaticamente para todas as novas Apps, deixando de ser necessário essa activação específica por parte dos developers. (Para as Apps antigas tal não é feito automaticamente, pois certas coisas poderão não ser suportadas pelo hardware, e ter consequências que comprometam a utilização da App.)
Mas... esta aceleração por hardware não é algo que resolva "magicamente" todos os problemas: para além do consumo de memória acrescido (no Nexus S alguns melhoramentos feitos para que corresse o Android 4.0 da melhor forma, consistiram precisamente em desligar essa aceleração e poupar memória), há muitos outros detalhes que têm que ser considerados - e que, nos piores casos, podem fazer com que mesmo Apps que funcionem aos tão almejados 60fps pareçam não ter a fluidez desejada.
Como sempre, está tudo na mão nos developers e nos métodos e escolhas que fizerem... Mas, fica assim (melhor) explicado em que consiste a aceleração por hardware dos gráficos no Android.
Actualização: E agora ficamos também a saber porque é que isso não evita que o Android tenha mais "lag" que os iPhones e iPads.
Artigos assim um pouco mais técnicos são raros, mas são sempre bem vindos. Como diz a autora, a performance é sempre um compromisso entre 2 ou mais variáveis. Não existem sistemas perfeitos. No caso do Android, enquanto programador, encontro 2 ou 3 características que acabam por determinar invariavelmente alguma desvantagem face aos seus competidores Windows Phone 7, mas sobretudo face ao iOS, no capítulo da performance: o Android é multi-plataforma e isso exige compromissos, designadamente o compromisso de ter as apps a correr em máquinas virtuais java. Isto acrescenta uma camada lógica ao OS, o que não abona em favor da performance; o SDK está sobre-simplificado e sobre-automatizado (veja-se o caso dos garbage collectors), o que por um lado permite alargar o leque de programadores, mas por outro acaba por potenciar o aparecimento de apps mal-feitas. No iOS e mesmo no Windows Phone 7 as coisas funcionam de forma mais integrada. As apps tem menos uma barreira no acesso ao hardware e o SDK é mais estruturado, obrigando a ter uma disciplina de programação que dá mais trabalho, é certo, mas também obriga a fazer apps mais depuradas.
ResponderEliminar