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

Programando Androids – Parte 3

Posted: maio 13th, 2009 | Author: coredump | Filed under: Programação | Tags: ,

android_t1

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

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.

Compartilhe:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Slashdot
  • StumbleUpon
  • Technorati
  • TwitThis
  • Identi.ca
  • Twitter

Posts relacionados:

  1. Programando Androids – Parte 1 Nos últimos dias eu vendi meu HTC Tytn II e...
  2. Programando Androids – Parte 2 Ferramentas do SDK: Uma das coisas que eu realmente gostei...
  3. Programando Androids – Parte 4 Na parte 3 falei sobre o gerenciamento de memória. Também...
  4. Lanterna: mais uma lanterna para telefones Android! English version below. Como eu disse neste post eu comecei...

No Comments »

Leave a Reply