Aula 1 - Android Gerencia de Processo

Prévia do material em texto

1
Sistemas Operacionais Abertos e Mobile
Android Runtime - Dalvik e ART
Prof. Elias Oliveira
2
Qual é o sistema operacional Android?
 Android - Plataforma tecnológica projetada para 
dispositivos móveis, como smartphones, tablets e 
relógios inteligentes.
 Origem - Aquisição da Android Inc. pelo Google em 
2005.
 Desenvolvido foi abraçado pelo Google, 
 Lançamento inicial em 2008.
 É baseado no núcleo do sistema operacional Linux
3
Recursos
 Interface amigável: 
 interface de usuário intuitiva e fácil de usar. 
 É altamente personalizável.
 Multitarefa: 
 Capacidade de executar vários aplicativos ao mesmo tempo. 
 Receber notificações em tempo real.
 Loja de aplicativos: 
 O Google Play Store, uma loja online que oferece uma grande variedade 
de aplicativos, jogos, músicas, filmes e livros. 
4
Arquitetura
 Android é mais do que um sistema operacional. 
 Ele ´e na verdade um software stack composto por cinco 
camadas,
5
Arquitetura
6
Arquitetura
 É baseado no modelo de máquina virtual Java (JVM) e no 
kernel Linux.
 O núcleo do Android é o Linux, que fornece serviços 
básicos do sistema operacional, 
 como gerenciamento de processos, 
 gerenciamento de memória. 
 gerenciamento de arquivos e
 Os drivers de interface com o HW
7
Arquitetura
 Acima do kernel ficam as bibliotecas C/C++ utilizadas por diversos dos 
componentes do sistema compostas pelas seguintes bibliotecas
 Padrão do C (libc), otimizada para dispositivos embarcados;
 Diversos formatos de áudio, vídeo e imagens; 
 Um gerenciador que intermedia o acesso ao display e camadas de imagem 2D 
e 3D; 
 O engine para navegadores WebKit; 
 Bibliotecas para gráficos 2D (SGL) e 3D (OpenGLES); 
 Renderizador de fontes bitmap e vetoriais; e 
 O banco de dados relacional SQLite
8
Arquitetura
 A máquina virtual Dalvik, que executa aplicativos 
Android.
 A Dalvik Virtual Machine é uma implementação 
personalizada e otimizada da Java Virtual Machine 
(JVM).
 Projetada especificamente para dispositivos móveis e 
com recursos limitados.
 É executada num processo isolado “Android Runtime” 
(ART) 
9
Arquitetura
 O Framework de aplicações, fornece as funcionalidades 
necessárias para a construçõ de aplicativos
 Aplicações Android podem possuir quatro tipos de 
componentes: 
 Activities,
 services, 
 content providers e
 broadcast receivers. 
10
Arquitetura
 Activity é um componente fundamental que representa 
uma única tela com uma interface de usuário. 
 Cada Activity é uma janela onde os elementos da 
interface, como botões, textos e imagens, são exibidos e 
com os quais o usuário pode interagir
11
Arquitetura
 Service é um componente que permite a execução de 
operações em segundo plano sem uma interface de usuário. 
 Tipos de Services:
 Foreground Services: Executam tarefas que o usuário está 
ciente, como tocar música ou baixar arquivos.
 Background Services: Executam tarefas que o usuário não 
está ciente diretamente, como sincronização de dados.
 Bound Services: Permitem que outros componentes, como 
Activities, se conectem a eles para interagir e realizar 
operações.
12
Arquitetura
 Content Provider é um componente que permite que 
os aplicativos compartilhem dados entre si de maneira 
segura e estruturada. 
 Eles gerenciam o acesso a um repositório central de 
dados, permitindo que diferentes aplicativos leiam e 
escrevam dados
13
Arquitetura
 Broadcast Receiver é um componente que permite que 
os aplicativos recebam e respondam a mensagens de 
broadcast enviadas pelo sistema ou por outros 
aplicativos. 
 Eles permitem que os aplicativos “ouçam” eventos do 
sistema, como mudanças na conectividade de rede, 
recebimento de mensagens SMS, ou a conclusão de um 
download.
14
ART - Android Runtime
 Quando construímos nosso aplicativo e geramos APK, 
parte desse APK são arquivos .dex . 
 Esses arquivos contêm o bytecode de nosso aplicativo.
 O bytecode escrito em arquivos .dex é traduzido pelo 
Android Runtime em código de máquina.
 O Android Runtime também gerencia memória e coleta 
