- Dalvik funcionava usando compilação JIT, traduzindo o código enquanto o aplicativo estava em execução.
- O ART otimiza o sistema usando a compilação AOT, realizando o processo durante a instalação.
- Ambos os ambientes utilizam o formato de arquivo DEX, garantindo a compatibilidade entre as versões.
- A transição para a tecnologia ART reduziu o consumo de bateria e melhorou a fluidez do sistema.
Se você já se perguntou o que realmente acontece nos bastidores do seu celular quando você abre um aplicativo, a resposta está no ambiente de execução. No ecossistema Android, migramos de uma arquitetura baseada na máquina virtual Dalvik para um sistema muito mais robusto chamado Android Runtime, mais conhecido como ART. Essencialmente, o ART é responsável por traduzir o código escrito pelos programadores em instruções que o hardware do seu dispositivo consegue entender sem travar.
Para entender isso, é importante saber que o Android não executa Java nativamente; em vez disso, ele usa uma adaptação personalizada . Tudo começa com o código-fonte, que é transformado em bytecode e termina em um formato específico chamado DEX. Dependendo se a sua versão do Android é mais antiga ou mais recente, o caminho que esse código percorre para ser executado muda drasticamente, afetando aspectos do dia a dia, como a duração da bateria e a velocidade de carregamento dos aplicativos.
O Legado de Dalvik: A Era do Just-In-Time
Dalvik foi um pilar fundamental desde o início do Android. Seu objetivo era claro: permitir que aplicativos escritos em Java fossem executados em dispositivos com recursos muito limitados . Ao contrário de uma máquina virtual Java padrão, o Dalvik foi otimizado para usar menos memória e executar várias instâncias simultaneamente, delegando o gerenciamento de threads ao kernel do Linux.
A principal característica do Dalvik era a compilação Just-In-Time (JIT) . Isso significava que o código era traduzido para linguagem de máquina precisamente quando o usuário interagia com o aplicativo. Para evitar a repetição dessa tarefa tediosa a cada interação, o Dalvik criou arquivos chamados ODEX (Optimized DEX) , que armazenavam as partes já traduzidas em um cache. O problema era que esse processo constante de compilação consumia ciclos de CPU e, portanto, mais energia.
Android Runtime (ART): O salto para o Ahead-Of-Time
A partir do Android 5.0 Lollipop, o ART assumiu o controle total. A grande diferença é que o ART implementa a compilação Ahead-Of-Time (AOT) . Em vez de esperar que você abra o aplicativo, o ART realiza o trabalho pesado durante a instalação. Ele usa uma ferramenta chamada dex2oat para converter arquivos DEX em executáveis ELF (Executable and Linkable Format), que são nativos do Linux.
Graças a essa abordagem, ao tocar no ícone de um aplicativo, o sistema não precisa compilar nada; ele simplesmente lê o arquivo ELF e o executa. Isso significa que o processador trabalha menos, a bateria dura mais e os aplicativos funcionam com muito mais fluidez. No entanto, há uma pequena desvantagem: a instalação de aplicativos leva um pouco mais de tempo e eles ocupam mais espaço de armazenamento do que com o Dalvik.
Comparação técnica e principais melhorias
Embora ambos os ambientes sejam compatíveis e executem o mesmo bytecode DEX, o ART introduziu melhorias que tornam o sistema incrivelmente rápido. Uma das mais significativas é a coleta de lixo (GC) . No Dalvik, o coletor de lixo causava aquelas pausas irritantes ou "travamentos" na interface (o infame lag). O ART redesenhou isso com um sistema predominantemente concorrente , tornando as pausas independentes da quantidade de memória utilizada.
- Depuração avançada: O ART permite que os desenvolvedores vejam quais bloqueios as threads estão mantendo e rastreiem instâncias de classe com muito mais precisão.
- Diagnósticos precisos: Agora, quando um aplicativo trava, os relatórios de erros são muito mais detalhados, especialmente em casos de Null Pointer Exception.
- Gerenciamento de memória: Ao contrário do Dalvik, que usava um cache não paginável, o ART usa memória RAM que É possível a paginação., otimizando o uso do hardware.
O processo de empacotamento: do código ao APK
Para que qualquer um desses ambientes funcione, o código precisa passar por uma linha de montagem. Primeiro, o compilador Java cria arquivos .class, que a ferramenta dex converte em um único arquivo classes.dex. Este arquivo é o núcleo do APK e é o que o ART ou o Dalvik processarão.
Ferramentas como o aapt são usadas para empacotar recursos, e o zipalign otimiza o alinhamento de dados, garantindo que o processador acesse a memória da forma mais eficiente possível. Assim que o APK chega ao dispositivo, a mágica acontece: se houver ART, o arquivo ELF é gerado; se houver Dalvik, o arquivo ODEX começa a ser gerado dinamicamente.
Fatos interessantes sobre ROMs e o processo de desodexação
No mundo das ROMs personalizadas, é comum ouvir os termos odex e deodex . Como o arquivo ODEX depende do hardware e do sistema exato em que foi criado, ele não pode ser facilmente transferido de um telefone para outro. Para modificar um aplicativo sem causar problemas no sistema, os desenvolvedores realizam um processo de desodexação , que consiste em integrar o arquivo otimizado ao APK para facilitar sua manipulação.
O ecossistema Android evoluiu de uma máquina virtual flexível, porém com alto consumo de energia, para um ambiente de execução otimizado que prioriza a experiência do usuário. Enquanto o Dalvik focava na versatilidade da tradução de código em tempo real, o ART maximizou a utilização do hardware por meio da pré-compilação , garantindo que o software seja mais estável, rápido e eficiente em termos de energia.
Índice