Pplware

ART vai substituir Dalvik já no Android 4.5

Com o Android 4.4, a Google introduziu várias novidades e melhorias para tornar o Android mais estável, seguro e funcional. Uma dessas novidades foi o novo Android Runtime, o ART, que veio melhorar como as aplicações funcionam.

Esta nova máquina virtual do Android, apesar de ter sido desenvolvida durante 2 anos, é ainda experimental e funciona como alternativa ao Dalvik.

No dia 22 de Janeiro falamos dos dois commits introduzidos pela Google que poderiam dificultar os utilizadores a fazerem ROOT no Android 4.5. Com a aproximação de mais um ano de novidades, nem tudo pode ser mau para os utilizadores e já se conhecem alguns ases de trunfo da Google para a nova versão do Android.

O ART foi uma das melhores funcionalidades apresentadas pela Google no Android 4.4. Veio corrigir vários problemas de funcionamento das aplicações fazendo com que elas passassem a Ahead-of-Time Compilation em vez do tradicional JIT (Just-In-Time).

O Android usa uma máquina virtual para executar o código das aplicações. Claro que não é a melhor solução, a melhor solução passava pelo Android executar as aplicações de forma nativa, falo precisamente do JNI (Java Native Interface). O sistema não tem de ser crucificado, simplesmente foi feita uma má escolha e agora só resta resolver esses problemas.

Devido ao Android usar uma máquina virtual que os equipamento necessitam de muito mais recursos que qualquer outro sistema operativo móvel.

O Dalvik, que é o actual Android Runtime (máquina virtual), não é nada mais do que um software que executa aplicações no Android. Desde o Android 2.2 que usa o JIT (Just-In-Time) para interpretar o bytecode do código Java das aplicações.

No Android, todas as classes Java de uma aplicação são convertidas para Dalvik (.dex) no momento da sua instalação. Um Odex é basicamente um ficheiro pré-processado de classes.dex das aplicações quando as mesmas estão a correr no Dalvik.

Quando um sistema é Odexed, quer dizer que todas as aplicações que estão instaladas no equipamento não têm o ficheiro classes.dex dentro do pacote APK, desta forma, nenhum dado é escrito na cache do dalvik.

Uma aplicação não odexed, também conhecido deodexed, é traduzida em haver duas cópias do ficheiro classes.dex no sistema por cada aplicação instalada, um dentro do pacote APK e outro a ser processado na cache dalvik. Desta forma, as aplicações no seu primeiro arranque demoram mais tempo, uma vez que a Dalvik tem de fazer o processo de extrair e processar o classes.dex.

Apesar das várias criticas e dos problemas do Dalvik, a Google ainda tinha uma enorme margem para o tornar bem funcional, mas decidiu  trocar por um runtime de alta performance, o ART.

O ART permite uma compilação Ahead-of-Time, que resumidamente quer dizer que o bytecode é pré-compilado em linguagem máquina no momento da sua instalação. Isto explica o porquê das aplicações que são instaladas sobre o funcionamento deste runtime levarem mais tempo a instalar e menos tempo para as executar.

Como mencionado em cima, o ART foi introduzido como recurso experimental no Android 4.4. No estágio em que o ART se encontra, apesar de muitos utilizadores reportarem de que o ART proporciona melhor eficiência e melhores tempos de execução das aplicações, na realidade ainda não é muito melhor que o Dalvik. A Google ainda tem muito trabalho pela frente para optimizar este novo runtime e trazer o seu devido potencial.

Benchmark de um simples algoritmo de ordenação de valores executado num equipamento Android com ART, Dalvik e Java Native Interface (jni)

Podem ver o gráfico aqui.

Mesmo a gigante das pesquisas sabendo que o ART ainda não está no seu patamar de máximo potencial, introduziu um commit no repositório AOSP que indica que a próxima actualização do Android vai trazer o ART como runtime pré definido e o Dalvik como alternativa.

Ainda não há certezas de que é definitivo uma vez que esta alteração pode ser revertida na próxima revisão.

Perante esta alteração / intenção da Google em tornar este runtime como pré definido, levantei uma questão. Actualmente o ART só funciona devidamente em hardware Qualcomm, apesar de haverem custom roms com o ART a funcionar noutros hardwares, ele não está totalmente funcional ou simplesmente não se notam quaisquer diferenças entre o Dalvik e o ART. Desta forma questiono, quais serão os benefícios que os utilizadores terão?

As novidades não ficam por aqui e para os que pensavam que nunca mais chegaria o dia em que o Android se tornava 64bits, então podem relaxar porque esse dia está para muito breve, possivelmente chegará na versão 4.6 do Android.

Tanto neste artigo como neste, mostramos que a Google tem estado a fazer várias alterações no repositório do Android e as mudanças que se tem mais notado estão nas pastas platform_system_core e na platform_frameworks_base.

Foram descobertos alguns commits nestas duas pastas que indicam que a Google está a fazer a transição do Android para 64bits. Estes commits foram inseridos por trabalhadores da Google, o que dá segurança de afirmar que são oficiais e que é oficial o Android em 64bits.

Este passo já não é novidade, mais tarde ou mais cedo o Android iria passar a ser 64bits. A Google não está muito preocupada em acelerar a transição, já que só para 2015 é que os processadores completamente funcionais em 64bits vão começar a sair.

Neste momento um processador 64bits não é muito melhor que um bom processador de 32bits. De certo que daqui por uns anos esta nova arquitectura irá tornar-se standard e irá dominar o mercado, mas por enquanto esta plataforma ainda precisa de muito desenvolvimento e optimizações até ser considerada estável e totalmente funcional. Como é o caso do Apple A7 que por ser o primeiro ARMv8 comercial, é bastante instável e como usa tecnologia ARMv8 antiga, ainda não suporta totalmente um sistema 64bits.

Será garantido que em 2015 os vários topos de gamas das várias fabricantes como Samsung, HTC, Sony, etc, irão começar a usar SoCs nesta nova arquitectura. A Qualcomm já anunciou que este ano vai lançar o Snapdragon 805 (ARMv7) com o GPU Adreno 400.

Exit mobile version