de lixo
15
ART - Android Runtime
16
ART - Android Runtime
 O Android Runtime é um dos principais blocos de construção do 
ecossistema Android. 
 O Android inclui um grupo de bibliotecas que fornece a maioria das 
funcionalidades disponíveis nas principais bibliotecas da linguagem Java
 o Android utiliza-se de uma Máquina Virtual(VM) própria a ART/DALVKIT.
 Tanto ART como Dalvikit utilizam o kernel do Linux para lidar com 
funcionalidades de nível mais baixo, como segurança, threading e 
gerenciamento de processos e memória.
 A partir do Android 5.0 (Lollipop), ART substituiu Dalvik como o runtime 
padrão
17
Android Runtime
A principal diferença entre Dalvik e ART (Android Runtime) está na forma como eles 
executam os aplicativos no Android:
1. Dalvik:
 - Compilação Just-In-Time (JIT): Dalvik utiliza a compilação JIT, que compila o código 
do aplicativo em tempo de execução. Isso significa que o código é traduzido para código 
de máquina enquanto o aplicativo está sendo executado.
 - Desempenho: A compilação JIT pode resultar em desempenho mais lento, pois a 
tradução do código ocorre durante a execução do aplicativo².
 - Consumo de Recursos: Pode consumir mais bateria e memória devido à necessidade 
constante de compilar o código durante a execução¹.
 
18
Android Runtime
19
Android Runtime
2. ART (Android Runtime) Android L:
 - Compilação Ahead-Of-Time (AOT): ART utiliza a compilação AOT, que compila o código do 
aplicativo no momento da instalação. 
 - Desempenho: A compilação AOT resulta em desempenho mais rápido, pois o código já está 
pré-compilado quando o aplicativo é executado.
 - Consumo de Recursos: Reduz o consumo de bateria e memória, pois elimina a 
necessidade de compilar o código durante a execução.
Desvantagens:
 O ART no Android L usava muito mais RAM do que o Dalvik.
 Maior tempo para instalar o aplicativo
 Mais tempo para realizar uma atualização do sistema.
20
Android Runtime
21
Android Runtime
 Compilação guiada por perfil (Android N)
 A compilação guiada por perfil é uma estratégia que permite 
melhorar constantemente o desempenho dos aplicativos Android 
durante sua execução. 
 Por padrão, o aplicativo é compilado usando a estratégia de 
compilação Just in Time , mas quando o ART detecta que 
alguns métodos são "quentes", o que significa que eles são 
executados com frequência, o ART pode pré-compilar e 
armazenar em cache esses métodos para obter o melhor 
desempenho.
22
Android Runtime
23
Android Runtime
 Melhor desempenho possível para as partes principais do 
aplicativo enquanto reduz o uso de RAM. 
 Para a maioria dos aplicativos apenas 10% a 20% do 
código é usado com frequência.
 Após essa mudança, o ART não afetou mais a velocidade 
de instalação de aplicativos e atualizações do sistema. 
 A pré-compilação acontece apenas enquanto o dispositivo 
estava ocioso e carregando.
24
Android Runtime
25
Android Runtime
 Desvantagem:
 Para obter dados de perfil e pré-compilar métodos e 
classes usados com frequência, o usuário precisa 
realmente usar um aplicativo. 
 Isso significa que alguns primeiros usos do aplicativo 
podem ser um tanto lentos porque, nesse caso, apenas 
a compilação Just in Time será usada.
26
Android Runtime
 Perfis na nuvem (Android P)
 A ideia principal por trás dos perfis na nuvem é que a maioria 
das pessoas usa o aplicativo de maneira bastante 
semelhante. 
 Portanto, para melhorar o desempenho logo após a 
instalação, podemos coletar dados de perfil de pessoas que 
já usaram este aplicativo. 
 Esses dados de perfil agregados são usados para criar um 
arquivo denominado perfil de núcleo comum para o 
aplicativo.
27
Android Runtime
28
Android Runtime
29
Android Runtime
 Os novos usuários obtêm um melhor desempenho logo após o 
download de um aplicativo. Depois que o usuário executa um aplicativo, o ART coleta dados 
de perfil específicos do usuário e recompila o código que é 
frequentemente usado por esse usuário em particular quando o 
dispositivo está ocioso.
 E a melhor parte de tudo isso é que nós, desenvolvedores que 
