As emocionantes aventuras de um sys admin linux na procura pelo uptime perfeito!

Continuando com meus posts sobre programação Android, mesmo desanimado pelo fato de não conseguir colocar minha(s) app(s) no Android Market.

Mas já que comecei, e o assunto é interessante, melhor continuar. Neste post, dando uma olhada por alto em como o Android OS é organizado e como ele gerencia a memória.

Arquitetura e Memória

O Android OS tem uma arquitetura em camadas (stacks). Os níveis mais baixos dessas camadas são por sua vez expostos para os níveis mais altos através de interfaces até a camada mais alta, onde se programa em Java.

A imagem abaixo (cortesia do google) demonstra uma visão aumentada de como estas camadas são organizadas:

Arquitetura do Android OS

Como se pode ver, o nível mais baixo do Android é o Kernel. Atualmente (versão 1.5 “cupcake”) o kernel utilizado é o Linux 2.6.27. No kernel estão também os drivers e controles básicos de hardware. A segunda camada é onde ficam as bibliotecas (libraries) e o próprio runtime do Android, incluindo aí a Dalvik Virtual Machine, encarregada de efetivamente executar o código das aplicações. A terceira camada consiste já das capacidades expostas aos desenvolvedores  para suas aplicações (gerenciador de janelas, sistema de notificação e etc). Finalmente a última camada é composta pelas aplicações propriamente ditas.

A camada de kernel é responsável também pelo controle mais fino da memória. Cada aplicação no Android roda em um processo separado, com sua própria VM, PID (número de processo) e usuário. Isso garante que caso uma aplicação dê problema, ela possa ser isolada e removida da memória sem comprometer o resto do sistema.

A Dalvik VM é a virtual machine que roda código java, mas com várias alterações para fazer isso usando menos ciclos de CPU (portanto gastando menos energia) e com otimizações de espaço/tamanho de dados. A Dalvik usa bytecode diferente da JVM tradicional e as aplicações usam um formato diferente do tradicional JAR (.jar), chamado .dex, também otimizado para menor uso de espaço.

Uma das diferenças da Dalvik é como ela mapeia a memória. Isso é feito usando um mapa memória-disco que permite que aplicações sejam rapidamente removidas da memória e depois restauradas. O G1 da T-Mobile limita cada aplicação a 16M de heap, e ainda estou tentando descobrir exatamente quanto de RAM ele tem. Algumas fontes dizem 192M, outras 64M. O fato é que a maioria das aplicações é bem menor que 16M. Quando o sistema começa a ter problemas de falta de memória o OS vai fechar aplicações que não estejam sendo exibidas, e estas aplicações podem ser retomadas depois com seus estados intactos (desde que bem programadas).

No próximo post eu vou falar um pouco sobre esses cuidados com as informações e o ciclo de vida das aplicações.