O que é ROM/Firmware?
Quando falamos no Sistema Operacional Android muitas vezes nos referimos a ele como ROM ou Firmware. Basicamente podemos utilizar esses termos como sinônimos. Mas de onde eles vieram?
O termo ROM é antigo conhecido dos usuários de computadores. é um termo inglês que significa (R)ead (O)nly (M)emory (ou memória somente para leitura). É a memória não volátil ou que não pode ser modificado pelo usuário (em teoria, pois com o acesso root nós podemos fazê-lo). É exatamente na memória ROM de seu aparelho que localiza-se o seu sistema operacional. O termo firmware é menos utilizado no universo Android sendo mais comum junto aos usuários do iOS da Apple.
Portanto toda as vezes que você ler aqui no site, em fóruns ou ouvir alguémfalando em ROM ou Firmware, estará referindo-se ao próprio sistema operacional.
O que é uma ROM/Firmware Odexada e Deodexada?
Algumas vezes nos deparamos com algumas limitações como por exemplo a impossibilidade de aplicação de alguma Modificação pelo simples fato desta ROM ser "odexada". Uma ROM odexada possui arquivos com extensão "*.odex" que os desenvolvedores criam para, supostamente salvar espaço na memória. Porém, algo bastante comum de ocorrer é a permanência de arquivos "*.odex" na memória após a desistalação de certos aplicativos fazendo com que ocorram erros de leitura da memória, impedindo que novos aplicativos possam ser instalados. O Sistema Operacional Google Android (que é baseado no GNU/Linux) usa pacotes de aplicativos, ou arquivos com extensão "*.apk", para dizer ao sistema operacional que aplicativo deverá carregar e executar. Se você já está familiarizados com o Android, já sabe que ele funciona na base de partições, onde os aplicativos contidos na partição "/system/" são aplicativos do sistema (e não pode ser alterado ou modificado sem ter o acesso root, uma vez que é uma parte do sistema operacional em si), enquanto as contidas na partição "/data/" são aplicativos do usuário e podem ser livremente modificados. A partição "/system/" é a primeira a carregar durante a inicialização do sistema operacional, dando prioridade aos aplicativos nele contidos. É com estes aplicativos que lidam os sistemas odexados e deodexados.
Voltando para as aplicações Android, há dois caminhos possíveis a seguir considerando-se o fato de que cada aplicativo é composto de um arquivo "*.apk" e uma parte de cache que diz a Máquina Virtual Dalvik o que cada componente que vem com o aplicativo deve fazer. Para os que não sabiam para que servia o "wipe Dalvik cache", agora sabem: limpar a Máquina Virtual Dalvik.
Nos sistemas operacionais odexados, o cache para cada "*.apk" está contido em um arquivo separado com extensão "*.odex" que é carregado na Máquina Virtual Dalvik no momento da inicialização, reduzindo o tempo de inicialização.
Já nos sistemas operacionais deodexados, o cache para cada "*.apk" está contido no arquivo apk como um arquivo "classes.dex", tornando o tempo de inicialização mais lento.
Perceba o motivo dos desenvolvedores preferirem criar as ROM odexadas: primeiro isso torna mais difícil modificar os aplicativos do sistema (tornando-o mais estável e seguro) e em segundo lugar torna mais rápido o tempo de carregamento do sistema operacional em si, uma vez que o cache é construído como parte da própria Máquina Virtual Dalvik. Confuso? Vamos tentar descomplicar.
Em casos normais, onde a ROM é odexada, os arquivos "*.odex" para cada arquivo apk contindo na pasta "/system/" (que são armazenados fora dos arquivos apk próprios) são carregados na Máquina Virtual Dalvik quando o sistema operacional carregar. Como esses arquivos contêm informações odex pré carregadas para cada aplicativo do sistema, o sistema operacional sabe o que esperar quando está iniciando e, conseqüentemente, carrega todos esses aplicativos mais rápido e para o usuário, isso significa que o tempo de inicialização será mais rápido.
Por outro lado, em uma ROM deodexada, não há informações de cache dentro da Máquina Virtual Dalvik no momento da inicialização e por isso o sistema só sabe quais são os aplicativos para carregar após o arquivos apk dentro da pasta "/system/" são acessados pelo usuário. Na prática isso vai resultar em muito mais tempo de inicialização (tá bom, nem tanto assim) uma vez que cada apk será processado um de cada vez.
Emborra pareça ser uma grande estupidez utilizar uma ROM deodexada, ela somente inicializará um pouco (e só um pouco mesmo) mais lentamente que as odexadas no primeiro boot após a limpeza da Máquina Virtual Dalvick, sendo que todos os boot subseqüentes serão tão rápidos quanto qualquer ROM odexada. Isto ocorre porque durante a primeira inicialização pós a instalação da ROM deodexada e portanto com a Máquina Virtual Dalvick "limpa", todas as informações de cache são carregadas na Máquina Virtual Dalvick tal como em qualuqer outra ROM (até que você limpe o cache Dalvik mais uma vez).
É por causa das possibilidades de realizar modificações/customizações que os desenvolvedores de ROM preferem essa forma deodexada (e eu também!). Uma vez que em um cenário deodexed, todo o código da aplicação está contido dentro de um único arquivo apk.
O desenvolvedor pode simplesmente modificar os valores nos próprios apk para aplicar qualquer aparência personalizada para o aplicativo em si, sem perder nenhuma funcionalidade. Isso também abre possibilidades de alterar os parâmetros diferentes do aplicativo sem afetar como os outros vão atuar. Como um sistema dodexado não sofre nenhuma dependência externa, há mais liberdade para modificar o que quiserem. Por outro lado, com uma ROM odexada, algumas modificações passam a ser amis difícies e sempre dependentes de atualizações e inftervenções do desenvolvedor a cada versão nova do sistema operacional.
Com a liberação do Android 4.4 KitKat, um projeto "secreto" (bom, nem tão secreto assim) com o objetivo de melhorar o desempenho dos dispositivos com o Sistema Operacional Google Android foi apresentado em algumas versões (customizadas ou não). Este projeto introduz uma nova forma de executar os aplicativos, com a promessa de aumentar a velocidade de execução. Ele se baseia no fato dos aparelhos atuais serem mais poderosos (o meu smartphone é mais poderoso que meu notebook, inclusive). Vamos conhecer o Android Runtime, ART para os íntimos, que veio para substituir o Dalvik Virtual Machine no Android 5.0 Lollipop
Dalvik Virtual Machine (JIT) vs. Android Runtime (AOT)
Para entendermos as vantagens e desvantagens do ART, precisamos entender um pouco sobre o seu antecessor: o Dalvick. A máquina virtual Dalvik, criada por Dan Borstein, está presente no Google Android desde a sua primeira versão.
Os aplicativos criados para rodarem no Android são escritos em Java (não confunda com Java Script, isso é uma outra história). De forma a permitir que o aplicativo rode em máquinas com arquiteturas distintas, este código é convertido em "bytecode", onde temos um código intermediário entre o código fonte e as instruções entendidas pelo hardware. E é aqui que o Dalvick entra em ação!
A máquina virtual Dalvik converte o "bytecode" em um código legível pelo hardware (que é o código de fato executado pelo processador de nossos aparelhos). A essa tradução damos o nome de "compilação" que ocorre durante a execução do aplicativo e que por isso é classificado como um processo JIT (Just In Time). Ou seja, todas as vezes que você solicita a execução de um aplicativo, ele é compilado durante a execução, por isso ele demora um pouco para abrir e entrar em funcionamento. E uma característica interessante é que ele compila apenas a parte necessária para a tarefa em questão e não o aplicativo inteiro. Após a compilação os dados são armazenados em cache. Incrível? Com certeza! Se da forma que é feito, em aparelhos top de linha já é rápido, o que já era bom pode ficar ainda melhor.
O ART, ao contrário do Dalvik, trabalha com processos chamados AOT (Ahead of Tine). O ART realiza a compilação antes da execução do aplicativo. Desta forma, o tempo que perderíamos com a compilação durante a execução do aplicativo, é aproveitado com uma compilação anterior a execução deste mesmo aplicativo (e esta compilação ocorre uma única vez após a instalação do aplicativo, o qeu faz a isntalação demorar um pouco mais do que nos aparelhos utilizando o Dalvik). O Google espera reduzir em até 2 vezes o tempo de execução dos aplicativos com o ART (eu disse que o Google ESPERA que aconteça e não que você verá acontecer em seu aparelho anteso do Android 5.0, só para deixar isso bem claro). Isso implicará em redução no consumo de bateria também (uma vez que os aplicativos já estão compilados, reduzirá o tempo de uso dos processadores para a compilação. Mas nem tudo é cor de rosa. Por já manter os aplicativos compilados na memória do aparelho, acaba por ocupar um espaço maior. Os aparelhos com armazenamento interno pequeno, talvez deixem seus proprietários decepcionados (isso só o tempo dirá). Haverá ainda menos aplicativos rodando ao mesmo tempo o que pode atrapalhar nossa tão útil multitarefa. Já podemos entender porque o Dalvik foi utilizado desde o início,não é mesmo? Não? Então eu explico.
O primeiro dispositivo Android, o HTC Magic tinha uma capacidade de armazenamento muito baixa. E por isso, como o Dalvik compila no momento de uso dos aplicativosapenas o que é necessário naquele momento, haveria uma economia de espaço.
Agora quando falamos de dispositivos de alto desempenho, provavelmente não veremos muita diferença (mas eu posso estar errado).
O que é uma ROM/Firmware zipalignada?
O zipalign é uma ferramenta de alinhamento de arquivo introduzido pela primeira vez com Android SDK 1.6 (kit de desenvolvimento de software). Ele optimiza a forma como um pacote de aplicativos Android (apk) é empacotado. Isso permite ao Sistema Operacional Android interagir com a aplicação de forma mais eficiente e, portanto, tem o potencial para fazer as aplicações em geral e todo o sistema muito mais rápido. O tempo de execução é minimizado para aplicações zipaligned, resultando em menor quantidade de consumo de memória RAM ao executar o aplicativo.
No Sistema Operacional Android, arquivos de dados armazenados em cada pacote de aplicativos são acessados por vários processos, por exemplo, o instalador irá ler o manifesto de dados para determinar as permissões associadas, o servidor do sistema pode ler esses recursos por várias razões, como a exibição de notificações; a aplicação de inicialização, vai ler os recursos para obter o nome do aplicativo e ícone, etc. Como o Sistema Operacional Android é baseado em infra-estrutura operacional verdadeiramente multitarefa, esses arquivos são continuamente e repetidamente acessados (por isso não adianta ficar utilizando os Task Killers!!! Se você usa, para com essa besteira!). Finalmente, mas não menos importante, o próprio aplicativo lê os dados do manifesto.
Como o Android é baseado no Sistema Operacional GNU/Linux, o mapeamento de memória desempenha um papel-chave na gestão eficiente dos processos. Essencialmente, o alinhamento ideal para o código do Sistema Operacional Android é o "4-byte". Isso significa que, se os aplicativos forem mapeados na memória para os limites "4-byte" e alinhados, o sistema operacional não precisará ler o pacote de aplicativos inteiro para buscar o manifesto de dados desejado. Cada processo do sistema vai saber com antecedência para onde buscar o recurso desejado e irá executá-lo mais suave e rapidamente. E isso resulta novamente em mais economia de memória RAM.