criamos aplicativos, não precisamos fazer nada para habilitar 
esse recurso. Tudo acontece nos bastidores do Android 
Runtime.
30
Resumo ART - Android Runtime
31
Prioridade Processos 
 No Android todos os processos são mantidos na 
memória até que haja a necessidade de recursos para 
outros processos. 
 A ordem onde os processos são finalizados para 
liberação de recursos está associada ao nível de 
prioridade da aplicação do mesmo. 
32
Prioridade Processos
33
Prioridade Processos
 Active Processes: São processos em interação com usuário 
(foreground). São os processos mantidos a todo custo pelo 
gerenciador;
 Visible Processes: São processos que estão visíveis, mas não estão 
interagindo com o usuário. Estes processos somente são terminados 
em casos de extrema necessidade, para que um processo ativo 
continue executando;
 Started Service Processes: São processos hospedando serviços que 
foram iniciados e não possuem interface visível. Como não interagem 
diretamente com o usuário possuem um nível de prioridade inferior ao 
de processos visíveis;
34
Prioridade Processos
 Background Processes: São processos de atividades 
que não estão visíveis e não possuem serviços iniciados. 
Estes processos são finalizados utilizando-se o padrão 
Last–Seen–First–Killed;
 Empty Processes: São processos já finalizados, que são 
mantidos na memória pelo sistema operacional, para 
acelerar o start–up do mesmo e melhorar a performance 
do sistema. Estes processos são frequentemente 
finalizados para serem finalizados e cederem recursos aos 
processos em execução.
35
Comunicação entre processos
Permitir que diferentes componentes de um aplicativo ou diferentes aplicativos 
troquem informações e coordenem suas atividades. 
 1. **Binder**: 
 É o principal mecanismo de IPC no Android. 
 Ele permite a comunicação eficiente entre processos, utilizando um módulo no 
kernel do sistema.
 2. **Intents**: 
São usados para enviar mensagens assíncronas entre componentes de um 
aplicativo ou entre diferentes aplicativos.
 Intents podem iniciar atividades, serviços ou transmitir dados.
36
Comunicação entre processos
 3. **Content Providers**: 
 Permitem que aplicativos compartilhem dados com outros aplicativos de maneira controlada. 
 Usados para acessar e modificar dados armazenados em um banco de dados SQLite, arquivos ou 
outros repositórios persistentes.
 4. **Messenger**: 
 Utiliza objetos `Message` para enviar dados entre processos. 
 É útil para comunicação simples e de baixo volume de dados.
 5. **AIDL (Android Interface Definition Language)**:
 Permite a definição de interfaces, podem ser usados para se comunicar com serviços em outros 
processos. 
 É mais complexo que o Messenger, mas oferece maior flexibilidade e controle.
37
Comunicação entre processos
38
Bibliográfia
 Bordin, Maycon. (2012). Introdução a Arquitetura 
Android. 
 https://tecnobits.com/pt/o-que-%C3%A9-sistema-operaci
onal-android/
 https://ichi.pro/pt/android-runtime-como-dalvik-e-art-funci
onam-121323415949541
 
https://tecnobits.com/pt/o-que-%C3%A9-sistema-operacional-android/
https://tecnobits.com/pt/o-que-%C3%A9-sistema-operacional-android/
https://ichi.pro/pt/android-runtime-como-dalvik-e-art-funcionam-121323415949541
https://ichi.pro/pt/android-runtime-como-dalvik-e-art-funcionam-121323415949541
	Sistemas Operacionais Abertos e Mobile
	Qual é o sistema operacional Android?
	Recursos
	Arquitetura
	Arquitetura (2)
	Arquitetura (3)
	Arquitetura (4)
	Arquitetura (5)
	Arquitetura (6)
	Arquitetura (7)
	Arquitetura (8)
	Arquitetura (9)
	Arquitetura (10)
	ART - Android Runtime
	ART - Android Runtime (2)
	ART - Android Runtime (3)
	Android Runtime
	Android Runtime (2)
	Android Runtime (3)
	Android Runtime (4)
	Android Runtime (5)
	Android Runtime (6)
	Android Runtime (7)
	Android Runtime (8)
	Android Runtime (9)
	Android Runtime (10)
	Android Runtime (11)
	Android Runtime (12)
	Android Runtime (13)
	Resumo ART - Android Runtime
	Prioridade Processos
	Prioridade Processos
	Prioridade Processos (2)
	Prioridade Processos (3)
	Slide 35
	Comunicação entre processos
	Slide 37
	Bibliográfia