Resumo sobre gerenciamento de arquivo em dispositivos mveis

Reinaldo Cerqueira Pinto1

1

Graduo em Sistemas de Informao Universidade Salvador

Feira de Santana, BA Brasil
pinto.rei@hotmail.com

1. Sistemas de arquivos
Todas as aplicaes precisam armazenar e recuperar informao. Enquanto estiver
executando, um processo pode armazenar urna quantidade limitada de informao dentre de
seu prprio espao de endereamento. Contudo, a capacidade de armazenamento est restrita
ao tamanho do espao do endereamento virtual. Para algumas aplicaes, esse tamanho
adequado, mas, para outras, como reservas de passagens areas, bancos ou sistemas
corporativos, pequeno demais.
Um segundo problema em manter a informao dentro do espao de endereamento
do processo que, quando o processo termina a informao perdida. Em muitas aplicaes
(por exemplo, bancos de dados), a informao precisa ficar retida por semanas, meses ou at
mesmo para sempre. inaceitvel que a informao em uso pelo processo desaparea quando
ele encerrado. Alm disso, a informao no deve desaparecer se urna falha no computador
eliminar o processo.
Um terceiro problema que muitas vezes necessrio que mltiplos processos
tenham acesso informao i(ou a parte dela) ao mesmo tempo. Se tivermos uma Lista
telefnica on-line armazenada dentro do espao de endereamento de um determinado
processo, somente esse processo poder ter acesso a ela, A soluo para esse problema
tornar a prpria informao independente de qualquer processo

2. Arquivos
Arquivo um mecanismo de abstrao, Ele oferece meios de armazenar informaes
no disco e de l-Ias depois, Isso deve ser feito de um modo que isole o usurio dos detalhes
sobre como e onde a informao est armazenada e como os discos na verdade funcionam.
Provavelmente a caracterstica mais importante de qualquer mecanismo de abstrao
o modo corno os abjetos so gerenciados e nomeados; portanto, iniciaremos nosso estudo
de sistemas de arquivos falando sobre a nomeao de arquivos. Quando um processo cria um
arquivo, de d um nome a esse arquivo. Quando o processo termina., o arquivo continua
existindo e outros processos podem ter acesso a ele simplesmente buscando seu nome.

As regras exatas para se dar nome a um arquivo variam de sistema para sistema, mas
todos os sistemas operacionais atuais permitem cadeias de caracteres (strings) de uma at oito
letras como nomes vlidos dc arquivos. Assim, andrea e regina so possveis nomes de arquivos. Frequentemente dgitos e caracteres especiais tambm so permitidos, tornando vlidos
nomes corno 2, urgente! e Ft_qura2. Muitos sistemas de arquivos permitem nomes com
tamanhos de at 255 caracteres.
Alguns sistemas de arquivos distinguem letras maisculas de minsculas e outros,
no. O UNIX pertence primeira categoria; o MS-DOS pertence segunda. Portanto, um
sistema UNIX pode ter trs arquivos distintos chamados maria, Maria e MARIA. No MSDOS, todos esses nomes referem-se ao mesmo arquivo.

3. Implementao de memria no Symbian.

O Symbian OS divide a memria em pginas lgicas e molduras fsicas. O tamanho usual
para as molduras de 4KB. um sistema operacional de 32 bits e seus endereos variam em
at 4GB conforme Tanenbaum [2]. Devido as limitaes de tamanho de memria, no
vivel para o Symbian dedicar 1MB para a tabela de pgina, pois a pesquisa e acesso a uma
tabela de pgina muito grande, iria provocar uma enorme sobrecarga ao sistema.
No Symbian h quatro verses de implementaes de memrias, sendo cada uma
projetada para uma configurao de hardware. So elas:
Modelo em movimento: Foi concebido para as arquiteturas mais recentes do ARM,
neste modelo o diretrio tem 4 KB, e cada entrada possui 4 bytes, o que da um
diretrio de 16 KB. Embora a segmentao no seja explicitamente utilizada, existe
uma organizao para o layout da memria. Existe uma parte para guardar os dados
pertencentes ao utilizados, e uma parte para guardar os dados relativamente ao
Kernel.
Modelo mltiplo: Modelo concebido para a verso 6 da arquitetura ARM. A MMU,
nesta verso, difere da utilizada nas verses anteriores. Por exemplo, a page directory,
requer um manuseamento diferente uma vez que pode ser seccionada em duas partes,
cada um referenciando diferentes conjuntos de tabelas de pagina, user-page tables e
kernel-page tables.
Modelo direto: Este modelo assume que no existe uma MMU. um modelo
raramente utilizado uma vez que a falta de MMU poderia causar graves problemas de
performance. Este modelo til para ambientes de desenvolvimento em que por
alguma razo seja til ter a MMU desativada.
Modelo Emulador: Desenvolvido para suportar o emulador do Symbian OS no
Microsoft Windows. Este modelo possui restries, o emulador roda como um nico
processo no Windows. O espao de endereamento esta limitado a 2 GB (ao invs dos
4GB). Toda a memria disponibilizada para o emulador acessvel por qualquer
processo do Symbian OS.

4. Implementao de memria no Android.

Conforme Hubsch [1] nas aplicaes Android o uso da memria limitado a 16 MB.
Caracterstica encontrada nos dispositivos mveis. Quanto mais aplicaes mantida na

memria mais rpido a realizado a troca entre as aplicaes, prtica comum na utilizao
dos usurios nos dispositivos mveis.
Como o Android baseado em Linux, sendo cada aplicativo tendo sua mquina
virtual, dessa forma cada processo diferente e invisvel do outro. seus aplicativos do
Android so escritos na linguagem Java e compilados os arquivos de recursos e gerando um
arquivo do tipo .apk, onde a ferramenta Android Asset Packaging Tool (AAPT) faz o
gerenciamento dos pacotes e instala os arquivos .apk no sistema.
J o alocamento e desalocamento de memria feito automaticamente pelo garbage
collector, que gerencia a questo do alocao de memria. O garbage collector solicitado
sempre que uma aplicao possuir um endereo de momria alocado que no possua
nenhuma referncia ativa apontando para ele, sendo que o mesmo no remove aplicativos
utilizados, dessa forma perde-se desempenho na utilizao desse recurso.

5. Referncias

[1] Tanenbaum, Andrews S. Sistemas Operacionais Modernos. 3 Ed., editora Pearson, So

Paulo 2009, 656 pg.